Image for post
Image for post

How To Sell Agile To Your Customers: Emphasize change

Christiaan Verwijs
Apr 28, 2012 · 14 min read

A completely revised and updated version of this article is available here. You can also listen to a podcast of this post too. I’m leaving this post here for reference, but I recommend you read the updated version.

A substantial part of my learning experience with Scrum originates from small- and medium-sized businesses, in particular Webdesign agencies. Compared to many large corporates, I always enjoyed how close Scrum Teams can work with actual stakeholders here. In most cases, teams interact directly with customers who pay their bills. Or they get angry calls from the users themselves when a website goes down or has a nasty bug.

This close proximity to the people who pay for the work done by Scrum Teams is wonderful in many ways but challenging in others. Because it puts to the forefront just how difficult it is to sell Agile to your customers. 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 clear and distinguishable products (e.g. websites and web applications). Although it took some effort to get everyone on the same page initially, the shift was successful overall. At its peak, we had between three and five Scrum Teams working on a number of products. Overall, 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, it was a huge struggle to take our customers along in our Agile approach. Initially, our approach was to sell Sprints instead of a completed product. So while we guaranteed that we would deliver an Increment at least once every Sprint, we wouldn’t guarantee how many Sprints would be needed precisely to achieve the product goal. In many cases, we offered a range, say “Between 4 and 8 Sprints”.

We found that while most customers appreciate the focus on transparency, frequent inspection, and adaptation, they still end up wanting guarantees for the scope, the budget, and the time it would take for us to discover. Without any irony, customers would first completely 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.

You Can’t Put A Number On Complexity

This put us in a difficult position. Customers expected a clear number for the hours and the budget for something that was decidedly complex and unpredictable. For me, the core of this is that you’re usually chasing a moving target. Once work gets underway, better ideas emerge, and the purpose of the product changes along the way in subtle-but-impactful ways. Most of these ideas are super-valuable, and you want your customers to benefit from them. But if you create that space, you probably end up shooting yourself in the foot as customers won’t agree to an unclear budget on the one hand while still expecting said flexibility from you.

“‘I prefer the old way”

A good example of this was one of our biggest customers. He lamented that he preferred the traditional way, which boiled down to writing a massive requirement document, estimating the hours the work, and translating that to a fixed budget. We would then set a deadline and get to work.

And this is understandable. From the perspective of the customer, this gives them the guarantees on budget, date, and 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 guarantees, the scope inevitably changed during the work anyways. After all, those new ideas emerged if we wanted to or not. And in many cases, we simply made incorrect assumptions in the requirement document that we based our estimates on. So we had to move deadlines, request additional budget, and frequently covered overly optimistic hour estimates on our part with our own money.

When we tried to accommodate the desire for strong guarantees with detailed price proposals, we would inevitably end up with many difficult conversations with customers when we had to move the deadline or ask for more budget. So all those initial guarantees — also given by our competitors — proved to be false anyway. What they did achieve was provide a sense of certainty and security to the customer that was needed to sell the project internally. Once underway, customers often had to increase their budget or change their deadlines anyway.

Although I am a strong proponent of Agile and Scrum, I feel that there is a lot of work to do when it comes to figuring out how to sell such an approach to your customers. Although Agile seems to be the most sensible approach from a rational perspective, and customers usually agree with that, they still express a strong desire for fixes prices, scopes, and schedules.

How (Not) To Respond To Requests For Guarantees

Suppose that you are buying a house and you want to renovate the kitchen and the bathroom. You wouldn’t be happy either when the construction company does not want to commit to a budget, a scope, and a schedule. It may feel as though you have to shoulder the risk of the project. If construction takes more time, you have to pay up and wait longer before you can move in. If the construction work uncovers issues like leakage or shoddy electrics, you pay. This comparison is actually wrong, and we will explore why later. But a lot of customers reason like this, with similar examples.

Now assume for a moment that you are in the shoes of the customer. You have this idea for a new product or some other project that needs to be done, and you are presented with an approach and a request for money by those who will be implementing it. What would you want to hear, as a customer?

What you probably don’t want to hear — and I mistake a made many times in the past — is a sales pitch for Scrum or Agile. Since customers often don’t have a frame of reference, all this terminology about Sprints, Scrum Events, and Increments means nothing to them. It doesn’t give them the guarantees they seek (or need).

As a wise person once told me after exactly such as sales pitch: “don’t sell me the hammer, sell me what you can do with it for me”. This was an important learning moment and helped me realize that it is not about “selling Agile”, but about offering the unique benefits that Agile offers over more traditional approaches.

The fallacy of certainty

One customer once commented that if we can’t estimate correctly, we are apparently not good enough at our job. 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. This customer had zero experience with software development.

