© grant thornton llp. all rights reserved. 1 p roject d elivery s ummit 2015 s ession 11 p art 2: a...

© Grant Thornton LLP. All rights reserved.1

PROJECT DELIVERY SUMMIT 2015SESSION 11

PART 2: AGILE PROJECT MANAGEMENT IN THE PUBLIC SECTOR


FACILITATORS

Brian ReynoldsPrincipalPMP | PgMP | CSSBB | ITIL | SMC | SPC | ACPT (direct) 703.837.4415T (mobile) 571.482.0293E [email protected] W www.grant.thornton.comwww.grantthornton.comLinkedin: http://www.linkedin.com/in/BrianKReynolds

Graeme FinleyManaging DirectorT (direct) 916.449.3991T (mobile) 571.242.0478E [email protected] W www.grant.thornton.comwww.grantthornton.com

http://www.grant.thornton.comwww.grantthornton.com/

http://www.linkedin.com/in/BrianKReynolds

http://www.linkedin.com/in/BrianKReynolds


DISCUSSION TOPICS

• Why Agile

• Introduction to Agile

• Agile and the PMBoK

• Agile Planning and Estimation

• Agile Procurement and Contracting

• Transitioning from Waterfall to Agile


WHY ARE WE TALKING ABOUT AGILE?


IT CHALLENGES

17%1

are over budget, behind schedule or don't meet user expectations

40%2 fail and are either

or started anew

only

6.4%1

abandoned

52%2

of large IT projects are successful

56%1large IT projects deliverless value that predicted

lengthy IT projects frequently incur cost overruns and schedule slippages while contributing little to mission-related outcomes3 too often they have become risky, costly, and unproductive mistakes4

more than

threaten the company's existence

1 McKinsey & Company Study, conducted in collaboration with the University of Oxford, based on 5,400 projects with initial budgets in excess of $15M2 Standish Group study conducted for ComputerWorld, based on 3,555 projects between 2003 and 2012 with labor costs in excess of $10M 3 1 GAO-12-745T: IT Reform: Progress Made: More Needs to Be Done to Complete Action and Measure Results.4 GAO-12-681: Agile Effective Practices and Federal Challenges


SUCCESS TIED TO DURATION

data taken from study of 23K projects in 2009, based data presented by Stephen W. Warren, Executive in Charge, Office Information Technology, Department of Veterans Affairs, presented 2014 CIO Bootcamp, Washington D.C., June 19, 2014; study lead to adoption of Project Management Accountability System (PMAS), based on Agile methodology

data taken from Technology Industry Findings and Implications, PwC Technology Institute, August 2014; chart titled: Why IT initiatives fail for technology companies


WHY TURN TO AGILE?

92%1

report improved ability to manage changing priorities

87%1

report improved productivity

report improved project visibility and team morale86%1

73%1

report faster project completion

82%1

report improved quality and reduced risk

1 8th Annual State of Agile, Version One, survey of 3,500 members of the software development community, 2013


THE BUSINESS CASE FOR AGILER

OI /

Val

ue

RO

I / V

alue

Time

Waterfall Agile

Value

Risk

ROI


INTRODUCTION TO AGILE


WHAT IS AGILE?

• Agile breaks a project into small units of functionality called user stories, prioritizing them, and delivering them in short cycles called iterations

• Agile is based on the following principles:

Individuals and interactionsWorking softwareCustomer collaborationResponding to change

Processes and toolsComprehensive documentationContract negotiationFollowing a plan

More

Emphasi

s Less

Emphasi

s

While there is value in the items on the right, we value the items on the left more. - http://www.agilemanifesto.org

Agile is a time-boxed, iterative approach to software delivery that builds software incrementally, instead of trying to deliver it all at once


WHEN TO USE AGILE?Where uncertainty is high, products cannot be totally defined up front – when least is know; iteration and feedback is required to balance feature, resource, schedule decisions; a learning system is needed to deliver complex products, like software

Predictive

efficiency focusactivity-drivenchange unwelcome

uncertainty

Adaptive Reactive

Waterfall Scrum/XP/… Kanban

rapid change focusvalue-drivenchange expected

work-in-process focushandles unpredictability

Agile applied

lowhigh


HOW DOES AGILE WORK?

Make a List

