Breakthrough Portfolio Performance: Managing a Mix of Agile and Non-Agile Projects

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 ∙ sqeinfo@sqe.com ∙ 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

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:

Scott Ambler & Associates’ 2013 IT Project Success Rates Survey

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

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?

Technique Project Staggering

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

Delay Delay Delay

High resource utilization

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

Technique Focused, Single-Task Execution

Round # 1 Round # 2

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

Staggering + Single-Tasking

4 Project Completions

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.

Technique Elimination of Sprint-Level Commitments

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

Assuming an additional 33% speed improvement…

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.

Technique Buffering

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:

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

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

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

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.

Technique Portfolio Buffer Balancing

Project A

Project B Project C

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

Two identical tasks, only one person (or team) with the required skill

Project 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,

Technique Show All Buffers as Time-Based

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

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

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

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).

Contact Info: Michael Hannan, Founder & Principal Consultant Mike@FortezzaConsulting.com 301.520.0899

Breakthrough Portfolio Performance: Managing a Mix of Agile and Non-Agile Projects

Software

Breakthrough Copywriting

PowerPoint · PDF fileWinning formula 1 - Shared Values ... Primary 9 Secondary Education ... Strategic business acumen Agile Breakthrough performance

Agile And Toc - Can Oil and Water Mix

Breakthrough 12.04.2014

Championing Breakthrough Innovation - Home - AIMC · Championing Breakthrough Innovation. 2 Topics Overview of Breakthrough Innovation Process Breakthrough Innovation @ Disney - China

Master Thesis IIM Becoming Agile Norstedt&Karlsson · concept of agile. Agile project methods had its breakthrough in the software development industry and have since then spread

Breakthrough Session

Scrum.org W hitepapers... · management principles with Agile product development thinking, as a total outcome, will result in an even more powerful mix. I believe that Lean and Agile

Breakthrough Prayer Prayer for Breakthrough – Part 2

Breakthrough Drills

Mix it 2016 - Retour d'expérience agile - Ce qui compte c'est les valeurs

StreamInsight Breakthrough

Coach like a wizard: Agile wisdom of Gandalf (Mix-IT 2014 conference)

An Agile Pick-N-Mix

Propulsion Breakthrough

Breakthrough Listen

Breakthrough Planning

Agile Project Management with Scrum by Ken Schwaberdbmanagement.info/Books/MIX/Agile_Project_Management_With_Scru… · This document was created by an unregistered ChmMagic,

Agile, Software Engineering, Process Kaizen. They mix like oil and water ?

MEKONG CAPITAL A NEW E … · 20.05.2004 · journey KPI-linked bonus Systems agile A/B testing distribution Vision Driven Investing breakdown-to-breakthrough independent Directors