This is a prime example of optimism bias, or more precisely the Dunnig-Kruger effect, that I wrote about recently. This effect has been frequently replicated in research and states that the less experienced people are at something, the more likely they are to overestimate their ability to have an informed opinion about it. Or more succinctly; the less you know, the more certain you are.

Most people — and this includes developers — believe on some level that software development is fundamentally predictable. If you would spend enough time nailing down the details upfront, no changes will occur during the process as all scope and their technical implementations are known. Think about it. Only if software development is predictable, can you actually accurately predict the budget, schedule, and scope of what will be delivered.

Software development as a predictable process is a powerful misconception that makes it difficult for customers to embrace Agile software development methodologies. Let me make it clear that you can’t blame the customer for this. We need to explain how we work and where the complexities lie. We also need to stop pretending (or even believing) that it’s a predictable process ourselves.

Focus on change: Agile development emphasizes that change in scope is part of software development. Changes in scope can have many reasons, including evolving insights in how a system should work or how a process should be automated, new ideas that pop up during the process, external factors (economic, political, judicial, etc.), because of complexities or underestimates, and because of user feedback. Customers should see the value of an approach that allows for change. Too many projects fail because the project delivered the system that was designed, but not the system that was needed;

Focus on iterative development: Agile development emphasizes that the best way to deal with the complexities of software development, is to work in small steps towards a fairly vague end state rather than trying to nail down all the details from the start. The details will change anyway, as new insights are gained. This avoids costly functional and technical designs that are hard to read, open to many interpretations, and will only result in contract negotiation as heated debates ensue over what constitutes a certain functionality. Customers should see the benefit in being able to start as soon as possible, rather than having to wait for massive design documents (which are hard to read anyways);

Focus on frequent feedback cycles: Agile development emphasizes that for change to be identified, frequent feedback cycles are necessary. In Scrum, this is done through the daily scrum, the sprint review, and the retrospective. Customers should welcome this, as it allows them to incorporate changing insights;

Focus on delivering functionality to achieve business value: Agile development emphasizes on delivery of functionality to achieve business value at the end of every iteration or sprint. Instead of having to wait for months, customers will be able to inspect progress periodically. Even better, each sprint can potentially deliver functionality that can be put into production or used to convince higher management or end-users that the project is really going somewhere;

Focus on removing the black box: Agile development emphasizes that the best way to develop software, is to put the customer in the room with the people that are actually going to build the system. This allows for the most direct communication and sharing of knowledge as possible. Customers should welcome this as it opens the black box that software development is.

The bottom line is that when you are using an Agile approach to software development, you acknowledge that change will occur and should be welcomed and even actively sought out during the development process through a joint effort of the product owner and the development team. The focus on iterative development, frequent feedback, delivery of functionality to achieve business value, and close communication with the development team are in themselves merely means of identifying progress, with change in scope as a likely result.

Approach 2: Explain the nature of software development and how change is unavoidable

Most customers (and software developers) believe that software development is fundamentally a predictable process. If you would spend enough time nailing down the details upfront, no change will occur during the process as all scope and their technical implementations are known. Think about it. Only if software development is predictable, can you actually accurately predict the budget, schedule, and scope of what will be delivered.

For example, one customer recently commented that if we can’t estimate correctly, we are apparently not good enough at our job. 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 that estimating accurately is impossible in software land, based on their experience.

Software development as a predictable process is a powerful misconception that makes it difficult for customers to embrace Agile software development methodologies. Let me make it clear that you can’t blame the customer for this. We need to explain how we work and where the complexities lie. We also need to stop pretending (or even believing) that it’s a predictable process ourselves.

Developing software is a highly complex process, involving many variables, unknowns and complexities. Although some parts of it are predictable, most are not because of a number of reasons:

  • Different interpretations and miscommunication: Software is an intangible product. Because of this, there will be many different interpretations of what is needed and why. Worse, there are many implicit assumptions that are rarely explicit. This makes developing software a far more complex process than building or renovating a house;
  • Understanding the customer’s domain: The processes that are being automated by software are intangible. To successfully automate a process, one must understand it’s rules and conditions first. Software requires black-and-white decision trees. Customers don’t think about their processes in this manner. And they don’t have to, because processes can be executed heuristically in the ‘real’ world. But when automating a process, every exception, every condition, every possible path has to be taken into consideration. If a process would be fully known up front by all involved, predicting scope, budget and schedule would be a lot easier. But this is obviously almost never the case. And even in that case, the understanding of a process often changes during the development process ;
  • Interdependancies: Software usually requires many different components to succesfully interact. 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 writing code a very delicate process;
  • Difficulties in communication: 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 process. Customers usually have a hard time understanding the technical finesses of developing software, while developers have a hard time understanding business processes. Although Agile methodologies try to limit this miscommunication by putting everyone together frequently, it is still a challenge that adds noise to the process;
  • Expertise: Developing software requires many different expertises and practices. Each expertise adds a layer of complexities;
  • Many unknowns: Software development entails a lot of unknowns. When you start, you often have a vague idea about what needs to be implemented, but understand that more analysis will be required at the time. 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;

