The Agile sales pitch
So your teams love to work Agile and are in pursuit of finding the highest value for your clients and end-users. Still your clients live in a world where ‘buying features for fixed prices with contractual deadlines’ are the standard. This is very understandable as ‘What are we getting for our money?’ is a logical question upfront. Certainly if your leads want to compare vendors and decide on price.
So I keep questioning how do I sell the Agile way of working to a world that is just not ready for it…
The contract
Contracts with fixed scope often lead to Big Bang solutions. You get the product at the end of the deadline and with some luck it meets the contractual requirements. Shouldn’t the world know by now that requirements defined upfront are not actually what is required in the end. Around 65% of the features in most products are never used, so why do we build them? Just because of the contracts? I guess so… Instead Agilists focus on delivering the value that is most important NOW and then adapt the plan after every iteration as we gain more knowledge about what works and what is really valuable.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Delivering working software is the primary measure of progress.” — Agile manifesto
So instead of having contracts focusing on requirements we should change them to focus on collaboration and flexibility. Sounds good, but how do I win the pitch. My client needs to understand the price of this new feature or product upfront. This should not be any different than selling software in the traditional way, but instead of putting the estimations and requirements in a contract suggest a development budget that meets this products size. Each iteration the clients gets a piece of working software and the budget slims down accordingly, until the envisioned functionality is achieved.
In the contract give the client room to cancel at anytime. This should make the Agile approach relative risk free, more so than with a fixed scope contract, where you just have to pray (for a miracle) you get what you payed for at the end. For example the client could cancel the contract because enough valuable features have been delivered or because after a few iterations it is clear that this product will go over budget gigantically.
The win for the client could be that the must have features are delivered under budget. This is pretty realistic if you know how to find the 35% of the features that will really be used instead of building what was envisioned at the start with the least knowledge. Software product evolve the best when being used by actual users. This leads to understanding what really works and what doesn’t in the real world.
The win for the development team is that possibly the client is so happy with the pace of getting new feature delivered that they will keep paying the team indefinitely to keep extending the product as the market changes.
Do add a clause in the contract that if the client cancels a percentage of the remaining budget is handed over the development team. This in order to give the team the room to find a new client or product to start working on. A percentage normally between 10 and 20% seems reasonable. Jeff Sutherland describes a scenario like this in his latest book.
As the requirements or now not part of the contract, we can focus on collaborating and finding the most valuable features without worrying about someone at the client suing us, because we didn’t meet our contract by 100%.
Or as the Agile manifesto says: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
You do need a contract, but not one with all the details in there.
The cost
So what does a feature cost? Most Agile teams estimate in story-point. Story-points are a relative estimate based on the complexity of features (also called stories). Each iteration the teams completes a number of story-points and the average is their velocity. Now if you take the total cost of the software development team (e.g. salaries, hardware, housing, commuting and any other costs the team has.) and divide this by the velocity, the result is an average cost per story-point.
For small features you can charge this story-point cost after you add enough profit margin. For larger projects or products this is a little bit more complex. Estimating a large backlog of requirements is time consuming and boring, but sometimes it is just what you have todo. Maybe you have some previous projects of relatively the same size and you can re-use estimates and some good safe margins to get to a good budget. Never forget too let the people who do the work do the estimates, never think you have so much experience in selling software products that you can do the estimates as a sales person. This will only lead to unnecessary pressure on the development team as your estimations where off. Also do not take hallway estimations (estimations gotten from a single developer in the hallway) as a guideline, since most developers are very optimistic. As a group the team makes much better estimations.
So what you are saying is that we should charge our client per story-points and not per hour as is the industry standard? Yes, that is what I am telling you. I think there is no need to keep an hour book-keeping if you charge by relative sizes per team per iteration. Also this is more accurate than the hourly rates as time-sheets are just made up at at the moment of conception. Relative sizes include all costs the team makes, not just the hours spent on the features. Another thing to keep in mind is that developers perform 10% less on average when they need to keep a book-keeping as stated by Jeff Sutherlands in his blog ‘Time tracking is anti-Scrum’.
The final pitch?
Don’t pay for features you do not need, minimize risk by working in short iterations and start monetising after the first most valuable features have been delivered as working software. Why settle for less?
“Customer collaboration over contract negotiation. Business people and developers must work together daily throughout the project.” — Agile manifesto
Give the client more safety by letting them pay per iteration. This in order for them to get a good feel of the Agile way of working. Maybe think about giving them a bit of discount if they pay a couple of iterations upfront.
In the end the most important thing is collaboration and trust between the team and the client. Together they can build innovative and great software products. Don’t let a contract get in the way.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” — Agile manifesto
