Esri Best Practices: How to Run an AGILE GIS Project€¦ · Esri Best Practices: How to Run An...

Preview:

Citation preview

Esri Best Practices: How to Run An AGILE GIS

ProjectJennifer Prather (esri), Betsy Leis (esri), and Joe Minus (NGA)

Who’s familiar with Agile?

https://www.youtube.com/watch?v=Wac3aGn5twc

• Watch the video

• Think about:

- What went wrong?

- What would you do differently?

How to Start…

Discuss similar

industriesAssess

workflows

Prioritize

workflows

Create a plan

Conduct

kickoff meeting

56

Choose

a life cycle

Launching your Location Platform Guide:

www.esri.com/LaunchGuide

5

The Agile Approach

Emerging Application Development | 1960’s – 1990’s

Requirements

Design

Implementation

Testing

Maintenance

`

`

`

`

• “I want something else”

1 + years6 months1.5 years1 year

`

Change Management

Process

Contract Amendment

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Agile | Terminology

User Story Epic

Velocity

Burndown Chart

AGILESprint\Iteration

Scope,

Technology,

Contract

When would you use Agile?

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

Proposing Agile

Big Picture

System

ArchitectureDatabase

DesignWidget 1 Widget 2

Application

Hardening

21

Story Points

34 34 45 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 45 21

168 272 272 360 168

Story Points

Hours

Activity Scrum

Master

Product

Owner

Developer Analyst System

Admin

Total

System

Architecture168

Geodatabase

Design272

Widget 1 272

Widget 2 360

Application

Hardening168

Pricing Sheet

16 16 0 16 120

24 24 0 184 40

24 24 176 48 0

20 20 240 80 0

40 16 84 24 4

Work Breakdown Structure

System

ArchitectureDatabase

DesignWidget 1 Widget 2

Application

Hardening

Project

1.1 User Story

1.2 User Story

2.1 User Story

2.2 User Story

2.3 User Story

3.1 User Story

3.2 User Story

3.3 User Story

3.4 User Story

4.1 User Story

4.2 User Story

4.3 User Story

4.4 User Story

4.5 User Story

5.1 User Story

5.2 User Story

Managing Agile

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

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

Let’s talk about people

• People have personalities

• Personalities can be tricky

Collecting Requirements

User stories facilitate a conversation with the team and with the users…

ProductOwner

ScrumMaster

The teamStakeholders

ndependent. Reduced dependencies = easier to plan

egotiable. Details added via collaboration

aluable. Provides value to the customer

stimate-able. Too big or too vague = not estimate-able

mall. Can be done in less than a week

estable. Good acceptance criteria

A good user story uses the “INVEST” model:

I

N

V

E

S

T

Build for Value

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Requirements evolve over time

Product Backlog

Wish List

Sprint Backlog

Sprint Backlog

4h

Sprint Backlog

3 days8h

2 days1h

2h

4h 8h

How do we know when we are done?Confirmation…the acceptance test

How do we know when we are done?Confirmation…the acceptance test

• Given I have enabled

offline access on my map

• When I click on the map to

create a feature

• Then the feature will be

stored locally until I

sync with connectivity.

How do we know when we are done?Couple of things to note…

• Define acceptance just in time…don’t waste too much time

• Part of the conversation process

• Acceptance consistency (given…when…expect) is helpful, but not necessary

Definition of Done

Examples of practices that might be included in the definition of “done:”

• Acceptance criteria met

• Code is reviewed by another development team member

• Test cases are written

• Unit tests and UI automation tasks are written

• Feature is tested for accessibility

We don’t do strict…

treehouse

http://blog.teamtreehouse.com/when-is-a-user-story-done-acceptance-criteria-definition-done

Example – Enterprise Geocoding ServicesDecomposing work into manageable pieces

Provide Single Line capabilities

Logic adheres to the following order building point, street centerline,

zip code

As an employee I need locators to be built on my Agency

Data.

Integrate reference data for building and

street centerlines

As an employee I need an authoritative geocoding service.

API documentation

As an employee I need a cascading set

of locators.

As a business owner I need a geocoding service available to

3rd party applications.

99.99% SLA

REST service

Provide Enterprise Geocoding Services

Feature level Epic

User Stories

Acceptance Criteria

Provide Reverse capabilities

Provide Batch capabilities

• Change control of requirements

• Capturing notes/conversations

What if my customer changes their mind?

Prioritized

Changes (Unapproved)

Prioritized

Changes (Approved)

Prioritized

Product Backlog

Updated Prioritized

Product Backlog

Change 1

Change 2

Change 3

Change 2

User Story 1

User Story 2

User Story 3

User Story 1

User Story 2

User Story 3

Change 2

Watch out for the ‘Gotchas’Things to avoid

• Avoid long lists of acceptance criteria on a single

user story

• Prepare for conflicting requirements

• Avoid requirements that are ambiguous

• Avoid requirements that describe HOW

• Requirements must have a “reason”

• Avoid moving forward on development until after the

customer has reviewed the design

• Don’t forget to prioritize

How to Esri Manage this

Agile Cycle?

Using Agile in a Professional Services ProjectM

eth

od

Waterfall

Agile

Time

Meth

od

Waterfall

Agile

Time

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

Meth

od

Waterfall

Agile

Time

Using Agile in a Consulting Project

Meth

od

Waterfall

Agile

Time

Final Release

Using Agile in a Consulting Project

Managing Resources

Your Project

Plan A Plan B

Sprint

50%

75%100%

75%

50%

100%

100%

50%

Plan ZSprint

50%

75%100%

75%

50%

100%

100%

50%

50%

50%

50%

50%

50%

Keys to Successful Projects!

Communication

Utilize Available Tools…

Trusted Partnerships

Transparency

Tools

Waffle.io

Microsoft Team Foundation Server (TFS)

Requirement Management ToolsLicensed and Open Source

JIRA

Compare

There is a lot of info out there to help

http://assets.cdnma.com/13314/assets/Website

Downloads/2016-Seilevel-RequirementsTool-Evauation-

Report-FINAL.pdf

http://project-management.zone/system/jira,pivotal-

tracker,team-foundation-server,trello

https://businessanalystlearnings.com/technology-

matters/2017/7/4/a-list-of-free-requirements-management-

rm-software

Requirements and Stakeholders

THE most important part of a project

• Solid requirements gathering leads to successful projects

• Consider solution, COTS capabilities before collecting additional

requirements

• Involve the right people in the process

• Pick a methodology that fits your project

• Focus on the level of detail that is appropriate

• Important to prioritize and allocate

• Invest plenty of time to secure customer approval

Case Study

Case Study - Large Scale

Product Backlog

Sprint Planning

Sprint Backlog

Potentially Shippable

Product Increment

2 Week

Sprint

Scrum of Scrum

Master

The team

Retrospective

Daily Scrum

Stakeholders

Tech LeadProject Manager

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

~5 developers

1 tester

~7 developers

1 tester

~8 developers

1 tester

Contract Type $$ Value

FFP-LOE $20M

Customer Customer Customer Tech LeadTech Lead Tech Lead

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 features.

- Dependencies existed between scrum teams.

- Stakeholders (customers) were only present during Stakeholder Reviews and

were not active participants during the release planning events.

- Disconnected environment meant that the customer could not test the features

until the end of a release.

- Bi-weekly demonstrations to “sell off” features and to show progress.

Questions

Print Your Certificate of Attendance

Print Stations Located in 150 Concourse Lobby

Tuesday12:30 pm – 6:30 pm

Expo

Hall B

5:15 pm – 6:30 pm

Expo Social

Hall B

Wednesday10:45 am – 5:15 pm

Expo

Hall B

6:30 pm – 9:30 pm

Networking Reception

Smithsonian National Museum

of Natural History

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”

Please Share Your Feedback in the App