Agile Forest

Welcome to the third blog in the Scaling Agile Tricks Series.

So far we have covered the Leadership Cell pattern and the Mitosis pattern.

In this blog I will cover my personal sentiments on managing, refining and decomposing pipelines when delivering using Agile across multiple teams.

Generally I use the word pipeline management instead of terms like Program or Portfolio Kanban, mostly because the term is simpler to understand and the usage of Kanban implies a solution that there may not be a problem for.

I have seen three patterns used for pipeline management at scale:

1. Dual Track with separate ownership
2. Dual Track with team ownership
3. Just in time team flow pull

Let’s take a look at the pro’s and cons of these in some more detail.

To Dual Track or Not, that is the question

Dual Tracking is a concept that originated as part of Dual Track Scrum – where teams were often seen doing some backlog preparation or actual initial thinking of work one Sprint in advance:

When doing this technique the reality is that it creates context switching for individuals across two sprints – the current and the next planned Sprint.

My main issue with Dual Track Scrum has always been that it has been dressing Agile up in Waterfall clothing. It creates and encourages the idea that Discovery occurs in one Sprint, Delivery in the next Sprint and, dare I say it, scarily some people end up doing testing in the following Sprint.

Well, imagine that at an even bigger scale. This is what it tends to look like:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From top to bottom this is the context switching breakdown (worst case scenario). Firstly, delivery teams may be supporting any production issues that arise from the previous increment that they have delivered (note I use the term increment to indicate a number of Sprints that has resulted in a release).

Secondly the team is working on the current increment, delivering user stories. If they are unlucky they are dual tracking here too – ie working across two Sprints (2nd and third rows).

Thirdly they may be involved in the shaping of the work coming up for the next Program Increment. In the three pipeline management options I gave at the start of this blog this equates to the second pattern “Dual Track with team ownership” as the initial discovery isn’t done by a different team or subset of non team individuals.

In the advent of a really massive piece of work then there may be even further upstream work, breaking massive boulders of work down to feature like rocks. Think of this as a rock crushing machine. In my experience, at scale teams rarely get involved in this activity.

And lastly we have all the other stuff that teams end up having to do – <insert bureaucracy activity here>. If they are super lucky they get to have time to think and reflect on themselves as individuals and seek opportunities to improve their own capabilities.

It shouldn’t be a surprise to anyone that teams barely deliver when put under these constraints and expectations, and yet I do find that often it is very unclear to leaders of such teams that such extensive context switching is occurring.

The first pipeline management option, “Dual Track with separate ownership” reduces the amount of context switching down by having either a different team or key individuals like a designer and an architect look at bigger work coming down the pipeline in order to assess its customer and business desirability and viability and whether it is feasible given constraints, value earned over cost, etc. More commonly than not, these people aren’t or haven’t for quite some time been involved in actual feature delivery. Whilst they can provide a buffer to the team having to do some of this activity, it is at a high risk that the solutions that they are coming up with are unimplementable, over designed, or are based on poor assumptions. Additionally they create a need for a handover, which is often poorly executed.

Whilst you could certainly put in process to reduce these risks, why over engineer the process?

As a core principle for Scaling Agile, my number one rule is “Remove handovers and dependencies”. Which brings us to…

Just in time team flow pull

Each option has it’s pros and cons. The Just in time pattern means that the backlog for the set of teams is very lightweight in fidelity and knowledge. Think of these backlog items as initiatives (I am trying deliberately to avoid words like Epic, Capability and Feature as the hierarchy varies based on which scaling model you use). In my mind, an initiative is the sort of thing you might put on the release notes to customers when you do a new app store release, or something big enough to do a sequence for customer onboarding. Initiatives can take as little as three weeks or be as big as six months of work for a single team.

Initiatives are de-coupled from the other teams delivering in the same product through good shaping of scope and good team design (which we will cover in a future blog post). As a team finishes delivering an initiative they will pick up (pull) a new one and begin the discovery process on it. It tends to look like this:

 

 

 

 

 

 

 

At the tail of this approach the team is likely to prioritise first and foremost the release and support activities. Their next priority is doing Discovery/Inception on the next initiative. In the learning period where they may be waiting for customer feedback they can fill the gaps with technical debt.

You can see visually the difference between the reduced context switching of this picture and the previous one is quite significant. It does come at a cost – the cost of ensuring that the team is as independent as it can possibly be from the other teams delivering on the same platform. It requires not only good work prioritisation from a backlog perspective to limit two teams working in the same area, but also great technical practices to limit integration risks and be able to release at any point in time.

I really love this approach because it empowers the team to release when they are ready and empowers them to know when they are ready to begin coding. One risk is that they may spend too much time in Discovery, but even Dual Track has this risk. Another risk is that they may begin Discovery and then determine that the initiative isn’t viable. This could also occur in the Dual Track scenario, but a new backlog item would then need to be picked up and potentially those stakeholders may not be prepared to spend time in Discovery. The core of the issue is that there is no buffer time if the stakeholder(s) are unavailable, whereas buffer time exists in the Dual Track approach.

The reality? Out of about forty-five initiatives I have seen an initiative be cancelled once, so why design a process solution for such a small occurrence rate? Where you work may be different and more work may be cancelled in Discovery, so choosing which approach to take may be dependent on the failure rate of Discovery.

As a coach I try to move organisations towards Just in Time team pull but it takes time to remove the dependencies and handoffs first.