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.

  • 24
    You're assuming that their numbers are bad because they're waterfall-based, and for them to be able to do anything right goes against a dogma you believe in. Your potential clients don't believe in that dogma, and may not have heard of it. Having a deadline and a price are standard contract things. So clients hear you trying to tell them that you have an amazing software development model, and then that you can't give them a fixed price or deadline. They want to be able to say "it will be done by this date at this price", not "I don't know when it will be done or how much it will cost." Commented Oct 25, 2013 at 18:51
  • 4
    "So, we end up looking bad to the client because we can't fix the price or a deadline but our competitors can.": If some clients feel better with a clear deadline and price, why do you want to impose a different model?
    – Giorgio
    Commented Oct 28, 2013 at 13:05
  • 11
    "We will deliver a fully-working product to you at every milestone. Features will be added at each milestone until you are satisfied that the product meets your needs. We will involve you at every step, and if you need to make changes (major or minor), they will be incorporated in each successive milestone. You risk goes down because you're only paying for what we actually deliver." Commented Oct 28, 2013 at 14:04
  • 10
    @Andrew: You surely can't use the words "fully-working" because you aren't delivering the full product, only some subset of the customer's desired functionality. You also left out the finishing part of the sentence "statisfied that the product meets your needs OR your money runs out.". Risk goes down in some ways but goes way up in others, such as not getting a product that does what you need before the money runs out.
    – Dunk
    Commented Oct 28, 2013 at 14:14
  • 5
    @Dunk Sure, but in an agile project, the ability to land certainly would be one of the higher-priority tasks, yes? And as such would be one of the first implemented? It is much more likely that such a feature would go unimplemented in a waterfall project, where none of the features need to be complete until all of them are. And if the money runs out first (as it too commonly does)? You got nothing.
    – Eric King
    Commented Oct 28, 2013 at 20:11

9 Answers 9


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.

  • 5
    Very well-motivated and balanced answer. +1.
    – Giorgio
    Commented Oct 28, 2013 at 17:32
  • 3
    +1 The customer must trust the developer before they are happy with the "agile" approach. This answer builds trust by delivering something at a fixed price, with the option for the customer to move to agile later, if they want to. And it doesn't use the word "agile", which won't mean anything to the customer. Instead it explains the benefits to the customer in simple terms.
    – MarkJ
    Commented Oct 29, 2013 at 12:50
  • 1
    This is a great approach. The only problem I've had with it, is pinning them down the initial scope. If they struggle to grasp that concept or prioritising features I usually steer clear...
    – Tim
    Commented Feb 1, 2016 at 17:16
  • 1
    Agile requires a commitment for each Sprint/Iteration. "Work to be done on a per hour basis, as requested by the client" sounds more like daily fire fighting duties with continuous priority shuffling (i.e. chaos). Commented Jul 27, 2016 at 13:25

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.

  • 2
    Great answer. The methodology you use is not the customer's problem. They still want a product and they want to know how much it is going to cost them. They certainly don't want a "fully-functional" but "half-featured" system delivered at the end. They want all the features they contracted for.
    – Dunk
    Commented Oct 29, 2013 at 14:15
  • @Dunk, agreed, but I think the "half-featured" bit mostly describes features that were requested after the initial specifications.
    – Wildcard
    Commented Jul 18, 2016 at 21:43

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.

  • 2
    "Often this was due to underestimating complexity". But MORE OFTEN this is due to the way contracts are awarded. Price is the over-riding factor with ability to do the job only a minor subset of considerations. With ACA, those companies who understood the complexity and could really do the job, because they've built similar systems before, were knocked out of the bidding process early on because their costs were too high. Thus, the contract goes to the incompetent low-cost company and agilists then try to blame waterfall. Competent companies and people will deliver no matter what methodology.
    – Dunk
    Commented Oct 29, 2013 at 14:10
  • 1
    +1 for the surgeon quote. Great way to counter the "building a house" metaphor. Commented Jun 4, 2014 at 10:14

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

enter image description here

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

  • 1
    this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Commented Oct 29, 2013 at 7:19
  • 1
    Good answer, reflecting the business reality that Agile Evangelists often fail to acknowledge.
    – mattnz
    Commented Oct 29, 2013 at 8:38
  • 2
    Please don't just copy the source and certainly not without attribution. Extract the relevant information and highlight why it answers the question.
    – ChrisF
    Commented Oct 29, 2013 at 8:42
  • 1
    I don't really see how this relates to teaching our sales force how to sell clients on agile when our competitors usually use waterfall. Commented Oct 29, 2013 at 10:49

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.

  • "set up 2 or 3 estimation sessions" -- did you try that with clients described in the question asked? With clients who "want a budget and a deadline"?
    – gnat
    Commented Oct 29, 2013 at 12:44
  • Yes, and they were happy we wanted to really understand what they needed, in stead of working from a document. We showed that we wanted to invest in these projects.
    – user99561
    Commented Nov 1, 2013 at 14:03
  • how did you manage to convince them to change their habit of just asking for "a budget and a deadline"?
    – gnat
    Commented Nov 1, 2013 at 14:38

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.


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.

  • 1
    So give them 2 weeks of free work as part of the sales cycle?!
    – Morons
    Commented Oct 28, 2013 at 13:44
  • 1
    @Morons - Yes. In my experience, there's usually 1-2 people dedicated to this sort of prototyping. Further, development is usually pulled into this sort of process anyways, so formalizing (and budgeting for) it only helps you.
    – Telastyn
    Commented Oct 28, 2013 at 14:07

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.