How to sell Agile development to (waterfall) clients

Question

Our development shop would really like to do more agile projects but we have a problem getting clients on board. Many clients want a budget and a deadline. It's hard to sell a client on an agile project when our competitors do come up with waterfall-based fixed deadlines and fixed prices. We know their fixed numbers are bad, but the client doesn't know that. So, we end up looking bad to the client because we can't fix the price or a deadline but our competitors can.

So, how can you get your sales force to successfully sell a project that uses agile development methods, or a product that is developed using such methods? All the information I found seems to focus on project management and developers.

Answer 1

The key to doing this well is by use of a support contract.

Basically, when you first sell the client, you sell them based of your expertise, and you do it waterfall. That means a contract that sets the scope and a firm dead line. This is what the client wants. The client more or less knows the scope. Waterfall works very well, in a fixed & defined scope environment, I would say it works better than agile in such environments. And in this case it gives the client a level of comfort when the tendency is to be nervous because he has never worked with you before. That’s Ok, Agile is not always better then waterfall.

So you have a fixed price contract for X scope. Then you tell the client “Look, you are going to want to make changes, and you are going to need us to support you post production, let’s set aside 20% of your budget for these things to be used on an as need basis by means of a support contract.”

Should a change come up during the project, simply defer it to be handled under the support contact. (Assuming this change would cause a serious disruption to the project)

The terms of the support contact are as follows “Work to be done on a per hour basis, as requested by the client, can be used for change requests or general system support and maintenance.” BAM! You are in Agile.

You can then continue to extend the support contact, and simply use the support contact as the means to run new projects. Additionally if these hours are purchased and paid for upfront, we usually give the client a 15% discount. It's Win-Win.

Answer 2

Agile doesn't preclude deadlines and budgets. If I was a client and I went to a developer and they told me that they couldn't give me a deadline or an estimated cost, I'd question their sanity. And telling them that they just don't understand isn't going to work: they need to be able to budget and plan.

They don't need to know your development process. They need to know how long it's going to take to develop features and how much its going to cost. Give them a number based on the (spurious) assumption that their requirements are 100% accurate, and when their requirements change, then change your estimates.

This gives them the budget line items and deployment dates they want, and when things change, your process lets you look flexible and accommodating.

Answer 3

It sounds like your salespeople are creating a layer of miscommunication between your development teams and customers. If they haven't been selling in the IT marketplace for a long time, they may view their role as 'move the product', meaning get a signature on a contract 'whatever it takes'. In short, they're motivated to close, regardless of what they're promising. In such circumstances they're going to track the language of the customer as closely as possible.

I'm a broken record quoting this, but here goes: you're on the operating table and as you're going under the surgeon says 'we'll have you out of here on time and within budget'. Great. Will I be alive?

If you are working on the internal organs of a business, do you stop at some arbitrary point? Typically an application is affected by forces neither you nor your client controls - regulations, business climate, competitor behavior, the emergence of some new paradigm, etc. If you simply say 'we will do 'thing x' for 'price y'' then the customer will come back three months later and say - 'well...'. Generally meaning that they know something that they didn't know when you agreed to a waterfall project.

What might work in such a situation is demonstrating to your own sales staff what a drive through a canyon is like. At every turn there are surprises. It isn't possible to see more than about three months out, so if a customer is asking for an 18 month project it will be unrecognizable by the time you're near completion. Therefore your sales rep needs to start out by finding the financial payoff of the project. Will this increase sales by $10 million? If so, is it worth investing $2,000,000 to make that additional $10 million? If the customer and sales rep are converging on a $500,000 commitment, then something might be wrong and no one can tell what it is - it just doesn't feel right. What 'isn't feeling right' is a commitment to doing something that runs the risk of being useless.

