Esri Best Practices: AGILE Project Management · •Why Agile?-Project was contractually required...
42
Esri Best Practices: AGILE Project Management Lana Tylka Jessica Schrage
Transcript of Esri Best Practices: AGILE Project Management · •Why Agile?-Project was contractually required...
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