Identify the capabilities (features, stories) your customer might want to implement and list these in the backlog

Estimate Size

Estimate the amount of work required to deliver each of the capabilities – derive schedule/cost from work estimate

Set Priorities

Considering dependencies, identify the most important capabilities, reorder list based on priorities

Plan and Commit

Conduct task–level planning, determine how much work can be accomplished in the timebox and commit

Execute Iteration

Implement, test, and demonstrate potentially shippable, working software that is valued by the customer

Inspect and Adapt

Measure key performance indicators, analyze, and identify small, incremental, needed process improvements

Update Plan

Review unfinished items on list, plan what work and how much work should be taken on next

1

2

3

4

5

6

7

>>

>

>

Agile provides early visibility into progress; this facilitates customer collaboration, early course corrections, reduced WIP, and products that are fit-for-purpose


THE AGILE (SCRUM) PROCESS

Sprint Review

Backlog Grooming

Sprint Planning

Daily Standup

Sprint

ProductBacklog

DeliveredProduct

2

3

4

1

Sprint Time Box

Retro-spective

5


WHEN IS WORK READY AND DONE?Define 'Ready' and 'Done' to ensure that stories are complete and understood, before code/test begins; and implemented correctly, before code/test ends


HOW IS AGILE DIFFERENT?Agile uses progressive elaboration, iteration, product demonstration, and customer feedback to accelerate value delivery

Waterfall assumes that stakeholder influence occurs up front and then declines throughout the rest of the project. With Agile, stakeholders are involved daily, throughout the project lifecycle

Value Value Value

ValueWIP WIP WIP

Value Value

Requirements

Design

Develop

Test

Wat

erfa

llA

gil

e

Pre

dic

tiv

eA

dap

tive


HOW DOES THE TEAM CHANGE?Agile success often requires change management and a rethinking of roles; delivery of customer value, not completion of functional responsibilities, is focus

Agile Teams

Functional Teams

Test

Code

Design

UX/UI

Requirements

• Silos• Specialized• Hand-offs• Responsibility• High WIP• Command / Control• Task Focused• Idle-Worker Focus• Large-Batch

• Collaboration• Cross Functional• Common Goal• Accountability• Constraint Driven• Self-Organized• Value Focused• Cost-of-Delay

Focus• Short Cycle Times

From… To…


AGILE AND THE PMBOK

© Grant Thornton LLP. All rights reserved.

PROJECT MANAGEMENT BODY OF KNOWLEDGE47 Processes organized within 10 Knowledge Areas and 5 Process groups

A: PMBOK® describes 'what should be done during the management of a project'… Agile methodologies describe ‘how to do the things that should be done’ – in short, ‘what versus how’.

Q: Is the PMBOK® Agile?


INTEGRATION AND SCOPE MANAGEMENT

Traditional / Phased Agile

Managers develop Project Management Plan and related sub-plans

Team develops and refines Release, Iteration, and Sprint Plans

Managers execute formal change control process and documentation

Team progressively elaborates backlog and manages changes daily


Team defines requirements needed to meet the project objective(s) at beginning

Team progressively elaborates and iteratively prioritizes Product Backlog

Managers create a work breakdown structure (WBS) that defines deliverables

Team progressively elaborates backlog and develops release and iteration plans

Comparison of Predictive (Waterfall) and Adaptive (Agile) Practices

unwelcome expectedCHANGE


TIME AND COST MANAGEMENTComparison of Predictive (Waterfall) and Adaptive (Agile) Practices


Managers estimate cost to complete project work activities and deliverables

Team derived duration and cost from work estimates; Cost, not scope, is fixed

Managers aggregate estimated costs to establish an authorized cost baseline

Team and costs are stable; costs derived from work estimate and velocity


Managers identify activities and durations needed to produce deliverables

Team progressively defines features, epics, stories needed for product

Managers estimate durations to establish an authorized schedule baseline; activity completion is focus of schedule

Team derives schedule from work estimates; velocity drives schedule; value delivery is focus of schedule

estimated derived

COST / SCHEDUL

E


QUALITY MANAGEMENT


Quality control techniques, like checklists and lessons learned, used to eliminate quality issues

Quality control is built into the product development process; Definition of Ready and Done help ensure quality