The two latest jet airliner models have had a history of snafus. Healthcare.gov doesn't even need discussion. If you can find books or trade press stories on the airliners, you can bring up how certain assumptions were made that proved to be optimistic, and that the projects missed their deadlines repeatedly. Often this was due to underestimating complexity. If you can't really figure out how complex it is until you start coding it, you'll need an 'initial round' to get a better idea of the real problems. The budget cutoff should be some fraction of the total additional profits (or revenues in some cases), and that number has to be more than anyone thinks the current project will cost. If you can show how the last milestone can be passed without exceeding the 'payoff limit', it should be possible to sell the project as an agile effort.

Answer 4

The main hurdle in achieving the benefits of Agile-Scrum outside software development is integrating it with existing control mechanisms. These control mechanisms are stipulated due to various organizational prerequisites and are normally actualized by using the Linear Waterfall approach and methodology.

Four of these typical organizational prerequisites are depicted below:

• Big global corporates – in these hierarchical matrix organizations, top down portfolio control is the rule of the day. The free spirited agile approach has a tough time adjusting to the rigorous controls. Specifically the inherent Agile plan-free concepts, make Agile-Scrum difficult for the organization to swallow.

• Highly regulated industries – some industries are required by compliance and governance bodies to have a strict binding control mechanism. These can be for example medical equipment, aircraft, and pharmaceuticals research and product development business units. While individual teams might operate Agile-Scrum, the development process must follow a rigid Linear Waterfall approach method for traceability and governance.

• Complex predefined products – some integrated products which include both hardware, software, imbedded and more are developed as a contract with an end customer under a predefined set of requirements. In these cases the degree of requirement flexibility is small, though larger than what is anticipated initially. The concept of a fully flexible backlog of Agile-Scrum suffers considerably in these cases.

• Generic IT departments – much of the daily and weekly activities in maintenance driven IT departments is ad hoc. Changes to the daily schedules are numerous and immediate. Constant interferences in the teams work are the norm. The concept of time boxing and no interference is difficult to maintain in these situations.

Naturally – many times the four discrete categories detailed above, actually mix; so it is common to find a complex product in a global big corporate which is required to comply with firm regulation.

Based on practical experience, the recommended method to tackle these scenarios and others is by empowering the Agile PMO to act as an enabler, driver and translator between the emerging Agile-Scrum teams and the Linear Waterfall elements.

Refer to the table below for specific guidelines

Source - Interfacing between Linear Waterfall and Agile Approaches by Michael Nir

Answer 5

We set up 2 or 3 estimation sessions with the potential customer and our developers where we discuss the work at hand and set the acceptance criteria. The developers estimate the work in story points during the meeting.

Afterwards we sell the customer a number of story points. This is possible because he has a good idea of the value of the story points. We tell him that he has the possibility to fine tune his backlog/scope during the project and that it will be easy due to the use of the story points. We also tell him that there will be a frequent delivery of working software so that he can monitor the progress and get new insights.

By agreeing on a number of story points the customer is guaranteed to get value for his money. If he doesn't change his backlog he has his fixed price/fixed scope project, but my experience is that he will make changes. By doing the estimations in the presence of the potential customer we try to build a relationship based upon openness and trust.

---

We managed to convince clients like you describe, who "want a budget and a deadline", and they were happy we wanted to really understand what they needed, instead of working from a document. We showed that we wanted to invest in these projects.

During the estimation sessions we estimated their entire backlog. This gave x story points. We suggested to add 25% for those features that weren't yet clear or known at the time. With the estimated backlog attached to the contract they were reassured that they would get everything for the fixed budget.

Originally the bid was time and material. As they wanted to have a fixed price bid, we suggested to work for the price we gave them and use the 25% extra story points for contingency. If things went well, the part of the 25% that was not used to cover the delays we encountered would be used to deliver more functionality for the customer.

This stimulated them in a number of ways: first, they did everything they could to enable our developers to work as fast as possible, as this was clearly in their own interest. We never had to wait for answers to questions. Secondly, they really understood the concept of the story points. Before the project started, they had already removed some of the stories and asked us to estimate other stories. No complicated contract negotiations were needed for this.

