A Scalable Agile Planning and Delivery Framework

Photo by Slidebean on Unsplash

In an earlier post, I talked about structuring an organization as you scale. Another extremely common challenge that product organizations face when they scale is planning. Whether explicitly written down or not, every product organization has a process to decide what to build next. These planning processes can span from “whatever our CTO said this week…” to a formal stage-gate process. Regardless of the approach, planning becomes increasingly more difficult as the number of interrelated teams and stakeholders increases.

The planning challenges manifest in different ways. For example…Is it a struggle to align work across different agile development teams/squads? Is it challenging to balance business needs against technical and architectural items? Are your dev teams frustrated by lack of focus and constantly changing priorities? Do you wonder whether your development velocity is improving or getting worse? If you are facing any of all of those, this might be for you!

This will be a multi-part post. In this first one, I will introduce concepts and how the process works in theory. In the follow-on post, I will show an example using our most recent implementation of the process.

Before I get started, I want to address a potential ‘elephant’ in the room. I introduced this post as a scalable ‘Agile’ planning and delivery framework. Over my career, I have met a few Agile purists that argued against any form of planning process as inherently non-agile. Sometimes these debates were about making commitments that extended past the end of the current sprint. In more extreme cases, some even eschewed planning with the sprint, opting for a Kanban-style approach. There are almost certainly situations where simply focusing on sprint-by-sprint or day-by-day incremental progress is appropriate, but in practice this rarely works at any scale. When you scale without a planning framework you will almost certainly see lower velocity over time as teams struggle to manage dependencies and more complex deliveries. I assert that you can have an ‘agile’ planning process. The ‘art’ of an agile planning process is to strike the right balance between planning rigor and agile principles emphasizing iterative, incremental development.

Tenets

In that spirit, I want to introduce something that I took away from my time at Amazon Web Services. When we were creating a new process, product, feature, etc. we often documented an explicit list of tenets. These tenets capture important principles which shape the thing being created. Agreeing on tenets up front creates alignment across stakeholders. In this case, here are a few of the most important tenets that shaped the evolution of this process over time.

1. Keep it simple — Any process introduces some amount of overhead. We strive to keep any net new work to a minimum and ensure that it directly drives value to our stakeholders.
2. Transparent — When stakeholders have all of the information available on demand and without friction, we can make better planning decisions and adjustments.
3. Don’t let perfect be the enemy of good [enough] — Planning (and software delivery in general) is an inherently imprecise activity and we do not strive for perfect accuracy. We strive for a planning framework that embraces that uncertainty rather than seeking to eliminate it.
4. Deliver early, deliver often — When planning, we should structure our epics to support incremental delivery of end-to-end use cases over time. This forces early integration work and enables us to deliver more predictably over time.
5. Minimize in-flight work — Seek conviction on the work we commit to do in the plan and then see it through to delivery.

The process takes significant inspiration from the Scrum agile process. In fact, the entire process can simply be viewed as an extended agile sprint. It starts with a planning activity, uses a scrum-like check-in process to monitor progress, and closes with a retrospective. I have found it to be most effective when aligned on a quarterly cadence. Shorter or longer periods also work, and you may want to explore different planning periods to see what suits your organization and business the best. Whatever the period chosen, it should be some number of your core agile development sprints. For example, we use 2-week development sprints and our typical “quarter” is 7 sprints or 14 weeks. The length of any given “quarter” may fluctuate based on the calendar and accommodation of holidays.

Step 1 — Surface the backlog

Stakeholders (product managers, engineering managers) create epics for consideration during planning. In this context, an epic is any non-trivial scope that you would like to deliver. Epics should encapsulate some end-to-end user or system value wherever possible. Epics must be tagged to each development team that needs to complete work to deliver the epic. Each epic will also be assigned a priority rank, typically led by product managers.

Step 2 — Estimate the backlog

Teams estimate the work required for each epic where they are tagged in a consistent unit. We use ideal developer-months as our unit of estimation, lovingly referred to as ‘wags’, short for ‘wild-ass-guesses’ . Note that in deciding appropriate epic scope, we aim for epics sized between 1 developer-week and 2–3 developer months. Too many small epics become unwieldy for planning and can typically be rolled up into more reasonably sized batches. Epics that are too big tend to be difficult to scope and estimate. It is best for these larger epics to be factored into a few smaller epics with incremental deliveries. Finally, teams provide their total capacity for the planning period using the same unit of estimation.

Step 3 — Team-level backlog grooming

With a complete set of target epics that have been estimated and ranked, you are ready for a special type of backlog grooming. By looking at running total of estimates for each team in epic rank order, there is a cut line. Epics that exceed a team’s capacity do not fit for that team and either need to be reprioritized, rescoped, or deferred to a subsequent planning period. By looking at epics across all teams, you can see where there are epics that fit for some teams but not others. The final plan is not valid until all teams have a set of epics that fit within their available capacity and all in-plan epics are fully funded across required teams.

This backlog grooming is an inherently iterative activity and often takes two or three passes to complete. While dropping lower ranked items that are clearly out is straight forward, it is quite common to find higher-ranked epics that are in for one team and out for another. In those cases, we typically engage teams in a discussion of whether a team with more available capacity can take on some of the work for the team with less capacity. All of this should hopefully become more clear in the next post when we walk through an example.

Step 4 — Plan lock

The grooming phase closes with a special session that we refer to as ‘Plan Lock’. At Plan Lock, we review the entire plan with all stakeholders including Engineering Managers (EMs), Product Managers (PMs), various business stakeholders. We typically ask PMs and EMs to walk the list for their teams in priority order. They provide a brief description of each epic and any important assumptions or constraints that influenced the estimate. We discuss the priority rank with stakeholders and may question the scope or estimate.

The conversation is especially important around the capacity cut line. We try to assess the level of heartburn with various stakeholders for epics that are below the cut line and subject for deferral to the next planning period. We also pressure test the relative priority between items above the cut line and below it. Quite often, we adjust the priority based on stakeholder feedback to arrive at the final list of epics.

Step 5 — Execution

During execution, we use a weekly check-in that is roughly analogous to a daily scrum to monitor progress against the plan. Each team updates a spent and remaining estimate on all their epics. Because all the epics were estimated before the quarter started, we are able to monitor a full burn down view of the quarter across teams. When teams get behind on their burn down or when some emergent priority comes up, it triggers a conversation on any necessary adjustments to scope. These check-ins continue throughout the plan period until we have (hopefully!) delivered a majority of the epics we intended to.

Step 6 — Retrospective

To close the planning period, we perform a retrospective on how well we did, how effective the process was, etc. Any of your favorite retrospective formats will do. We typically try to narrow down to a small handful of specific actions items that we commit to complete moving forward.

Conclusion

That’s all there is to it! Mastering the process takes some practice and experience with your team of course. Finding the right depth of requirements/scope detail so that estimation can be effective enough is tricky. My advice — don’t sweat it! You will probably miss by a lot the first time. Take that in stride, do your retrospective, and work out ways to do a bit better each iteration. Also, remember that tenet about not striving for perfect accuracy. Somewhere around 70–80% completion is the sweet spot to aim for. Too far below that and you aren’t building confidence and trust with stakeholders. Much more than that and your teams are sandbagging estimates and could probably accomplish more!

Hope this was helpful and would love to engage around more of the nuances here (there are many!) with those that are intrigued. Will follow-up shortly with the post showing an example planning period using our current implementation here at Coalition.