Monitor results of project activities to assess conformance and performance

Quality of the real, emerging product, not just project artifacts, is verified iteratively

Comparison of Predictive (Waterfall) and Adaptive (Agile) Practices

When cost overruns or schedule delays require scope reductions, which model delivers more value and better quality?

Deadline


AGILE PLANNING


PREDICTIVE PLANNINGPredictive approaches attempt to define precise performance measurement baselines (PMB) at the beginning of the project. What could go wrong here?

Develop Work Breakdown Structure

Project

Work Package 1

Work Package 2

Work Package 3

1 2

Work Package 4

Use Critical Path Method to Define Network Path

Work Package 2

Work Package 1

Work Package 4

Work Package 3

Work Package 2

Work Package 1

Work Package 4

Work Package 3

D: 2w

D: 4w

D: 6wD: 4w

3 Identify Work Product Deliverables, Cost, and Schedule

C: $4

C: $10

C: $8 C: $13

4 Define PMB (the triple constraint)

based on PERT, analogous, bottom-up, expert judgement or other technique; should be based on resource loaded task and activity work plan

PMB

decomposed into deliverables and schedule activities used as basis for estimating

Control accounts, planning packages not shown


PREDICTIVE PLANNING ASSUMPTIONSPredictive approaches are based on four key – seemingly flawed assumptions – that are the root cause of many cost overruns and schedule delays

"…changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed…"

-- study of 1,027 IT projects in the United Kingdom, reference Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises

Assumptions :

1. There exists a reasonably well-defined set of requirements, if only we take the time to understand2. During development, requirement changes will be small enough that we will not need to revise plans3. We can predict how well system integration will go based upon up-front architecture and planning4. Software R&D required to innovate can be done on a predictable schedule

source

http://michaellant.com/2010/05/18/how-to-make-your-project-not-suck/


THE IRON TRIANGLE / TRIPLE CONSTRAINTSome aspects of solutions are unknowable and can't be accurately planned up-front; using Agile, delivery of value is the focus, not adherence to an up-front plan

SCOPE

SCHEDULECOST SCOPE

SCHEDULECOST

COMMITMENT

ESTIMATE

ADAPTIVE(VALUE DRIVEN)

PREDICTIVE(PLAN DRIVEN) refined via communication,

demonstration, feedback, iteration, and working software

defined up-front, often specified via elaborate documentation

If cost and schedule are to be treated as commitments, we must treat scope as an estimate and expect some change


BENEFITS OF ADAPTIVE PLANNINGAgile acknowledges that we cannot totally define the product up front – when we know least; iteration is required to balance feature, resource, schedule decisions

Characteristic Predictive Adaptive

Focus Activity Feature / Value

Estimate Cost, Schedule Work, Job Size

Commitment Scope Cost, Schedule

Change Unwelcome Expected

Assignment In-Advance Just-In-Time

Quality Check Missing Activities Missing Features

Progress Activity Completion Value Delivery

Priority Resource Availability Customer Value

Scope Reduction Remaining Activities Least Valuable

Activity-based Plan Overruns Causes:

• Activities don't finish early• Lateness passed down schedule• Activities are not independent• Multitasking increases cycle times• Precise estimates on uncertain work• Estimates become commitments

Agile planning assumes Agile team members will:• work collaboratively towards goal• work in short, consistent iterations• deliver demonstrable value each iteration• prioritize work and deliver highest value first• inspect, adapt, continually improve

Agile Planning Fundamentals:

• Iterative, uncertainty recognized• Multi-Level: Release, Sprint, Story• Work, job size estimated• Estimates are relative• Cost/Schedule = Job Size / Velocity

based on ideas presented in Agile Estimating and Planning by Mike Cohn


SCALED AGILE FRAMEWORKA proven framework for applying Lean and Agile practices at enterprise scale; synchronizes collaboration and delivery effort for large numbers of teams


AGILE LEVELS OF PLANNINGLarge-scale Agile planning efforts rely on five planning levels to overcome need for large upfront investment in analysis and design common in predictive approaches

Uncertainty decreases as the planning horizon is shortened across planning levels

Therefore, planning detail can be increased without running the risk of expending resources on features that may not be built or may be built differently

Long-term plans are coarse-grained, feature-based; short term plans fine-grained, story- and task-based

