Jagged delivery

You’ve got a project to deliver. You’ve got a neat plan. You expect that the team will deliver the scope as planned.

The work starts. You start with two components, A depending on B, each backed by a delivery team. You issue a plan showing delivery of A and B. Soon after the work starts, you discover that B needs a change of an existing component C not owned by your teams. No panic, you just need to find a team to make the changes for C. The changes are not big, but the team responsible for delivering C is busy; you need to wait for them to become available. No mad panic, you can stub out C and continue development of A and B.

Not long into the project, you detect that the team building component B operates at a different maturity level compared to the one building A, and as a consequence the two teams operate at different speeds. When component A is done, B is far from being complete. You try to help deliver component B faster, but that is not possible to achieve. The team delivering component B are making a case that support is futile and they don’t accept the help.

The team delivering A becomes idle. You ask them to start working on a new component D, which is dependent on component E. Project management updates the plan, indicating that the release will now contain A, B, C, D and E. The project issues a new baseline plan.

Midway through development of D, component B and C get complete. In response to this you move away focus from D, shifting it to complete the integration testing of A -> B -> C. While the team does that, component E needs the attention of the team building component D, who is now tied with the integration testing of A with B and C. Team building E have to wait now because you found problems in the integration between A and B. The dates don’t stand anymore and another new baselined plan is issued.

Once the team fixes the A->B integration issues, the focus goes back to D which was dependent on E. To your surprise, the team building E could not wait any longer and they have moved on to work on something else.

Now imagine that at the starting point you didn’t have only two components to build, but rather five, six or even more. Furthermore, assume that most components would experience similar delivery issues, an assumption that it is not far-fetched for any medium/large size deliveries. For such situations it becomes difficult to perfectly align component deliveries, and as a result plans are constantly re-baselined and stakeholders disappointed.

Projects portray a false sense of control. Despite component dependencies blowing out of control, the release scope is neatly cut and project plans are neatly aligned.

One of the problems is that projects portray a false sense of control. All the while component dependencies blow out of control and delivery of those components become progressively harder and harder to align, project plans remain neatly aligned.

So, what do you do in this situation? You’d want to change the organisation, make it leaner, but that is not an easy task, requires a lot of energy and cannot be done in the timeframe of the project. You’d want to slice the project differently, but it’s too late for that. You feel trapped, wanting to buckle down and continue. But it’s hard and frustrating, you feel that you are ever-losing a battle, you feel powerless.

There is hope though. There something that most projects can do and it is within their powers — stop looking at projects as a collection of neatly aligned deliverables, requiring a perfect alignment of components and start looking at projects as ‘jagged deliveries’.

“Jagged — with rough, sharp points protruding”. [1]

It’s hard to align delivery of all the components perfectly. Don’t fight this.

Instead of trying to perfectly align deliverables, growing ever-frustrated and spending energy on work that doesn’t move them forward, projects can focus instead on building capabilities that produce _resilient systems w_hich degrade functionality gracefully. If we look at the components dependency as a graph, the project owner owns the top of the graph. They should be able to control how the system behaves from top down.

Going back to the example, consider that C is only partially working, which doesn’t unleash the full functionality of A and B. If A and B degrade gracefully then a release can happen despite of what the rebased plans are saying. No need to wait for a fully functioning C. If at that point, D doesn’t have E, then we need to make sure that deploying D doesn’t crash the system; we need to consider if D needs completely hidden, or a graceful degradation is possible. When C is fully functional, A and B will catch-up.

Move away from ‘straight line delivery plans’, to a ‘jagged’ one.

Projects can take this concept to release and delivery planning, reflecting in their plans this resilient behaviour of the system. Some features might be released earlier than planned, some later. They should abandon the ‘straight’ line planning. Project planning needs to support engineering and avoid being a constraint and a source of pressure. By taking a different approach to planning, projects communicate differently to their stakeholders, providing the necessary cover for the team.

A jagged delivery model — given the scale and complexities of most projects, a well-defined release mechanism with ‘straight’ delimitation of scope is challenging to achieve, probably even undesirable.

How do you build such resilient systems? By focusing on building capabilities that help you achieve it, such as:

• feature toggling — toggle on and off features based on their availability.
• trunk-based development — don’t start branching. Stay put and develop on one a single branch.
• environments on demand — implement flexibility for development and testing by making sure that environments and test data are never a limiting factor. Implement environments on demand, where team-members can spin up any environments they wish; have simulators for testing.
• prioritize deployability of the system over feature development — make a priority of keeping the software in a deployable state over working on new features
• automate deployments and testing — fully automate deployments and use test automation throughout the development process.

References

[1] Google definition