I think the major misconception here is that software development is often equated to writing code. This makes comparisons with assembly line work, building or renovating a house or some other physical job understandable. Although writing code is a very delicate, very hard and difficult job in itself, the majority of uncertainty is introduced not by writing the code, but by determining what needs to be written, exactly.

Maybe we should stop calling it ‘software development’ altogether, because it implies that we are merely ‘building’ something. The majority of work is often not even in ‘building’ (or writing) the code, but the process that goes on before writing any code. In a sense, calling it ‘process automation’ is probably more useful and makes customers more receptive to the creative and innovative aspects of the process (that often cause the most change).

Advice 3: Just do it, show by example

Although the above might help to explain to a customer why an Agile approach is the best approach to software development, it might not convince them as first-hand experience will do. Just doing some sprints with a customer as the product owner will hopefully show them where the complexities of software development really lie, and that change is always going to happen.

Back to the customer, and how to sell Agile

So back to the customer and the renovation analogy. It is obviously a false analogy. The challenge in software development does not lie primarily in writing the code (although that is challenging as well), but in figuring out what to write. When you renovate a house, you already have a good idea on what you need to do. As such, the scope is much smaller and less likely to move. The reality of a lot of construction work is that it still costs more as anticipated though. If a customer compares software development to renovating a house, they clearly don’t understand what it is that we are doing in the IT sector. But you can’t blame them. The analogy is easy to make, and is also made by those working in the field. I hope this blog showed you that it is more useful to focus on the advantages of the Agile approach and that customers often need to be educated on why software development is not a predictable process. If you can achieve this, it still doesn’t mean you’re going to get a signature for your project. But it will make the customer more receptive to an Agile approach.

In reality, the challenge is still to compete with the many competitors that do offer a fixed price for the same project. And customers still have to explain their budget to upper management. Although not perfect, there are several ways to do this:

  • Convince them anyways: Try to convince your customer anyways and sell sprints rather than a fixed price. If the customer prioritizes correctly, the first sprint can already deliver working functionality. Also, the actual risk is only 1 sprint;
  • The first sprint is no-cure/no-pay: Many customers have trouble believing in the benefits that Agile may have for them. Agile requires mutual trust. The customer has to trust that the development team will work as hard as they can, while the team has to trust that the customer honours their limits to how much they can complete in a sprint. In order to build this trust, it might help to give a customer a ‘taster’ of Agile. Make the first sprint no-cure/no-pay. If the first sprint was successful enough for the customer to warrant more sprints, the first sprint will be charged retrospectively. Of course, this requires fairly short sprints (one or two weeks) and a sprint backlog that really delivers value quickly.
  • Fixed price for product backlog: You can also set up a product backlog with the product owner and estimate that with the development team. You can use the estimates to determine the number of sprints required, based on an estimated sprint velocity. The sprints can be translated to a budget. There are a lot of ‘estimates’ here, so use a good margin multiplier (40%-60%) of error. Be open about this to the customer and explain that you have to cover the risk of changes in scope. Also, keep in mind that point estimates for product backlog shouldn’t really be used this way. They are for relative complexity, not as a substitute for hours. Once the sprint is underway, the product owner can change the product backlog, but only be replacing items with similarly sized (in terms of points) items. Priority can of course be changed. The advantage of this approach is that it allows iterative development with a fixed price and can accommodate some change during the project. The downside is that it uses a lot of estimates that are very rough, and thus risky. It also allows for a lot of ‘contract negotiation’ during the project, as the product owner and the team argue over interpretations of vague product backlog items.

Concluding thoughts

Selling your Agile projects will be incredibly hard. This blog might lead you to conclude that we know pretty damn well what we are doing at my company. But despite the internal success, we are struggling with this as well. But we are experimenting, because we really, really believe that an Agile approach is the only way to deliver high-quality software in a process that is sensitive to the customer’s needs. And that’s where the key lies; you have to really believe it yourself first. Only then can you convince you customer how they needs are met.

Good luck experimenting! And if you have any thoughts on the subject, please drop a line! I appreciate any advice.

Image for post
Image for post
You can already support us with $1/month. Find out more on patreon.com/liberators

The Liberators

The Liberators: Unleash The Superpowers Of Your Team

Christiaan Verwijs

Written by

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.

The Liberators

The Liberators: Unleash The Superpowers Of Your Team

Christiaan Verwijs

Written by

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.

The Liberators

The Liberators: Unleash The Superpowers Of Your Team

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store