Detail

Predictability


AGILE PLANNING CADENCEInstead of attempting to develop a detailed plan for the entire project up front, Agile uses incremental planning techniques to incorporate feedback and change

Week 4 Week 6 Week 8 Week 10 Week 12 Week 2 Week 4 Week 6 Week 8 Week 10Week 0 Week 2

I1 I2 I3 I4 IP I1 I2 I3 I4 IPIP0

• Priority features are delivered via iterations comprised within Program Increments (PI)

• Each PI has a uniform length of 10 -12 weeks and can be aligned with releases

• PIs comprise ~4 development sprints and 1 Innovation and Planning (IP) sprint

• Each PI delivers a set of demonstrable and potentially releasable features

• PI length informs and constrains the size of features we plan to deliver

• IP sprints used to plan upcoming PI, to execute spikes, and perform refactoring

PI 1 PI 2


Release 1 (384pts) Release 2 (384pts) Release n (384pts)

AGILE PLANNING PROCESSThe Agile plans provide basis of a PMB and are developed incrementally, and iteratively, instead of trying to develop precise estimate for entire effort up-front

Develop Program Backlog

Feature 1

1 2 Develop Roadmap

aim for max size of 4 sprints of work

30pts

3 Develop Release Plan 4 Develop Iteration Plan

Feature 2

Feature 3

Feature 4

Commit Plan

Feature 1

Feature 4

Feature 3

Feature 2

Feature n

Feature 5

Prio

rity

65pts

30pts

75pts

40pts

80pts

45pts

45pts

75pts

Team Iteration 1.1 Iteration 1.2 Iteration 1.3 Iteration 1.4

Feature 1

Feature 4 Feature 3

48pts/Int

48pts/Int

Feature 2

Feature 5

45pts

40pts 40pts

35pts 40pts

40pts 35pts

Feature 5 75pts

Feature 6

Feature …

Feature …

Feature …

Feature …

Feature …

Feature …

……

45pts

CapacityLoad

96pts85pts

96pts75pts

96pts80pts

96pts80pts

Team Iteration 1.1 Iteration 1.2 …

48pts/Int

…

CapacityLoad

1 8

5

3 5

3 16 2

3 48pts46pts

CapacityLoad

48pts43pts

user story defect infrastructure spike

*at conclusion, revise feature estimates

Release 1 (Capacity 320pts)


FEATURE BUFFERSFeature buffers provide a margin of error around a scope estimate; they are useful when there is significant uncertainty or the cost of plan errors is significant

Feature Buffering (performed when building Roadmap):

Programs where Agile buffers are useful:

1. Planned far in advance

2. Must meet a firm deadline

3. Must commit to substantial functionality

4. Is contracted between organizations

5. Requirements understanding is superficial

Buffering is a risk management strategy; that protects the program against the impact of uncertainty

1

2

Release 1 (320pts)

Feature 1

Feature 2

Feature 3

Feature 4

80pts

45pts

45pts

75pts

Feature 5 75pts

feature buffermandatory

3

4

Size features that are candidates for release at 50% confidence (we will add a Schedule Buffer – next slide -- to address this)

When building roadmap, identify mandatory features representing ~70% of release capacity… this is the release minimum viable product (MVP)

Select additional features representing ~30% more work; this is the feature buffer, the nice-to-have features

Add MVP estimates to the buffer estimates, the result is a total estimate for release features


AGILE ESTIMATION


PRODUCT BACKLOG

• Progressive elaboration used to disaggregate work as delivery approaches; this minimizes Work in Progress (WIP) and allows lessons learned and changing priorities to be considered

• Disaggregation improves understanding and estimation. Large things are hard to estimate; margin of error is larger when estimating large units of work

Agile backlogs are a prioritized inventory of features, epics, user stories, spikes, and defects, intended to deliver business need and the value of the solution

Long-term, Course Grained

Near-term, Fine Grained

Feature

Epic

Story

Insert

Reprioritize

Disaggregate

Delete

Backlog Uncertainty

+ -


STORY ESTIMATION AND VELOCITYWhen using an Agile method, work and velocity is estimated and duration is derived

When planning development, we ask:• “What can we complete?” • “When will we be done?” • “How much will this cost?”

