How To Sell Agile To Your Customers
Four clear benefits that Agile offers to your customers that traditional methods do not
This post is a substantial rewrite of an old post. As one of the most-read posts I’ve written, I felt that its message could be clearer. You can also listen to a podcast of this post too. So here goes :)
A substantial part of my learning experience with Scrum originates from small- and medium-sized businesses, in particular web design agencies. Compared to many large corporates, I’ve always enjoyed how close Scrum Teams can work with actual stakeholders here. In many cases, these teams would interact directly with the customers who pay their bills.
This close proximity to the customers is wonderful in many ways and highly challenging at the same time. Because it puts to the forefront just how difficult it is to sell Agile. This post is about that challenge, and how I think we overcame it - to some extent.
Setting the stage
Rather than an abstract and theoretical story, I wanted to ground this story in a real-life example. This story took place between 2007 and 2015 when I worked at a web agency in the Netherlands that also developed a range of enterprise applications.
One of the great things about this company was that we evolved into an Agile approach over a number of years, together. We picked Scrum as our framework of choice, as most of the development work involved a clear product (e.g. a website or a web application for a product). Although it took some effort to get everyone on the same page, the shift was successful overall. At its peak, we had five Scrum Teams working on a number of products. Overall, we found that quality improved, team spirit was high and customer involvement was significant throughout the process. Even our interns tended to form Scrum Teams that worked together on internal products.
But Selling It …
Despite the internal success, we struggled greatly to take our customers along in this Agile journey. Initially, our approach was to sell Sprints instead of a completed product. So while we guaranteed that we would deliver a new version at least once every Sprint, we wouldn’t guarantee how many Sprints we would need precisely. In many cases, we offered a range instead, say “Between 4 and 8 Sprints”.
“Initially, our approach was to sell Sprints instead of a completed product.”
We found that while most customers appreciate the focus on transparency, frequent inspection, and adaptation, they still ended up wanting a guaranteed price. Without irony, customers would first acknowledge the complexity and uncertainty of all their requirements, and then demand a detailed breakdown of the costs and planning for projects that would probably take months. We lost more than one pitch when customers ended up liking our honest story the most but still picked the vendor with the most detailed (and often cheapest) budget proposal.
This put us in a difficult position. Customers expect a simple, predictable, and precise budget for work that is decidedly complex, unpredictable, and imprecise.
“Customers expect a simple, predictable and precise budget for work that is decidedly complex, unpredictable and imprecise.”
“I prefer the traditional approach”
A good example of this was one of our biggest customers. He lamented that he preferred the traditional approach. For this, we would produce a massive requirements document with detailed estimates of the work and a nice, clean number for the budget at the bottom. From there, we would schedule the start date and calculate the delivery date.
I see what this gives customers. From their perspective, they receive guarantees on budget, the delivery date, and the scope they need to sell the work internally and to their own management, who in turn demand similar guarantees.
The irony of course is that, despite these initial guarantees, the scope would inevitably change during the work anyways. New ideas emerged whether we wanted to or not. In many cases, we had “uh oh” moments where we identified a critical missing requirement. Or a user would casually mention a super important feature that nobody had considered. In other cases, we made incorrect assumptions in the requirements document and had to argue with the customer over who’s fault it was. So we moved deadlines, requested additional budget, and frequently covered overly optimistic hour estimates on our part with our own money. More often than not, we completely shot ourselves in the foot.
All those initial guarantees proved to be false anyway. While they did make it easy for our customers to sell the projects internally, they would inevitably have to go back into their organization to secure more funding, reschedule deadlines, and disappoint stakeholders. Because what else can the customer do when the product isn’t ready and the budget is empty? Or we would spend many more hours on a project, and take a huge financial hit when we couldn’t find an agreeable solution with the customer to resolve the squeeze. As you can imagine, this dynamic put a lot of strain on the relationships we had with our customers.
The Fallacy Of Certainty And Precision
A customer once commented that if we couldn’t deliver precise estimates, we were apparently not good enough at our jobs. He said this in a room with four highly skilled developers, two senior analysts, and one business developer that all tried to make the case from their experience that accurate estimates are impossible for complex work.
He then openly wondered how we would feel when we would renovate our house, and the contractor would refuse to give an estimate because the work was “very complex”. Wouldn’t we want guarantees? Wouldn’t it feel as if we would shoulder the full risk of the project? If the construction work would take more time, we’d have to pay and have to wait longer. If the construction work would uncover issues (like leakage), we’d have to pay again. Our customer was certain that this wouldn’t appeal to us either if we were customers ourselves.
And many customers reason like this. How do you respond to that? Fortunately, this analogy is misleading as I will show further down. It also happens to be a prime example of the Dunning-Kruger effect I wrote about recently. This effect has been frequently replicated in research and shows that the less experienced people are at something, the more likely they are to overestimate their ability to have an informed opinion about it.
So while the customer wasn’t very respectful to the experience of the people he was talking to, you can’t really blame him either. He didn’t know better because he didn’t have personal experience with many of the following challenges that Scrum Teams face on a daily basis:
- The impedance mismatch between code and the real world brings complexity: To successfully automate a business process (e.g. handling a shop order, estimating an insurance policy, or tabulating hours), a developer must first understand it’s rules and conditions. By its nature, software requires black-and-white decision trees. Customers don’t think about their processes in that manner. Before they are automated, processes are often flexible, fluid and can be adapted in the moment to suit the situation. But when a process is turned into code, every exception, every condition, every possible path has to be taken into consideration. That process of translating something fluid into something that can be captured in code is very unpredictable and will unearth many challenges. It is also entirely likely that the process itself changes as new possibilities emerge during development.
- Dependencies bring complexity: Software usually requires many different components to interact successfully. Each component consists of hundreds if not thousands of lines of code. Each line of code can introduce new possible paths within the codebase. No human is capable of grasping the blossoming tree of possible paths that can be executed and their consequences. This makes the process of writing code very delicate.
- Communication brings complexity: Developers and customers usually have a hard time understanding each other. Developers tend to think more in terms of code and technology, while customers think in terms of their business and processes. These different languages can lead to Babylonian confusion about what is meant by some requirements. Although Agile tries to remedy this by putting everyone together frequently, it still adds noise.
- Unknowns bring complexity: More often than not, there is only a vague idea about what the product should be. So a lot has to be discovered along the way. These unknowns add uncertainty. Sometimes, I hear customers or development teams say they know 95% of the functionality. This does not mean that you don’t know 5% (‘oh, there’s not a lot of uncertainty’). You don’t know what you don’t know, so you can’t put percentages on it.
When we revisit the renovation-analogy, we can now see how clearly false and misleading it is. The challenge in product- and software development does not lie primarily in writing the code, but in figuring out what to write. Whereas in renovation work, you probably have a pretty clear idea about what needs to be renovated. The challenge there is mostly in the execution and the skills required for that. The ambiguity is also orders of magnitudes less, as your house is a physical object that you can walk around and frequently inspect (as most customers of renovation work do). With all that said, everyone who has ever renovated their house knows that it also tends to cost more than you calculated anyways. During the work, new issues emerge — faulty wiring, leakage, asbestos, or construction errors — that need to be taken into account and escalate costs. This uncertainty is an issue even for work that seems much clearer and less ambiguous at first glance.
So while this in itself is an argument to also renovate your house in an Agile fashion (as I’ve recently done with a contractor), it brings to the forefront what it’s all about: (financial) risk. The inherent uncertainty and unpredictability of complex work bring with it significant risks for your customer. There is the risk of spending all this money on a product that nobody actually needs. Or there is the risk that — along the way — a critical oversight is discovered that changes everything. Or the risk that the budget turns out to be insufficient, and customers have to go back into their organization to secure more funding and have difficult conversations with their management.
Don’t Sell The Hammer. Sell Its Benefits
As a wise person once told me after a feverish attempt to sell Scrum to them: “don’t sell me the hammer, sell me its benefits”. This was an important learning moment for me as I realized that I was explaining how it benefitted us, but not necessarily the customer. So what benefits does Agile offer to the customer?
1. Agile allows the customer to benefit from emerging wishes
The cognitive psychologist Daniel Kahneman writes in his famous book “the failures of forecasting […] reflect the customer’s inability to imagine how their wishes will escalate over time”.
Where a plan-based approach effectively tries its best to capture all possible wishes upfront, an Agile approach anticipates that wishes will escalate over time. Not because we didn’t spend enough time planning or thinking things through, but because the nature of complex work is that newer and better ideas will emerge when you actually do the work. In other cases, wishes emerge because something in the environment changes while work is underway. Perhaps a new competitor enters the market, a global pandemic hits, or the product strategy shifts.
If your customer doesn’t see the appeal in this, you can ask:
- “What makes you certain that you won’t come up with a great idea or insight during development that we just have to include?”
- “What proof do you have that your users won’t come up with better ideas for our product while we’re developing it that we just can’t ignore?”
- “What proof do you have that the feedback we receive from users will not surprise us?”
- “What proof do you have that the environment of the product won’t change during development in ways that we just can’t ignore?”
2. Agile gives the customer control over where their money goes
In plan-based approaches, the customer and supplier essentially agree on a certain list of work in exchange for a certain amount of money. It always amazes me how easily customers sign huge contracts and offer huge amounts of money (often with advance payments) for work that hasn’t even taken place yet. What if the supplier isn’t up-to-par? What if they make a total mess of things? What if the supplier starts holding your uncompleted product hostage in return for more money somewhere down development?
You can capture all these eventualities in huge legal appendices that stipulate in great detail what is legally expected from each other, with the promise of legal action if that isn’t delivered. But why would you go through all that effort when Agile makes things so much simpler and transparent?
“What if the supplier starts holding your uncompleted product hostage in return for more money somewhere down development?”
With an Agile approach, the customer arranges a Product Owner who is responsible for maximizing the value of the work done by the various Scrum Teams working on the product. Because completed versions of the product are delivered incrementally every Sprint, the Product Owner can make sure that the most valuable work is delivered first.
This is all happens in a very transparent manner. The customer can see exactly what Scrum Teams are working on, and what they will be working on in the near future. If a new and valuable idea emerges, or critical feedback has to be included, the Product Owner can simply re-order the Product Backlog to make sure it happens as soon as possible.
You can help your customer see this benefit by asking:
- “Why is it more important for you to have a completely nailed-down list of features now than the opportunity to capitalize on new and valuable ideas that emerge during development?”
- “How would it benefit the competitive advantage of your business if we allow you to change your mind about what should be part of the product as we develop it?”
- “How would it help you if you have an important say during development about what we work on and in what order, versus no say at all?”
- “How can we prevent that we waste a lot of time on nitty-gritty details of the product, while 80% would’ve been sufficient?”
3. Agile allows customers to avoid wasting money
When a list of requirements is exchanged for upfront money, and the work is delivered only at the very end of development, the customer implicitly assumes that every requirement is of equal value.
Another benefit that Agile has over plan-based approaches is that teams deliver valuable increments every Sprint. This changes everything. For one, it allows customers to verify assumptions about certain features early on. It is possible that a feature may not be as valuable as expected, or a better idea may emerge through feedback from users as they interact with a version of the product. Without these intermediate checks, the customer stands to risk losing a lot of money on work that isn’t necessary. How much money is saved depends on the discoveries made throughout the work, but it allows the customer to more effectively invest their money where it matters to their business.
If a customer wants, they can stop work at any point in time. Perhaps the product is good enough for its purpose when 80% of the work has been done. Or the customer may discover after a few Sprints that the product isn’t feasible at all. Either way, there is no commitment to keep spending money. These decisions would be impossible in a non-Agile approach, where nothing is delivered until the very end of development.
If your customer doesn’t see the appeal in this, ask:
- “Of all the requirements that you mention, which ones are so critical that the product fails if those are not accepted by the market? How can we work together so that we can deliver those first, and the rest later?”
- “What is necessary from us both to allow you to be able to decide — at any moment— to stop development because enough value has been delivered? How would that impact your financial risks with this project?”
4. Agile allows the customer to avoid difficult conversations
One of the inherent problems of complex work is that it tends to be fraught with assumptions and resulting misinterpretations. Over my years in this industry, I’ve created dozens of specification documents for the requirements that customers asked us to deliver. Every time, I was sure that I captured everything to the point where no confusion was possible. Feeling the same way, the customer happily signed off on it. But inevitably we ran into different interpretations. And every linguist, philosopher, theologist, or historian can tell you why: language is a very incomplete way to transfer information between two people.
So if we know that, why would we waste all this time compiling those functional, technical, and design documents and participate in this pointless dance? The company I worked for, this dance would make both parties feel good initially. But down the road, we would always run into many difficult conversations and heated debates about what we agreed to in the documents.
Agile allows us to sidestep this pointless dance and the ensuing heated debates, as well as all the energy siphoned into it, by getting the most valuable features out the door first. We don’t have to waste weeks, if not months, to clarify all requirements in excruciating details, and invite all the problems we talked about before, but deliver value this or next Sprint already. The customer doesn’t have to sign off complicated technical documents that they probably don’t understand, nor do they have to worry about detailed legal frameworks for when things don’t work out.
If the customer doesn’t feel this yet, ask:
- “What generates more real value for your business? That we spend the coming months hammering out all the functional and technical details for the entire product or that we only work out the details for the first small bit we can completely deliver, and then do that within weeks from now?”
- “How can we work together in such a way that our collaboration will not be dragged down by back-and-forth exchanges about how to interpret certain requirements?”
Three Ways To Sell Agile
Hopefully, you can use the benefits that I outlined in this post to help your customer understand how Agile benefits them. When you find yourself pitching against competitors who offer precise estimates in return for a certain set of requirements, you can use the questions in this post to help your customer see how Agile benefits them more compared to the illusion of certainty that your competitors try to sell them.
What would this look like in practice? These are forms that have worked well in projects I’ve been involved with:
- The customer only pays for the first X sprints. In this case, we turned the traditional model on its head and started with the constraint that we would only spend 3–5 Sprints on development and we would guarantee a valuable (part of the) product at the end. Within those constraints, what would be on the Product Backlog, and in what order? We would repeat this cycle after that, basically breaking down a large product into smaller (incremental) products.
- The customer pays every time a Sprint delivers a valuable outcome. In this case, we agreed to a flat price for any valuable outcome from any single Sprint (e.g. 15.000 euro’s). Every time we delivered a valuable outcome, the customer would pay that amount. Whenever we didn’t, the sum was paid in addition to the next time that we did deliver. Although we never had to do this, you can also agree to a “decay”-rate where the price of un-delivered outcomes slowly decreases over time. This adds a natural driver to deliver every Sprint and reflects how undelivered work doesn’t actually reduce risk or benefit the customer.
- The customer receives an estimate of Sprints: In some cases, the Scrum Team estimated a range of Sprints (best case/worst case) based on a rough overview of the requirements. We then offered the customer the likely range. When we delivered under the range, we would split the money that the customer saved equally. When we exceeded it, we split the additional costs that the customer would make equally.
Very early on, we learned that some customers just don’t want to go along. For them, we were often nothing more than “suppliers of paid labor”. What value can be gained from such a relationship? Even though hard at times, we declined to work for customers like that.
Don’t Sell Agile When You Can’t Deliver
All this talk about Agile is only marketing when your Scrum Teams don’t have the skills, means, and tools to deliver working increments of the product every single Sprint. If you sell Agile on its benefits and are then unable to deliver, you destroy all that trust. And you’re not really helping your customer to reduce risk. It's unprofessional.
It will always be hard to sell Agile. You may conclude from this post that we had a great time doing so. And despite many successes, we also struggled. We lost potential customers that we really wanted to work for. We occasionally still got into heated debates with customers over misinterpretations and we still occasionally fell into the trap of not delivering fast enough. On a whole, however, the quality of the products was high and customers were happy. In fact, our largest customer at one point acquired our company because we consistently outmaneuvered their internal IT-department in terms of quality and speed. They saw the benefits of Agile all too clearly.
Good luck with your experiments! And if you have any thoughts on the subject, please drop a note in the comments.