The Onion, a model for software processes

I love a good model. Imperfect as they can be, they're invaluable in trying to organize the world and create clarity between detail and big picture. As a consultant it was only ever going to be a matter of time before I ended up creating my own model for the world around me: the world of (software) delivery organisations. At heart my job is usually very simple to define: create a system in which the right work can be delivered in a controlled manner. Let's unpack that a little bit. It starts by knowing what "the right work" really is. Delivering the wrong thing isn't the goal here. So any system has to deal with understanding the input and how to make sure that input fits the right goals. When I talk about a controlled manner I don't mean a command-control "manage the detail" style. Instead I mean controlled in a wide statistical interpretation, as in "within the bounds of acceptable variation". The last part to think about is that any process or framework ultimately has a number of people to think about. While I do subscribe in part to the Ohno "it's the system, stupid" line of thinking, in the end the work still is done by people and so that's a dimension that has to be factored in as well. In future articles I'll come back to all of those, but for now let me start with big picture and walk you through The Onion.

The Onion

The Onion really is a meta-framework, if you will. It doesn't prescribe any particular actions in the way that some project management methods would. Instead it takes a step back and tries to place the various methodologies and practices in context. In it's simplest form, the onion is simply a set of concentric layers. The inside is delivery, surround by quality, automation, frameworks and governance.

Delivery

The heart of the onion is delivery. At core, the capacity to put product or services in the hand of customers is what drives a business forward and generates revenue. It doesn’t really matter if that product is a small toy, a complex supercar, a piece of software, or something where the product is more knowledge based like in typical consulting work. At the end of the day, value comes from delivering this product to people who have some use for it. That’s equally true on a macro level (i.e. company wide) as it is on a team or even individual level where the product might be a deliverable to a downstream team or a tool for internal use.

Quality

When thinking about quality there are 2 perspectives to look at. Are you delivering the right thing, and are you delivering it right. Or as an open question: is delivering the wrong thing right better than delivering the right thing wrong? Whereas the first perspective is about understanding demand/requirements, the second is about building better processes. As a sidenote: a common pitfall when organistaions "go Agile" is a foucs improving the latter part, but there is a danger that teams simply end up building the wrong thing better if that’s the only perspective taken.

Automation

Once in a position where delivering quality (in every perspective) is no longer a problem, the next question should be around making that repeatable. In most situations “repeatable without introducing extra variability” means some amount of automated decision making. That doesn’t necessarily imply full-on automation coded up, but could equally be very clear rules for people to make decisions in common situations. If you think in terms of value of time-spent by a person it's not difficult to understand that situations where creative problem solving is needed are more valuable than repeatable processes. If anything, the latter are more error prone if done by a person. So design the system to absorb the variability and reduce errors on work that can be automated/structured.

Framework

This layer and the next one are less about the product itself and more about the process surrounding the delivery, creation and management thereof. While this layer often gets a lot of attention, it’s real function is to guide the others. There are many ways you could focus on the 3 layers inside this one. That’s why when evaluating a framework it’s important to understand how it impacts those layers, as well as the people available to work, rather than focus on the specific acts of this layer. Put bluntly, no company ever won because they had the best prince2, Scrum, Kanban, ... implementation. They won because they consistently delivered the most value to their customers.

Governance

The last layer takes another step back and looks at perhaps the most important question of all: how do you make decisions. Governance isn’t about picking a particular framework, let alone directly impacting a particular level of quality of delivery. The core problem of governance is that of defining tolerance, focus, approaches and strategy. Setting the broad guides for what is valued, what the organisational system should optimize for and how that will be achieved.

People's perspective, impact and focus

As you travel through the layers of the onion 2 important aspects tend to change. The first, and the most obvious one, is that you move away from the core. As many people end up in roles that are dealing less with the core it’s sometimes easy to lose sight of the fact everything is rooted in delivery.

The second aspect that changes is the feedback loop between making a change and seeing the results. Making some changes in the governance process will eventually ripple through every layer until they start affecting the delivery capacity. Which then will take some time to feed enough data points to see a pattern in the regular noise of the organisation.

This point also highlights a difference between traditional managers vs individual contributors and how to measure success for those. Individual contributors quite often sit very close to the core and tend to look from the insisde outwards. Their focus is on practices that are usually quite quickly and clearly visible. Whereas traditionally managers sit on the outer layers of this system and look through those towards the inside. Ideally their goal is to work in those outer layers to create an environment in which the inner ones can flourish, rather than dictate the inner layers directly.

Summary

The Onion lays out the prism through which I have viewed delivery organisations for the last 15 years. Each layer comes with its own set of tools, practices and challenges but having this in the back of my mind has always allowed me to quickly place new practices and evaluate them, or have an expectation of timelines to see effect of changes. Over the next few articles I'll refer back to this model to help with framing. Of course, always up for a chat on this as well.