Esri Best Practices:

AGILE Project ManagementLana Tylka

Jessica Schrage

Why Agile?

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Build for Value

Requirements evolve over time

64% - Rarely

or Never

20% - Often or

AlwaysAlways

7% Often13%

Sometimes16%

Rarely19%

Never45%

Agile Manifesto

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right,

we value the items on the left more.

Agile Manifesto - www.agilemanifesto.org

KanBan Approach (Still Agile, just not Scrum)

• No defined iterations

• No defined roles

• Direct communication with customer

• Limit your work-in-progress

• Visualize your work

• Ever-changing backlog with on-the-fly prioritization

Scrum Sprint Cycle

Product Backlog Sprint Planning Sprint Backlog

Potentially Shippable

Product Increment

2 - 4 Week

Sprint

Product

Owner

Scrum

Master

The team

Retrospective

Daily Scrum

Stakeholders

Product Backlog

Sprint Planning

Sprint Backlog

Potentially Shippable

Product Increment

Release Manager Scrum of Scrum

Master

The team

Retrospective

Daily Scrum

Stakeholders

Daily Scrum

Daily Scrum

Sprint Planning

The team

Sprint Planning

The team

Scrum

MasterProduct

Owner

Scrum

MasterProduct

Owner

Scrum

Master

Product

Owner

Sprint Backlog

Sprint Backlog

Scrum of Scrums

SAFe (Scalable Agile Framework)

2 - 4 Week

Sprint

When Do These Models Work Best?

Scope,

Technology,

Contract

Waterfall

• Clear requirements

• Fixed deliverables

• Single application

Staged Delivery

• Several applications

• Prototypes expected

Agile

• Flexible scope, deliverables

• One or several applications

Capacity,

Capabilities,

Environment

Size,

Duration

• Small size, short duration project

• Limited capacity, resources, and environment

• Frequent turnover on project team

• Medium or large size, mid to long duration

• Capacity, resources, and environment to support multiple releases

• Customer EXPECTS collaboration

• Stable, experienced project team

• Any size or duration project

Estimating the Work

Big Picture

System

ArchitectureDatabase

DesignWidget 1 Widget 2

Application

Hardening

21

Story Points

34 34 54 21

EpicsStory point is a arbitrary measure used by Scrum

teams. This is used to measure the effort required to

implement a story. In simple terms its a number that

tells the team how hard the story is. Hard could be

related to complexity, Unknowns and effort. In most

cases a story point range is1,2,3,5,8,13,21,34,45

21 34 34 54 21

168 272 272 432 168

Story Points

Hours

Activity Scrum

Master

Product

Owner

Developer Analyst System

Admin

Total

System

Architecture168

Geodatabase

Design272

Widget 1 272

Widget 2 432

Application

Hardening168

16 16 0 16 120

24 24 0 184 40

24 24 176 48 0

32 32 304 80 0

40 16 84 24 4

Estimating Sheet

Managing the Work

Use Tools to Manage Requirements…

Microsoft Team Foundation Server (TFS)Rally Agile Implementation Tool

Using Trello

Using GitHub

Using TFS

Making a Decision

Project Considerations Trello GitHub TFS

Requirements are Proprietary

Mobile App

Easy to setup

Estimation tools

Scheduling tools

Automated Burndown chart

Easily integrated with Visual Studio for Code Repository

Capacity Planning

Exports to MPP and Excel

16%

84%

Estimated %Spent

Estimated %Remaining

Task Proposed StartProposed

FinishStatus

Setup EMCS environment 4/10/17 4/14/17

Configure Portal 4/14/17 4/28/17

Configure Surveys 4/14/17 4/28/17

Survey tie-in 4/24/17 5/19/17

Onsite visit 5/9/17 5/11/17

Finishing touches 5/15/17 5/19/17

Pilot After 5/22

Reports

Doing the Work

Product Backlog

Wish List

Sprint Backlog

Sprint Backlog

4h

Sprint Backlog

3 days8h

2 days1h

2h

4h 8h

Meth

od

Waterfall

Time

Agile

Using Agile in a Consulting Project

Meth

od

Waterfall

Agile

Time