To answer these questions, we:• Estimate size of what we are building• Measure work completion rate (velocity)• Derive development duration / cost

Work: 500 lbs. of Stone to move Capacity: 50 lbs. / Trip Time: 200 minutes(10 trips * 20 minutes / trip)

Backlog Velocity Duration


STORY POINT ESTIMATIONStandardized story point estimation allows the Agile team to set realistic sprint goals, plan work in accordance with velocity, and quantify accomplishments

Story Size Estimation

• Stories disaggregated until sprintable

• Size estimated in story points: 1,2,3,5,8 (Fibonacci)

• Distribution indicates that uncertainty grows with size

• Factors: volume, complexity, knowledge, uncertainty

• Stories sized relative to one another by team

Technique for Normalizing Story Sizing:

1. Find a small story – one that would take about a day to code and test.

2. Assign 1 story point to this story.

3. Estimate every other story relative to this story.

This establishes an estimating framework that defines "how big" a story point is; using

this technique, each story point requires ~one day of one FTEs time

Stories

2pt 3pt 5pt 8pt

Stories sized relative to each other

Different team might estimate story sizes differently

8pt

5pt

3pt

2pt

1pt


SMALLER IS BETTERThere is direct relationship between Throughput, Lead Time, and Inventory (WIP); we use these relationships to drive performance improvements

Story size: 32 -- takes longer the complete; delivery of entire batch delayed because last 8 units not ready at end of iteration; delivery of value is delayed; WIP is increased; Throughput is jeopardized

Story size: 8 -- takes shorter period the complete, delivery of value is shortened; delivery of 3 of 4 stories recognized as Throughput; testing coverage better in this scenario, as stories not delivered at late in iteration

Large Stories

Small Stories


VELOCITY ESTIMATIONStandardized story point estimation allows the Agile team to set realistic sprint goals, plan work in accordance with velocity, and quantify accomplishments

Velocity: the sustainable rate at which Agile teams consistently deliver business value

Team Velocity Estimation (Fast start)

• Assume 8 points can be delivered by each FTE/iteration, subtract one point for every team member vacation day and holiday (e.g. 1 point/day * 10 sprint days * 80% utilization)

• Example: 7 person team (4 developers, 2 testers, 1 product owner), with no non-working days, the estimated velocity would be 6 * 8 = 48 points/iteration.

Best estimated using historical performance data

Should not be used to compare the performance of different teams

590

500

410

320

230

140

50

Velocity = 90 pt. / iteration


FORECASTING ACCOMPLISHMENTSTrack backlog dynamics, defect density, and velocity to forecast duration, encourage needed productivity gains, and plan releases

• FV of an annuity equation calculates how much a stream of payments (PMT) will be worth at a specified time in the future.

• Substituting velocity for PMT and average productivity increase for i, we forecast how much work will be accomplished within a specified number of sprints

• When considering amount of remaining work, use backlog dynamics and defect density to incorporate anticipated work, not currently in backlog


AGILE METRICS


INSPECT AND ADAPT (I&A)Measurement drives action and focus; to realize measurable agile performance improvements, use inspect and adapt metrics to focus improvement efforts

Core Management Measures• productivity (velocity)• predictability (sprint plan variance)• unplanned work (defect density) • integrity (test case coverage/execution)

Backlog Management Measures• backlog dynamics (growth, change)• backlog points by story type/state

Defect Measures• open defect aging, by priority• defect closure duration, by priority• defect open/close trending• defects found by/found in (environment)• % stories w/ defect

Quality Assurance Measures• test case pass/fail/no result• % test cases automated

Planning Measures• actual hour range & std deviation per story• average plan & actual hours per story size• average plan & actual hours per accepted point• % points split (pushed to subsequent sprint)

Efficiency Measures• velocity % increase / decrease• actual hours per task/task type

Product Flow Measures• work utilization – actual hours /accept duration• acceptance slack, by story size• average story size / sprint


I&A EXAMPLE: PRODUCTIVITYInspect and Adapt metrics provide insights into needed performance improvements


I&A EXAMPLE: PREDICTABILITYInspect and Adapt metrics provide insights into needed performance improvements


I&A EXAMPLE: STORY EFFORTInspect and Adapt metrics provide insights into needed performance improvements


