The roots of agility

If you read the agile manifesto, you will find an annunciation of principles for decision making. We value A over B, when the two are at odds. But underneath all these are some basic assumptions about how and what we are aiming at. Assumptions which are not always well understood. The reason we choose A over B is service to the customer. That is true. But don’t get it confused with the suggestion that means we need to ‘go fast and break things’. Taken in the right light, that might be the path your team needs to take. Just don’t assume that is the path without evaluating it first.

If you read the Scrum guide, you’ll find that is mentions ‘lean’ thinking. This alludes to a sister concept called ‘Lean Manufacturing’. This idea was first given life by Toyota. Lean emphasizes the flow of value to the customer, through continually managing towards perfection, eliminating waste as you iteratively improve… Sounds suspiciously like agile doesn’t it? In truth, there is a lot that agile practice can bear to learn from our older sister ‘Lean Manufacturing’.

To begin, it is important to distinguish between the potential objectives an organization might have in ‘going Agile’. You might want to deliver to market faster. You might want to be able to respond to market change more rapidly. You might want to just avoid being outdone in the market. Each of these reasons has it’s merits. But that is not what spawned the Agile movement. The Manifesto that started the movement was about ‘discovering better ways to deliver software’.

Put another way, agile was about finding better ways for Software Engineers to deliver value to the businesses we are part of. If you think about delivering better value, you might think of delivering more of the software that the business really needs. This might look like delivering more depth in a feature the customers use heavily. And this a sweet spot for Agile, finding out what the customer values. But there is another part to the equation. Delivering that software more effectively, more quickly, is also a way to deliver better value. This might look like delivering more of the applications or ecosystem in a given period of time. We could summarize those two parts as ‘Build the right thing, and Build it well’. And typically we associate Agile with that first part.

Now, suppose we have an Agile team that have reached the Norming Stage. We might expect them to be reasonably good at learning whether and how the features they are delivering are meeting customer needs. But what about their development process? Should we expect it to have changed? And if so, how should it have changed? Would it just be in standing up new processes and inputs for customer feedback? Would it be automated CI/CD pipelines and automated tests?

While all that is good, none of those will suddenly help a team into high performance. But then, I wouldn’t expect my son to start zooming down the street with his training wheels on either. Having those tools is great, but having the tools is not the same as leveraging them effectively. For example, the developers could still be tossing code over the fence to the QA, who tosses bug tickets back. Some of those bugs might still be originating from misunderstood requirements. Doesn’t sound too efficient does it?

One of the goals of Lean is to optimize the flow of value to the customer. That starts by understanding the steps that add value to the product as we deliver it to the customer. Once we understand which steps add value, the challenge is to determine which steps we can drop or reduce. The goal is to continually provide more and more value to the user, while spending less and less. In the example above, tossing things back and forth is leading to a lot a rework. And rework is a kind of waste. If we could deliver value in a single shot, then we’d deliver more value in less time. But to cut the rework, we need to understand what is causing the rework in the first place! And we will need to keep digging until we can identify the root cause. Surface level answers won’t be enough.

That is a lot of ground to cover! After all, mankind has been learning how manufacture since the early 1900s at least! That’s a lot of history, and many lessons to distill. But for anyone just starting out on this journey into Lean-Agile, even the first lessons can be powerful. Agile seeks to discover more effective ways to build software. Lean seeks to optimize the process for delivery as we learn to do the work more and more effectively. We should expect our ways of working to change over time as we grow as professionals. But we need to center all that growth around the core concern: Delivering better value to the businesses we are part of. To that end, let us depart with a question: What steps of your work actually add value for the end customer of your product?