Using Agile in a Consulting Project

Meth

od

Waterfall

Agile

Time

Using Agile in a Consulting Project

Using Agile in a Consulting Project

Meth

od

Waterfall

Agile

Time

Final Release

Example: Agile Daily Stand Up Meeting for Visibility

What did you complete yesterday

What have you planned for today

Are you facing any obstacles?

15 Minutes, 3 Important Questions Defined In Progress Completed Accepted

https://www.rallydev.com/

Managing Resources

Your Project

Plan A Plan BSprint

50%

75%100%

75%

50%

100%

100%

50%

Plan ZSprint

50%

75%100%

75%

50%

100%

100%

50%

50%

50%

50%

50%

50%

Case Studies

Small ScaleContract Type $$ Value Team Size

T&M $32K 2

Case Study – Small Scale

• Why Agile?

• Follow-on support for post-production

• Key Challenges / Lessons Learned

- Enhancement requests ad-hoc in nature based on user feedback

- Lapse between work can be significant which can be difficult for staff

- Customer had flexible release schedule and close access to development staff

Product Backlog Sprint Planning Sprint Backlog

Potentially Shippable

Product Increment

2 Week

Sprint

Product

Owner

Scrum

Master

The team

Retrospective

Daily Scrum

Stakeholders

Lead developer

Analyst

Customer’s PM

Internal PM

2 developers

1 UI\UX Team Member

2 Testers

1 PM

Case Study – Medium ScaleContract Type $$ Value Team Size

T&M $433K 5

Case Study – Medium Scale

• Why Agile?

• Customer was new to Esri technology and unable to define their requirements up

front without collaboration

• Key Challenges / Lessons Learned

- 2 week sprints, formal bi-weekly Stakeholder/Planning/Retro Meetings

- Keeping an agreed MVP was challenging for customer PM and customer

stakeholders

- Diligent backlog prioritization with customer was key to visualize trade-offs

(additions/subtractions of user stories affecting scope and schedule)

Product Backlog

Sprint Planning

Sprint Backlog

Potentially Shippable

Product Increment

2 Week

Sprint

Release Manager Scrum of Scrum

Master

The team

Retrospective

Daily Scrum

Stakeholders

Technical LeadAnalyst

Customer’s PM

Project Manager

Daily Scrum

Daily Scrum

Sprint Planning

The team

Sprint Planning

The team

Scrum

MasterProduct

Owner

Scrum

MasterProduct

Owner

Scrum

Master

Product

Owner

Sprint Backlog

Sprint Backlog

Scrum of Scrums

Analyst Analyst AnalystTech Lead Tech Lead Tech Lead

4-7 Techies4-7 Techies 4-7 Techies

Case Study - Large ScaleContract Type $$ Value Team Size

FFP-LOE $3M 24+ with Subs

Case Study – Large Scale

• Why Agile?

- Project was contractually required to follow the SAFe Agile Methodology.

- Requirements were vague and customer recognized the benefit in iterative

development to achieve the best results.

• Key Challenges / Lessons Learned

- Deployment into the customer’s footprint occurs at the end of the Release.

- Large project team to manage.

- Each Scrum Team was responsible for individual applications.

- Dependencies existed between scrum teams when it came to data sources

- Smaller team meetings for individual applications allowed for faster progress.

- Bi-weekly demonstrations to core team allowed for cohesion for the program as a

whole.

Keys to Successful Projects!

Communication Trusted Partnerships

Transparency

Be Agile!

Questions?

Please Share Your Feedback in the App

Download the Esri

Events app and find

your event

Select the session

you attended

Scroll down to

“Survey”

Log in to access the

survey

Complete the survey

and select “Submit”

Learn and Do More….

• Esri Best Practices: Collect

and Manage Requirements for

Successful GIS Projects

• Esri Best Practices:

Implementing and Enterprise

Geodatabase

• Implementing ArcGIS Island

SESSION LOCATION

• SDCC Room 30A

• SDCC Room 31A

• SDCC Expo Hall

TIME FRAME

• Wednesday 1:00 pm – 2:00 pm

• Wednesday 2:30 pm – 3:30 pm

• 8:30 am – 6:30 pm daily