I&A EXAMPLE: DEFECT TRENDSInspect and Adapt metrics provide insights into needed performance improvements


I&A EXAMPLE: CONTINUOUS FLOW Inspect and Adapt metrics provide insights into needed performance improvements


I&A DRIVEN IMPROVEMENTMeasurement drives action and focus; to realize measurable agile performance improvements, use inspect and adapt metrics to focus improvement efforts

reduced results

delayed story completion

large stories

rushed in-sprint testing

defects not detected/ fixed in-sprint

delayed story completion

RC

RC

RC

RC


I&A AND THROUGHPUT ACCOUNTINGThroughput Accounting focuses on delivering value by improving the efficiency at which Investments are converted to Throughput; Metrics are key.

Throughput: improved productivity, in the Lean vernacular, helps teams "focus on value"

Investment: reduced inventory leads to shorter lead Times and improved ROI

• Productivity, measures velocity at which Agile process is delivering valuable software; should be measured and improved throughout the project

• Unplanned Work, which measures defect density of delivered software; effort spent on defect remediation increases Operating Expenses and does not contribute to Throughput

• Integrity, a predictive indicator of defect occurrence that measures test case coverage and degree to which software conformance to requirements has been validated

• Predictability, measures iteration variance, this is the team's "Say-Do Ratio;" where predictability is low, iteration commitments are not being met and Investment (WIP) is increased

• Story Size, which the average size of stories scheduled within an iteration; larger stories are converted to working software more slowly (e.g. have longer Lead Times), this increases WIP and threatens Throughput


AGILE PROCUREMENT


NOT NEW TO GOVERNMENTAgile delivery models align with government IT policies and recommendations

"only approve funding of major IT programs that… use a modular approach with usable functionality delivered every six months"

25 Point Implementation Plan to Reform Federal IT Management, 2010

"agencies should… consider breaking large acquisitions into smaller, more manageable segments or modules. each module should be economically and programmatically viable (i.e., useful) "

Capital Programming Guide, OMB Circular A-11, July 2013

"… adopt a modular approach that combines controlled system development with rapid prototyping techniques" … projects should be as "narrow in scope and brief in direction as possible to reduce risk"

Capital Programming Guide, Appendix II, OMB Circular A-11, July 2013

"officials who have used Agile methods on federal projects generally agree that these practices are effective"

GAO-12-681 – Effective Practices and Federal Challenges in Applying Agile Methods, July 2012

Agile-consistent critical success factors:

• actively engaged stakeholders

• end users and stakeholders are involved

• program staff prioritized requirements

• end users tested functionality prior to UAT

• regular communications between program and contractor

GAO-12-7 – IT Critical Factors Underlying Successful Major Acquisitions, 2011


AGILE ACQUISITION MODELDefense Science Board, a federal advisory, provides independent advice to DoD; in March 2009 recommended a Strategic Acquisition Platform based on Agile ideals


CHALLENGES USING A TYPICAL CONTRACT STRUCTURE FOR AGILE• Nontraditional SDLC

– Design, Development, Testing occur continuously– License cost may be unknown because buyer is typically procuring

services in support of functionality rather than an end software product

• Requirements Uncertainty– Requirements are variable prior to, and throughout, project– FFP has fixed schedule, cost, and scope– Fixing scope in Agile inhibits the team's ability to deliver value that

meets changing needs– Requirements uncertainty coupled with FFP places undue risk on

contractors who will charge a price premium to compensate for risk


EXAMPLE: TIERED FIXED-PRICE MENU

Line Item

Description of Services

POP Type Quantity Unit Unit Price Price

0001 Discovery & Stabilization

3 Mos. T&M x HoursVendor Proposed Hours,

& Rates$______

Not to Exceed$ (specified in

RFP)

0002 Release 3 Mos. FFP 6 Sprint $______Not to Exceed

$_____


$_____


$_____

0005Non-

Development Activities

12 Mos. T&M x HoursVendor Proposed Hours,

& Rates$______

Not to Exceed$ (specified in

RFP)

TOTALNot to Exceed$ (specified in

RFP)


PROCUREMENT CONSIDERATIONS

• Expectation for use of Agile approach should be explicit.

• Without detailed requirements, procurement needs to focus on service provider, not solution, quality. Prototyping sometimes used as part of evaluation process.

