I’ve been struck recently by the power of self-similarity in Agile. Self-similarity is a concept that is borrowed from complexity science. A self-similar object is exactly similar to a part of itself. The whole has the same shape as one, or more, of the parts. You may be familiar with how coastlines, when seen at different scales, are statistically the same. Whether viewed through a magnifying glass, from 1,000 feet in the air, or six feet off the ground, the twists and turns of the coastline are statistically self-similar at each of these very different scales. Without trying to prove this mathematically, the idea of self-similarity in Agile has led to some interesting conclusions about how to address agile product delivery at scale.
Let's start at the team level.
A strong agile delivery team is adept at swarming around a work item leading to its rapid completion. The team manages the number of work items they are immersed in to keep a lid on work-in-progress. They also work together to share the load on getting the work finished. The completed work items provide a barometer on delivery risk over time (or during the Sprint if they are using Scrum). If the pace of delivery of work items is significantly impacted, the delivery risk is higher.
Now picture a major product change. Months of development supported by many different teams working towards the same end. Using our principle of self-similarity, what can we deduce?
In our description of a single team, we mentioned three principles:
- Swarming around work items to complete a work item rapidly
- Limiting work-in-progress
- The pace of completion of work items as an indicator of delivery risk
When considering a major program, the “incremental” part of “iterative and incremental” delivery holds the key. Instead of work items, we focus on increments of delivery. Shippable product increments in Scrum parlance. In the context of this article, an increment is a shippable set of functionality that can be completed by the delivery team(s) in a couple of months, depending on the scale of the program. You may not ship them to a paying end-user, but you would certainly get them onto a pre-production environment to allow internal stakeholders to explore. These delivery increments are a different scale to a work item (or user story). Increments are larger than a user story, smaller than a release. However, they serve the same purpose.
We can see the same principles at play:
- Teams swarm on their work to complete an increment as rapidly as possible
- Teams work on one, or at most two, increments at a time to limit work-in-progress
- Increment delivery is an indicator of delivery risk
At the team level, this skill is driven primarily through the guidance given to the team. A great Product Owner with a well-formed backlog will help, but how the work is delivered falls to the team itself. At the product level, this skill is driven by the ability of the product team to break down major product development into many increments of delivery. Exactly as we expect a Product Owner to create a backlog of well-sized work items, we want a product team to create a backlog of well-sized shippable product increments. These well-formed increments then lead to the right behaviour on the (many) delivery teams. Alignment, collaboration, and a focus on the current increment. The result of this is a powerful indicator of delivery risk - the rate of completion of these increments. Literally increment one followed by increment two followed by... well, you get it. This application of self-similarity has real value. As we discussed above, the power is in the increments to manage risk, even on the largest projects. Often, digital product delivery beyond a few teams become site iterative delivery without the incremental. This has real problems.
First, we cannot take completion of an iteration as a step forward. Iterations do not reduce delivery risk. Increments do. If we don’t have increments, just iterations, we need some other mechanism to manage delivery risk. Completed stories are not sufficient without a testable increment.
Second, we cannot change direction with ease - the pivot that business bought into when learning about agile delivery. This ability to pivot– to welcome changes even late in the development process – is based on the assumption that we have completed and released a potentially shippable product. Without that testable increment any pivot can be messy – imagine pulling the team out of the kitchen when they are in the middle of cooking a meal.
Third, we cannot 'trim the tail', as Henrik Kniberg so prosaically describes. Too often we have observed programs that run and run because they are nearly impossible to release until every last feature is complete. With iterative delivery, instead of iterative and incremental delivery, we can struggle with an illusion of progress that is more like a train between stations – we are making lots of progress but are no-where nearer getting alighting from the train.
In closing, the self-similar nature of agile product delivery allows us to better create successful agile delivery across large programs. It applies in a number of different ways, for example, from the tasks to user stories to epics to increments to releases. We discussed the impact of self-similar thinking on the delivery of a single team, focusing on stories, and extended this to one or more teams delivering a major increment. Many of the artifacts and behaviours we see at one level have relevance and equivalence at another level. We can apply our learnings and experience at a team level to the larger program (with a bit of a twist).