We kept them informed of the progress and kept a very open communication. They got a progress report every 2 weeks: x % of the story points done in y % of the estimated time leaves z % of the extra story points available. We had a bit of a difficult start but managed to catch up with the estimates by the end of the project, which left 100 % of the extra story points available for extra development. The customer was happy because he got everything he really needed (and that was a bit different from his initially requested features, he removed some and added others).

The customer was also happy because everything was delivered in the foreseen timeframe (where he also did everything possible to help us like chasing tickets, answering questions immediatly, involving the users in weekly analysis meetings and also involving them in functional testing).

My company was happy because we delivered in time and on budget. My company was also happy because the success of this project opened the door for more projects. We even got mentioned in the monthly magazine of the customer that was sent to people worldwide.

Doing good estimates was the most difficult part of the project, but having the estimation sessions up front helped us to understand the difficulty and the risks. It enabled us to give an estimate based upon facts and removed a lot of the unknowns.

Answer 6

Trying to use Agile methods in a consultancy/bidding environment is very difficult when the customer is not on board.

If they are used to Waterfall style "here are our requirements, how much and how long will it take?" type projects, and are putting it out to tender there isn't really any time to convince them that Agile or any other way is better.

Agile has its advantage (and disadvantages of course), but quite frankly the customer often doesn't know or care about the detail behind the scenes.

They want 2 things - cost and time scale. And once you tell them that, they then want it cheaper and sooner. And you know what, we want it all. All the requirements. None can wait, or be chopped.

And as much as I dislike sales people in most walks of life, don't be too hard on the sales guys. That's a tough job.

They don't build software, they mostly have no idea how it all works past the buzz words.

Yet they have to come up with time scales and cost based on some woolly requirements meeting. Maybe they have some of the tech guys with them to reign them in, but they need to make a sale to keep things going.

Answer 7

So, how can you get your sales force to successfully sell a project that uses agile development methods, or a product that is developed using such methods?

By having your sales force bring the customer in to the office. The entire point of agile is to get immediate feedback from the client so that you can produce what they want (and no more). Bring them in, ask what they want. Two weeks later, bring them in and show them a demo/prototype. Sell them on that interaction. Show them progress and explain that this sort of iteration is what you'd like to do so that they get exactly what they want.

Give estimates for the amount of work necessary (that's what a budget is after all), but let them have the power (read: responsibility) to include what they want to fit into their budget.

Answer 8

I think the answer is that for most cases you probably wont. I would try and see this initially as a small part of your business - perhaps 20%, with the rest under a traditional model. Over time I would try to focus more on the Agile products and clients and try to make that part grow more.

Another part of tackling this is perhaps to try and use both approaches. Use the waterfall approach with the senior management and contract negotiation folks. For example 'a system to allow clients to maintain portfolios and make investment decisions using both browser based and mobile phone devices (Apple and Android).' or something like that. Then use Agile for the development team's development on the more detailed features, e.g., Create Home Page, Create Login Page, Create Portolio Management History, Create Mobile Login, etc.

Another idea is so make Agile your differentiator. I know that many if not most large organizations are not doing Agile. However most (the vast majority in my experience) of small companies are. I think that Agile is growing rapidly and this will continue. The advantage of this route is that you are pitching what you most want to do to the customers who already recognize it. This approach will require some work over time with no guarantee of success.

You might also find some traction if your clients like testing. Having well-tested products can be an easier sell to some clients. A book that I am finding helpful in this area is 'Agile Testing' by Adison Wesley Press.

You can also use current events to support your case. For instance the current (writing this in Oct 2012) health care site is a making a great case for how NOT to handle changes that were needed 2 weeks before go-live. Also the apparent over-engineering would likely have been better addressed more more agile methods.

Answer 9

Contact previous clients that are happy with your work. Especially if they are Waterfall to Agile converts. At the very least, converts that weren't your clients.

Their testimonials (as a customer) will outweigh anything and everything you could say. They can address the concerns and fears of your new customer more than you ever could.

From a management perspective, a budget and a deadline is a business need for the project. You need to make sure you're addressing those needs, and if you look a business' testimonials about switching, you'll notice that comes up directly. If you look at developer's testimonials about switching, you'll notice that often times it does not.