• Contract cannot assume fully defined scope, schedule and cost at contract award.

• Product Vision important to define scope – provides basis for determining that requirements changes are still within scope.

• Baseline metrics (e.g., velocity, delivery efficiency) very important as gauge of vendor productivity.

• RFP should include 'Definition of Done' and require bidders to describe how they will manage quality and performance.


ROLES AND RESPONSIBILITIES


• Project Manager• Development Team• Contracts Manager

• Project Manager*• Scrum Master• Scrum Team• Contracts Manager


• Project Manager• Customers• CO Representative• Contracting Officer

• Project Manager* • Product Owner• Agile Coach• Users/Customers• CO Representative• Contracting Officer

Contractor Team

Government Team

*Depending on the scope of the contract, Project Managers may be needed to manage cost, scope, and schedule of the overall project.

Customers

ProductOwner

Contractor

COR

CO


NOT JUST ABOUT DEVELOPMENT

• Focus is often on software development process, but all the traditional elements of the full system development lifecycle remain important:

– Business process reengineering

– Organizational change management

– Training

– Project management

• In addition, contract assistance may be required with other processes:

– Planning (Roadmap, Release Plans)

– Requirements (Backlog development and grooming)

– Agile coaching/oversight


TRANSITIONING TO AGILE


CONSIDER GOV'T RECOMMENDATIONSGAO identified effective practices and approaches for implementing Agile as well as the challenges agencies generally encounter


RETHINK RESPONSIBILITIESStakeholder involvement during Agile delivery goes beyond requirements definition and user acceptance, Product Owners are responsible for prioritization

Phase Product Owner Responsibilities (Scrum)

Initiate Phase (a) Define Project Vision(b) Identify Stakeholders(c) Develop Epics, Features, Personas(d) Prioritize Product Backlog(e) Define "Done" Criteria(f) Create Release Planning Schedule

Plan and Estimate Phase

(g) Create and Elaborate User Stories(h) Define User Story Acceptance Criteria(i) Prioritize Users Stories in Product Backlog(j) Determine User Story Readiness (Approval)(k) Clarify User Stories during Task Planning(l) Clarify Requirement during Sprint Backlog Creation

Implement Phase (m) Clarify Requirement during Development(n) Groom Prioritized Product Backlog

Review and Retrospective Phase

(o) Determine Deliverable Done (Accept/Reject)(p) Update Product Backlog per Deliverable Status(q) Update Release Planning Schedule

Release Phase (r) Approve Release Deployment (s) Communicate Release to Stakeholder

• Involve business units: OCIO issued and managed integrator contracts can lead to confusion, as Product Owners within business units set priorities

• Clearly define roles: Use RACI matrices, or similar, to reduce confusion about responsibilities, especially where non-standard Agile roles (PMs and Coaches) are concerned

• Value conversation: business unit collaboration is important; limit use of intermediaries, who reduce direct interaction between developers and Product Owners

• Plan together (Hoshin Kanri): Align OCIO and business unit goals, plans, and commitments; limit predictive plans, where adaptation is needed

• Pursue DevOps: improve IT collaboration where functional silos undermine Agility


USE AGILE COACHES

establish teams

train teams establish tools and metrics

coach teams, as servant leaders

execute, inspect, and adapt through kaizen

promote adoption and scale proven practices

1

23

45

6

• Establish teams at the project-, product-, and portfolio-level• Make sure team members understand roles and responsibilities• Train teams to make sure they are prepared to execute• Establish governance for coordinating teams • Oversee management of information with the ALM tool• Establish program and project management controls

• Help groom and prioritize product backlog items• Assist with work planning and estimation• Provide release planning guidance and support• Use inspect and adapt metrics to identity needed improvements• Work to establish a team-culture of shared accountability • Promote focus on Kaizen (good change)• Promote adoption of effective practice across the organization


CRITICAL SUCCESS FACTORS FOR ADOPTION OF AGILE (From 2015 Grant Thornton State CIO Survey)


QUESTIONS ANDTHANK YOU!

Brian ReynoldsE [email protected]

Graeme FinleyE [email protected]

© grant thornton llp. all rights reserved. 1 p roject d elivery s ummit 2015 s ession 11 p art 2: a...

Documents