gao scheduling in an agile setting - karen richey

1

GAO Scheduling in an Agile Setting

September 11, 2014

Karen Richey

[email protected]

2

What is the Government Accountablity Office?

• Independent agency• Provides Congress with

audit, evaluation, and investigative services

• Headed by the Comptroller General, a non-partisan position in the government

• The Comptroller General is appointed by the president, by and with the advice and consent of the Senate, for a 15-year, non-renewable term

3

Outline

• What is a Schedule?• GAO Schedule Assessment Guide

• Overview• Status

• Agile Appendix• GAO Scheduling Best Practices• Best Practices & Agile

4

What is a Schedule?

• Specifies• When work will be performed• Completion dates for activities

• Key for managing• Program performance • Expected cost to complete

• Program success depends on it!

5

GAO Schedule Assessment Guide

• Develops scheduling concepts introduced in ‘GAO Cost guide’

• Draft published May 2012 www.gao.gov/products/GAO-12-120G

• Current Updates:• Figures• Schedule risk analysis• Appendix on ‘Agile Development Environments’

• Expected February 2015

• Gives GAO’s criteria for assessing a schedule’s credibility

• Indispensable for Agencies without a policy for creating schedules

http://www.gao.gov/products/GAO-12-120G

6

‘Agile Development Environments’ Appendix

Needed because:

• Many audits found no schedules for Agile IT projects

It will identify:

• Common misconceptions about scheduling for Agile projects and dispel them

Key Point: Agile measures progress through implementation of working software

7

GAO Scheduling Best Practices

• Research has identified ten best practices:

1. Capturing all activities2. Sequencing all activities3. Assigning resources to all activities4. Establishing duration of all activities5. Verifying that schedule can be traced horizontally & vertically6. Confirming that critical path is valid7. Ensuring reasonable total float 8. Analysis of schedule risk9. Updating schedule using actual progress and logic

10. Maintaining a Baseline Schedule (new)

8

The 10 Best Practices and Agile…

1: Capture All Activities?

• Roadmap with basic features (Must Haves) planned for project• Must-Haves• Should-Haves• Could-Haves• Nice-to-Haves

• Go no deeper that the ‘Release’ Level

• Show number of Sprints for each release

2: Sequence All Activities?

• Agile fixes time

• A steady team completes work

• Use Agile metrics to determine amount of working software from each Sprint:

• Daily standup meetings

• Completed stories

• Burndown charts, etc.

• Don’t monitor effort level within the Sprint

• Let the team self-organize

9


3: Assign Resources to All Activities?

• Since the development team is usually stable, let the team self-organize

• Allow scope to be variable

• Team size should be small (between 5-9 people)

• There can be several Sprint teams working in parallel

4: Establish Duration of All Activities?

• The time for each Sprint is fixed

• Tracking Sprints in a schedule means you are only monitoring level of effort • Releases will often have

longer durations (months) than the Sprint lengths (days/weeks)

10


5: Can Schedule be Traced Horizontally and Vertically?

• Horizontal Integration: Examine Sprint whiteboards showing what work has been done, is underway, and still to be accomplished

• Vertical Integration: Examine Sprint burn down charts to provide management and oversight and how this corresponds to work status for the release

6: Is Critical Path Valid?

• Logic of sequence of releases

• “Must-Haves” identified?

• Critical path of releases identified and tracked?

• Do not attempt a critical path below the release level

• Inspect Agile metrics to determine features & user stories for each Sprint

11


7: Ensure Reasonable Total Float?

• Float only expected to be monitored to Release level

8: Conduct Schedule Risk Analysis?

• SRA should be done at Release level but Agile approach will also address risk• Scope flexibility in Agile

manages schedule slippages• Agile feedback loops tighter so

risks tackled sooner & mitigated faster

• Sprint planning by the team ensure ability to deliver ‘Must-Haves’

12


9: Update Schedule Using Actual Progress & Logic?

• ‘Actuals’ tracked at Release level

• Within Sprints use actuals from: • Burn-down / burn-up charts• Number of story points

completed• Velocity

10: Maintain a Schedule Baseline?

• In an Agile setting we fix time and use a steady team

• Tracking Sprints in a schedule means you are only monitoring level of effort

13

You’re Invited…

• Please meet with us and other experts to discuss further updates to the Guide so that it continually reflects best practices

• Please e-mail:Karen [email protected]

mailto:[email protected]

14

Hand back to the APM in London…

14

15

Back-Up

16

Shared Values of Traditional and Agile Schedules

• Traditional: Processes and Tools• Agile: Individuals and interactions

• Traditional: Comprehensive Documentation• Agile: Working Software/Solutions

• Traditional: Contract Negotiations• Agile: Customer Collaboration

• Traditional: Following a plan• Agile: Responding to Change

17

Agile Background- Definition of Selected Terms

Term Definition Also called

Project Roadmap

High level view of the features the project will set out to accomplish along with the expected business value Project Vision

Release Plan Schedule for developing working software that identifies the expected number of Sprints and features that will be included in a release

Epics High level capabilities High level Requirements

Features Next level below an epic which represents items of specific business value. Some features may need several stories to be complete.

Capabilities

User Story Small chunk of software that identifies business value and success criteria that can be completed within a Sprint timebox. A user story defines the work to be done to satisfy a feature.

Story points Assessed value of effort for an epic, feature, or user story based on team consensus

Sprints short-term, timeboxed effort for delivering an agreed upon number of story points Iterations, increments

Product Backlog List of prioritized user stories identified as Must Haves, Should Haves, Could Haves and Nice to Haves Requirements backlog, feature list

Burn down Chart Burn down charts represent completed user stories and reflect the rate of progress over time. Can be compared to estimated number of stories to be completed during each Sprint for variance analysis.

Burn up chart

Retrospective Final review of what was accomplished during a Sprint and documentation of lessons learned (Agile team and customers/stakeholders attend)

Velocity The rate of progress accomplished by the team during a Sprint (measures number of story points delivered per Sprint to better estimate future work). Velocity reflects a team’s cadence and will vary among teams.

Cadence