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
39
Embed
Breakthrough Portfolio Performance: Managing a Mix of Agile and Non-Agile Projects
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
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?
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
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
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
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.
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:
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.
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
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,
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
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).