Help: My Teams Are Agile But My Execs Are Waterfall! (Part 2)

Posted by Steve Elliott on Nov 5, 2015 5:00:00 AM

execs are waterfallIn our last post we framed an approach that PMOs and Program Managers should take when caught in between waterfall planning and agile execution. Tactical questions you may have include:

  • How can we start to link strategy to execution if we are agile at the team level but still follow a more traditional waterfall-style strategic planning process? 
  • How do we begin to marry our scaled agile process (think SAFe, DaD or Less) to our executive level strategic planning in order to take a value driven approach? 
  • Once we’re executing against that plan, how do we report back up through the organization and link our agile progress back up to our strategic plan? 

Here are four steps you can follow to get started on your journey:

#1: Establish your approach to strategic planning

Define your project intake process

First, define a project intake process that allows those responsible for the demand side of the equation (Program Managers, Product Managers, Executive Stakeholders) to create, define, and request projects in a way they’re familiar with. Most likely these projects will have traditional artifacts that span the business case (revenue projections, strategic priority, competitive positioning, NPV, etc.…) and the execution plan (projected time to completion, costs, resources, dependencies, risks, etc.…).

With a system that allows for weighted scoring, the business can define a model that works for your particular situation. You can then score and prioritize each project against weighted criteria and rank them against one another. The end result is a backlog of waterfall style funded projects that are awaiting execution.

If you have a mature waterfall organization today at the enterprise level, this most likely already exists. 

Establish your strategic planning increment

Since your executive team is waterfall, they’re most likely using some form of a 3-5 year strategic plan with annual reviews. Eventually, as you move to a more agile approach to strategic planning you’ll want to facilitate a more iterative cadence (like an annual strategic plan that is re-evaluated and adjusted on a quarterly or rolling basis).

But don’t worry… while it’s ideal for organizations to scale agile practices all the way to the executive level, it’s not where many organizations start out. In this post, we’re making the assumption that your execs are waterfall, and that your job as the PMO is to ensure that the agile program and development teams in your organizations can execute and report against the waterfall-style strategic plan.

The most straightforward thing to do here is to adopt the current strategic planning cycle as your “strategic planning increment”. In most cases, this is one year. This means that you’ll be planning one year’s worth of work from a strategic portfolio standpoint. 

#2: Facilitate Resourcing and Project Selection

With a ranked backlog of projects based on demand and a defined strategic planning increment to plan against, you’re ready to start the project selection process by estimating resource availability.

Assuming your teams are agile, traditional models based on individual or skill-set based resource availability may feel awkward (after all, the teams are agile). On the other hand, assuming each project just needs to be “prioritized for future inclusion on the agile backlog” won’t provide much comfort to your executives looking for a detailed annual plan they can feel confident in. 

Blending is the only way home.

It won’t be practical in all cases to run one portfolio with waterfall using skill-sets and have another portfolio running agile. To get it right, a good approach involves a bimodal approach at the epic / project level. Teams running agile stay together and plan their work for the increment (let’s say quarter to keep it simple) using capacity and velocity. At that point the agile teams may have Features and even Stories by team, so all is well. Enter our skills-based teams. They do not stay together and team up around the epic / project but may disband after work on that epic / project is complete or they may spread work across multiple epics / projects at a time. 

If we know who is skill-based and who is agile-team-based we know a part of the puzzle. If we also know all of the skills-based capacity for the quarter then we can simply merge the two. This requires that our forecasting, capacity planning, roll-ups, and reporting all support a dual mode approach. With a bimodal platform under the hood, it becomes easy to see a path for companies that are blending both methods of resourcing in the same program / portfolio. Visualize a fit forecast showing capacity by teams and capacity by skill set for each epic / project.

Take dependencies and risks into account

Beyond basic capacity and resource planning, good forecasts and strategic plans take into account dependencies between projects and account for major risks. Dependencies may exist at the highest level between two projects, or may link more granular work items at the feature level depending on how much details about a specific project is known at during the planning process. Just like you would for any strategic planning exercise, identify these dependencies and programmatically insert them into your project plan. Then, as you execute against the plan, features or objectives that are dependent on work that gets missed can be appropriately highlighted in your agile management platform for immediate remediation. 

When you complete the exercise of layering in dependencies and re-sequencing projects, you’ll most likely need to re-baseline your strategic plan to reflect the list of projects that can actually get done in your strategic planning increment.

#3 Map the project intake process to your agile epic backlog

The secret sauce to linking waterfall strategy to agile execution is to translate each waterfall project into an agile epic. Then, at the portfolio level, assign each epic to the appropriate program(s) and allow the team to break down the work and execute in a traditional agile fashion. If using the domain approach above, there will be a natural fit between programs and projects. If using the skillset approach, there will be some high-level adjustments to make sure the right resources are on the right team at the right time… but as long as the programs have full-stack capabilities (even if each agile team does not) there won’t be any major impacts to the overall plan.


#4: Report Back to Executives on Agile Progress

As the agile team delivers against the stories and features that make up the project, how do you as the Program or Project Manager report back to executives on progress against financial and operational measures? 

Epic-level reporting is the answer. In agile, most metrics are typically done based on team velocity and the ability to complete work over time (vs. earned value and the ability to complete work against a plan).

Questions that need to be answered include: How complete is the epic? Is it on track? What percent complete is it? What is my burn-up or burn-down on my project? How well estimated are my projects at the detailed level vs. the high-level estimates I started with? What changed from a scope perspective? How much have I spent? Am I on budget? How am I doing against my baseline?

The answers to these types of questions enables you to create the type of traditional waterfall style reporting executives are used to. For financial reporting you’ll need to ensure that you’re leveraging cost center information (whether it be from AgileCraft or your systems of records) and time tracking may be required in some organizations for capitalization and financial auditing purposes. Then pull all of it together in a portfolio and enterprise level dashboard and you’re good to go.

How have you navigated this bi-modal world? Share your experience in the comments section below.

Topics: Bi-Modal