Utilize Agile Project Management for GIS Projects Jennifer

  • Slides: 34
Download presentation
Utilize Agile Project Management for GIS Projects Jennifer Prather and Lana Tylka

Utilize Agile Project Management for GIS Projects Jennifer Prather and Lana Tylka

Agenda • Proposing Agile • Managing Agile • Case Studies

Agenda • Proposing Agile • Managing Agile • Case Studies

Proposing Agile

Proposing Agile

When would you use Agile? Waterfall Agile Staged Delivery Scope, Technology, Contract • Flexible

When would you use Agile? Waterfall Agile Staged Delivery Scope, Technology, Contract • Flexible scope, deliverables • One or several applications • Several applications • Prototypes expected • Clear requirements • Fixed deliverables • Single application Size, Duration • Any size or duration project • Medium or large size, mid to long duration • Small size, short duration project Capacity, Capabilities, Environment • Customer EXPECTS collaboration • Stable, experienced project team • Capacity, resources, and environment to support multiple releases • Limited capacity, resources, and environment • Frequent turnover on project team

Contract Type Order of Preference Situation T&M FFP Competitive 2 4 Sole source 1

Contract Type Order of Preference Situation T&M FFP Competitive 2 4 Sole source 1 3

Pricing

Pricing

Big Picture Epics System Architecture Database Design Widget 1 Widget 2 Application Hardening Story

Big Picture Epics System Architecture Database Design Widget 1 Widget 2 Application Hardening Story Points 21 34 34 55 21

Story Points 21 34 34 55 21 440 168 Hours 168 272

Story Points 21 34 34 55 21 440 168 Hours 168 272

Pricing Sheet Activity Scrum Master Product Owner Developer Analyst System Admin Total System Architecture

Pricing Sheet Activity Scrum Master Product Owner Developer Analyst System Admin Total System Architecture 16 16 0 16 120 168 Geodatabase Design 24 24 0 184 40 272 Widget 1 24 24 176 48 0 272 Widget 2 40 40 280 80 0 440 Application Hardening 40 16 84 24 4 168

Work Breakdown Structure System Architecture Database Design 1. 1 User Story 2. 1 User

Work Breakdown Structure System Architecture Database Design 1. 1 User Story 2. 1 User Story 1. 2 User Story Project Widget 2 Application Hardening 3. 1 User Story 4. 1 User Story 5. 1 User Story 2. 2 User Story 3. 2 User Story 4. 2 User Story 5. 2 User Story 2. 3 User Story 3. 3 User Story 4. 3 User Story 3. 4 User Story 4. 4 User Story Widget 1 4. 5 User Story

Managing Agile

Managing Agile

AGILE

AGILE

Development Cycle Scrum Master Product Owner Daily Scrum The team 2 - 4 Week

Development Cycle Scrum Master Product Owner Daily Scrum The team 2 - 4 Week Sprint Product Backlog Stakeholders Sprint Planning Sprint Backlog Retrospective Potentially Shippable Product Increment

As a [role], I can [feature] so that [benefit]

As a [role], I can [feature] so that [benefit]

As a field representative, I want to collect information offline so that data can

As a field representative, I want to collect information offline so that data can be collected in remote locations.

Product Backlog

Product Backlog

Wish List

Wish List

Sprint Backlog

Sprint Backlog

Sprint Backlog

Sprint Backlog

Sprint Backlog 4 h 8 h 3 days 2 h 1 h 2 days

Sprint Backlog 4 h 8 h 3 days 2 h 1 h 2 days 4 h 8 h

Managing Resources Plan A Plan B Plan Z Sprint Your Project 100% 50% 50%

Managing Resources Plan A Plan B Plan Z Sprint Your Project 100% 50% 50% 100% 75% 50% 100% 50% 50% 75% 50% 50% 100% 75%

Keys to Successful Sprinting! Communication Trusted Partnerships Transparency Utilize Available Tools…

Keys to Successful Sprinting! Communication Trusted Partnerships Transparency Utilize Available Tools…

Tools

Tools

Using Trello

Using Trello

Using Git. Hub

Using Git. Hub

Using TFS

Using TFS

Case Studies Example Projects

Case Studies Example Projects

Case Study – Medium Scale Contract Type $$ Value T&M $4 M Scrum Master

Case Study – Medium Scale Contract Type $$ Value T&M $4 M Scrum Master Product Owner Lead developer Analyst Daily Scrum The team 1 Week Sprint 12 developers 2 testers 1 PM Fluctuates as needed Product Backlog Stakeholders Customer’s PM Internal PM Sprint Planning Sprint Backlog Retrospective Potentially Shippable Product Increment

Case Study – Medium Scale • Why Agile? • • Customer was familiar with

Case Study – Medium Scale • Why Agile? • • Customer was familiar with Agile and believed iterations was the best method to get to realize their end goal Key Challenges / Lessons Learned Stakeholders (customer) was an active participant with respects to the grooming of the product backlog and sprint planning events. - Team consisted of contractors from multiple companies who were all using their own version of Scrum - Utilization of multiple contractors created dependencies that had to be accounted for in Sprint Planning. - Hours were used for estimates to avoid an inconsistent Points experience - Monthly iterations, then bi-weekly, then back to bi-weekly in order to get the right amount of feedback -

Case Study - Large Scale Release Manager Analyst Scrum Master Developer $$ Value FFP-LOE

Case Study - Large Scale Release Manager Analyst Scrum Master Developer $$ Value FFP-LOE $9 M Scrum of Scrum Master Lead developer Analyst Product Owner Contract Type Product Owner Analyst Scrum Master Developer Scrum of Scrums Product Owner Analyst Daily Scrum Master Developer The team ~7 developers 1 tester Sprint Backlog 2 Week Sprint Daily Scrum Sprint Backlog Product Backlog Sprint Planning Stakeholders Customer’s PM Project Manager Sprint Backlog Retrospective Potentially Shippable Product Increment

Case Study – Large Scale • Why Agile? Project was contractually required to follow

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?

Questions?

Please take our Survey Your feedback allows us to help maintain high standards and

Please take our Survey Your feedback allows us to help maintain high standards and to help presenters Find your event in the Esri Events App Find the session you want to review Scroll down to the bottom of the session Answer survey questions and submit