breakthrough portfolio performance: managing a mix of agile and non-agile projects
TRANSCRIPT
AT14 Agile Development Concurrent Session 11/13/2014 3:00 PM
"Breakthrough Portfolio Performance: Managing a Mix of
Agile and Non-Agile Projects"
Presented by:
Michael Hannan Fortezza Consulting
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073 888-268-8770 ∙ 904-278-0524 ∙ [email protected] ∙ www.sqe.com
The founder and principal consultant at Fortezza Consulting, Michael Hannan helps organizations achieve breakthrough improvements in their IT project portfolios. Mike has twenty-five years of experience as a consulting executive, IT project portfolio manager, and software engineer. He began his career at NASA, supporting large, complex initiatives such as high-performance computing and communications program. In a Big 4 consulting firm, Mike formed the first enterprise Java practice focused exclusively on serving public-sector clients and grew it into the company’s largest and most profitable project portfolio. Recently, Mike has focused on innovating high-powered techniques to dramatically improve IT project portfolio performance.
Presented at the Agile Development Conference - East
13 November 2014
2
Dilbert ©2014
PMI’s 2014 Pulse of the Profession: The High Cost of Low Performance: ◦ Only 56 percent of strategic initiatives meet
their original goals and business intent The Standish Group’s CHAOS Report:
3 Copyright © 2014 Fortezza Consulting, LLC
Scott Ambler & Associates’ 2013 IT Project Success Rates Survey
4 Copyright © 2014 Fortezza Consulting, LLC
Source: http://www.ambysoft.com/surveys/success2013.html
Typical project-level speed improvement: 30-40% Typical project-level reliability improvement: 10-80% Supporting project-level improvements in ◦ Accelerating scope refinement, which reduces rework ◦ Customer/stakeholder engagement, transparency, and trust ◦ …and more
But, a decidedly mixed track record at the portfolio level ◦ Hit-or-miss pattern of moderate successes and disastrous failures ◦ Competing value systems that lead to “binary resolution” ◦ Heavy-handed approaches for “Agile adoption” Highly specified enterprise approaches that mandate a “one-size-fits-all”
approach Knowledge gaps that call for sending everyone to training
5 Copyright © 2014 Fortezza Consulting, LLC
What drives a high rate of project completions? ◦ For a given level of productivity in my current resource pool, how do I
know what my optimal number of projects is? What drives high productivity at the task level? ◦ How can I maximize the flow of productive work? ◦ Can highly productive work be done without sprints? ◦ Are there aspects of sprints that harm productivity?
What drives project reliability? ◦ How do I know what buffering approach is best?
What drives portfolio reliability? ◦ How can I maximize the number of projects that finish within plan?
6 Copyright © 2014 Fortezza Consulting, LLC
Technique Project Staggering
7 Copyright © 2014 Fortezza Consulting, LLC
Three types of tasks, requiring three different resources: A – Planning, Scoping,
Prioritizing B – Architecting, Developing,
Integrating C – Marketing & Distribution
The sooner we start ….
Three simple projects
Seven weeks each
8
Delay Delay Delay
High resource utilization
Delay
9
10
P4
8 6
4
Simultaneous Projects
Staggered Projects
Typically delivers a 20-40% improvement in project throughput
Agile tenets are consistent with staggering, but staggering is not an Agile requirement; the organization must apply the necessary discipline to implement staggering
Executive stakeholders must be convinced that a project start date weeks or months in the future will result in an earlier finish.
Staggering helps expose hidden resource bottlenecks, identifying opportunities for resource balancing (more on this later!)
Individual efficiency must be subordinated to the goal of maximizing throughput
11 Copyright © 2014 Fortezza Consulting, LLC
Technique Focused, Single-Task Execution
12 Copyright © 2014 Fortezza Consulting, LLC
Round # 1 Round # 2
13
Dat
a po
ints
First round results with multitasking (108/122/172)
Second round results with
focus (55/70/112)
Time to complete
43% reduction
30 60 90 120 150
Note: Some content on this slide is property of NOVACES, LLC, and is used with permission 14
2σ ~ 90% 2σ ~ 70%
Staggering
A B C
Staggering + Single-Tasking
A B C
A B C
A B C
A B C
A B C
A B C
4 Project Completions
7 Project Completions
15 Copyright © 2014 Fortezza Consulting, LLC
Assuming a 35% speed improvement…
Potential speed improvements are typically 40% or more, and execution is more predictable and reliable.
Agile isn’t the only way to drive single-tasking, and simply organizing work into sprints does not guarantee single-tasking.
Monitoring the performance of task flow is crucial—Kanban approaches are increasingly popular, though we prefer the “Drum-Buffer- Rope” method.
There are many ways to drive single-tasking on your own, but executive support is critical. ◦ Executive “top cover” for single-tasking can accelerate its adoption
dramatically. ◦ Executive interruptions and expectations of multi-tasking will quickly
derail adoption of single-tasking.
16 Copyright © 2014 Fortezza Consulting, LLC
Technique Elimination of Sprint-Level Commitments
17 Copyright © 2014 Fortezza Consulting, LLC
Responsible scrum teams understand the inherent uncertainty in task execution, and build in appropriate buffers when committing.
Responsible scrum team members enjoy delivering early—much like a relay-race runner does—as long as they have the assurance that the organization is behind them if things don’t go so well.
Total = 40 days 5 Days 5 Days 5 Days 5 Days 5 Days 5 Days 5 Days 5 Days
5 Days 5 Days 5 Days 5 Days Total = 20 days
5 Days 5 Days 5 Days 5 Days Total = 30 days 50% Buffer
18 Copyright © 2014 Fortezza Consulting, LLC
A B C
12 Project Completions
19 Copyright © 2014 Fortezza Consulting, LLC
Assuming an additional 33% speed improvement…
A B C
A B C
A B C
A B C
A B C
A B C
A B C
A B C
A B C
A B C
A B C
Speed improvements are often as big as 2x, and execution is more predictable and reliable
Aggregating buffers at the project level pools project risk, just like an insurance policy does ◦ Scrum teams are already aggregating risk above the individual team member…this
further aggregates risk to the project level—which is primarily what the customer cares about anyway.
Eliminating task-level commitments encourages individuals and teams to deliver early, just like a relay race does
Once scrum teams have faith that there is a project buffer that will be there if they need it, they stop adding hidden buffers, and are free to focus on rapid execution
However, executives may still be tempted to cut it, so for this to work, they must be trained to protect it, not cut it.
20 Copyright © 2014 Fortezza Consulting, LLC
Technique Buffering
21 Copyright © 2014 Fortezza Consulting, LLC
In order to buffer against project uncertainty, the Triple Constraint Rule says that we can hold fixed at most two of the three standard project constraints:
$
22 Copyright © 2014 Fortezza Consulting, LLC
A traditional “waterfall” project typically has a “management reserve” schedule buffer at the end of the project
Phase 1
Phase 2
Phase 3
Schedule Buffer
Project Due Date
23 Copyright © 2014 Fortezza Consulting, LLC
Agile projects serve as a good example here—they typically have “backlogs” of tasks that include lesser-priority software features that users would like to have, but can live without.
Sprint 1
Sprint 2
Sprint 3
Sprint 4
“Must Have” Features
“Nice-to-Have” Features
Project Due Date
24 Copyright © 2014 Fortezza Consulting, LLC
This is what I call the “Olympic Stadium” type of project ◦ The schedule is absolutely fixed ◦ The scope is almost absolutely fixed ◦ Budget is the only available buffer
Task 1
Task 2
Task 3
Project Due Date
25 Copyright © 2014 Fortezza Consulting, LLC
The buffer type(s) selected must align with customer needs and preferences. ◦ A scope buffer is not always the best.
Buffer levels must be ample—typically one day of buffer for two days of focused, productive work effort.
Conserving and protecting project-level buffers is everyone’s job, at all levels.
26 Copyright © 2014 Fortezza Consulting, LLC
Technique Portfolio Buffer Balancing
27
Project A
Project B Project C
Copyright © 2014 Fortezza Consulting, LLC
15 Days 10 Days 15 Days 10 Days 10 Days 10 Days
15 Days 10 Days 15 Days 10 Days 15 Days 10 Days 10 Days 10 Days 10 Days
Project A
Project B
Today
Two identical tasks, only one person (or team) with the required skill
Project Buffer
Project Buffer
28
A
B
29 Copyright © 2014 Fortezza Consulting, LLC
A B
30 Copyright © 2014 Fortezza Consulting, LLC
Simply uses project-level buffers as portfolio reliability assets as an effective way to focus Portfolio Governance
Fosters a strong “unity of purpose” among Executives, PMs, Scrum Masters, and Team Members ◦ This can help accelerate Agile adoption enterprise-wide, extending
the strong team emphasis from the Scrum Team to the entire organization
Encourages “relay race” behavior, with all Team Members looking to increase, conserve, and protect buffers at every opportunity ◦ This further enhances Agile’s emphasis on velocity
Complements Staggering, Single-Tasking, and Eliminating Sprint-level Commitments,
31 Copyright © 2014 Fortezza Consulting, LLC
Technique Show All Buffers as Time-Based
32 Copyright © 2014 Fortezza Consulting, LLC
Project managers tend to prefer a schedule view—such as a Gantt chart—to depict a logical flow of execution over a defined project duration
Project managers intuitively know how to translate between budget, scope, and schedule ◦ For example, we might “buy schedule” by
increasing budget or sacrificing scope If we can translate budget and scope into schedule, then
we can also show all project’s buffers—whether budget, scope, schedule, or some combination of the three—as time-based
33 Copyright © 2014 Fortezza Consulting, LLC
Task 1
Task 2
Task 3
Schedule Buffer Sprint 1
Sprint 2
Sprint 3
Sprint 4 Scope Buffer Task 1
Task 2
Task 3
Project Due Date
Budget Buffer
34 Copyright © 2014 Fortezza Consulting, LLC
In order for IT executives to optimize the reliability of their project portfolios, buffers must be visible, and represented in an “apples-to-apples” manner
Not all IT projects are well-suited for Agile, so it is important to maintain “right tool for the job” flexibility in project methodology ◦ Many attempts at “Agile Transformation” have failed because of
overzealous attempts to mandate Agile for all IT projects Showing all buffers as time-based is usually the most intuitive for
executives, project managers, and team members ◦ Agile’s velocity-based approach can easily be translated into time-based
buffering Helping one project by using buffer from another is simple and
straightforward
36 Copyright © 2014 Fortezza Consulting, LLC
Fortezza Consulting’s free newsletter (www.FortezzaConsulting.com/stay-connected)
Fortezza’s blog (www.FortezzaConsulting.com/blog)
My new book! I’ll be signing discounted copies immediately afterwards in the Grand Foyer (next to the bookstore). Copies are also available at the conference bookstore, and on Amazon (hardcover, paperback, and Kindle versions).
37 Copyright © 2014 Fortezza Consulting, LLC
Contact Info: Michael Hannan, Founder & Principal Consultant [email protected] 301.520.0899