Agile enthusiasts will likely recognize the title of this blog as a paraphrase of one of the 12 Principles behind the Agile Manifesto. The entire principle reads:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
But why? Why is it so important to deliver frequently? What if customers don’t want frequent deliveries?
Let’s explore.
A Useful Diagram About Delivery
I found the following diagram a few years ago. It was created by Elizabeth Hendrickson, who is an expert in software development, testing, and agile ways of working. I think I first discovered her excellent work through a recording of a presentation she made on feedback loops.
Hendrickson expressed the importance of feedback loops quite elegantly with this simple diagram. Here is my interpretation of Hendrickson’s diagram:
- Intentions – This is what was requested or intended by the customer or end user.
- Implementation – This is the solution that is developed by the technology team.
- Actual Need – This is what was actually needed by the customer or end user.
The key to the diagram is not those three things. The real key to the diagram is the great arrows that connect each. The arrows represent possible gaps. Where there are gaps, there is a likelihood of waste and rework.
How could there be gaps? Well, this is the crux of the issue. Let’s look at each of the gaps.
- Gaps between intention and implementation – The customer-stated need could be different than the implementation because the technology team chose to build something different or they misunderstood what was stated. It is even possible that the team built what the customer actually needed instead of what the customer said they needed.
- Gaps between the stated need and the actual customer need – These gaps are highly likely because it is difficult for a customer to describe what they actually need. It may be easier for them to say what they don’t need after seeing what the team implemented.
- Gaps between the Solution Coded by the team and the Actual Customer Need – These gaps should not come as a surprise, based on the other two gaps. It is unlikely that teams are going to build exactly what is needed.
Are these gaps inevitable? I think they are highly likely, particularly when we are working in complex environments which is increasingly common.
So what can we do about it? Recognizing that these gaps are likely, one thing that development teams can do is shorten their feedback cycles in order to keep the gaps small. That is the best way to minimize throw-away work.
A Necessary Step in the Process
I started my technology career in the 1990s. In those days, we spent significant time upfront trying to understand and accurately capture the customer’s needs. This requirements-gathering and analysis process usually lasted several months and preceded any work on solution development. In fact, we usually tried to get the customer to sign off (in blood) prior to the start of any development.
If we use Hendrickson’s image, the process we followed might look like the one below. Note that the green arrow in this diagram represents a process, not a gap. That is, we collected the customer’s intentions, and then we implemented them in the solution.
At the time, we thought that if we just worked hard enough to capture the intention (i.e. the requirements) accurately, we would be able to build exactly what the customer needed. But frequently, we were not able to build exactly what the customer needed. Hence there was usually a gap between what was implemented and what was actually needed.
Projects at this time were long and the outcomes were often delivered in big batches at the end of the project. It might take six to twelve months before we built anything that we could show to the customer. It was only then that we were able to determine if there was a gap between what we implemented and what the customer actually needed. Unfortunately, that knowledge came too late to make a change without incurring additional costs and delaying completion.
Which is why there was such a heavy focus back then on controlling scope creep, which is bullshit, btw. Changes were unwelcome and teams pushed to deliver exactly what the customer thought they needed (the intention above) at the outset. The team ignored whether or not the intention was accurate or to recognize that change could have happened after the intentions were documented.
And by that time, the budget was spent and there was little likelihood of going back to deliver the actual need.
With some cynicism, we would label the gap between what was needed and what was built as Phase 2. Rarely was there a budget to complete the Phase 2 items.
This type of failure was pretty common in the 1990’s and even into the 2000s. Blame often fell on the customer for changing their minds or the team for not doing a good job of gathering the requirements.
The Standish Group first started studying failed projects in 1994. Their first Chaos report published in 1994 pointed to requirements as the top causes of project failure cited by users.
The thinking at the time was that if we did a better job with requirements, we would satisfy our users.
This sounded good in theory, but in practice, it didn’t work out so well.
First, it took a lot of effort to gather the requirements, double-check them, document them in a big binder, and get them reviewed and signed off. Worse, the longer the process took, the more likely it would be that the requirements that were gathered were out of date or no longer needed.
Second, it was near impossible for customers to describe what they needed with accuracy. This problem still exists today.
As a result, even those teams that invested heavily in getting the requirements “right” wound up building a number of features that were wrong or would not be used by the customer or end user.
Spending more time on requirements gathering didn’t solve the problem of the gap between what was implemented and the actual need. What actually works to eliminate the gaps?
Can You Eliminate the Gaps?
An obvious question is whether or not you can eliminate the gaps.
One approach is to start with the intention, build something very small, and then show it to the customer to determine if it meets the actual need. And doing it in smaller and smaller increments with shorter and shorter feedback loops.
Yes, this means that we might have the team build something without being certain it will meet the customer’s needs. That is the idea behind the Agile Principle mentioned above. It may be necessary for the team to build a small part of the solution just to give the customer something to react to.
This is quite similar to the Lean Startup approach, where the team builds the smallest possible version of their product that allows them to validate their assumptions.
There is a great example of the Lean Startup approach from the Nordstrom Innovation Lab. In this YouTube video, they describe how they quickly built a sunglasses app with rapid feedback from customers. They did their best to deliver frequently, even using paper prototypes as a quick and inexpensive way to gather feedback. Why write code when you can simply draw the interface on a piece of paper?
We Can’t Be Bothered To Deliver Frequently
Unfortunately, many Agile teams today lack the historical perspective, and true understanding of the Agile Principle mentioned above. They don’t get Hendrickson’s diagram, either. And they don’t deliver frequently.
Sure, they say they use the Scrum Framework. They have 2-week sprints and daily meetings. Some may even have retrospectives every sprint.
Rather than building in small increments and getting feedback, many of these teams write “user stories” that read like chapters from those old-school business requirements documents. These user stories represent big batches of development. Big batches don’t get completed within a sprint, and that means that the team doesn’t learn that they built the wrong thing for two, three, or more sprints. [See my related blog post, How to User Story].
These “agile” teams miss the point. They don’t deliver frequently and they really aren’t all that agile. They are just using sprints to churn out big batches. It is like we never left the 1990’s.
Bottom Line
It is challenging to build what customers actually need on the first attempt. Teams can reduce the likelihood of building the wrong thing by understanding the relationship between intentions, implementation, and actual need, as well as where there can be gaps among these factors.
Deliver frequently – short feedback looks are essential!
Thanks to Elisabeth Hendrickson for everything she has contributed to the SW Development, Testing, and Agile body of knowledge. And for allowing us to use her image.