Steve Eichert asks the question: Are clients read for Scrum? I say yes. Being in the consulting world for a few years now (almost 5 - not a ton of experience, but enough), I've seen companies slowly make the change from looking at things from the waterfall approach to a more agile methodology.

Why are they open to it? Because they've been burned by the Waterfall approach - or those implementing it have been. Remember, most consulting companies (at least ones worth dealing with) will do whatever it takes to make things right - even if that may mean losing some money on the deal. Customers see this and start to get an understanding of why the waterfall approach isn't the ideal way in some cases.

So just because they've been burned by the waterfall approach (can you be burned by a waterfall?) doesn't mean they automatically turn to an agile approach, does it? Lots of people were burned by gas prices in the '70s, but we didn't turn to other transportation options. We optimized cars to use gas better. So you're really left with two options: 1.) Optimize the waterfall approach, or 2.) try something else.

That something else is an agile approach. How can that appeal to a client? Well, from the client's perspective, they can better budget for it. I know that sounds odd, but I believe it. If you start from a burn rate (X developers times Y dollars per hour times 40 hours a week equals a weekly burn rate) and a budget, you know exactly how long the project will run. The question then becomes functionality. Using an agile approach, you prioritize those features, building the most important ones first. So now when your budget runs out, you may not have everything, but you have your top priorities, and probably (unless your budget and functionality are way out of whack) most of your medium priorities in a usable system. So you don't get the low priority ones, but those can be left to be done after launch.

On the other hand, if something goes wrong with the waterfall approach, such as the time estimates being wrong, you may be left with an unusable system. Why? The waterfall approach doesn't prioritize development in line with feature priority. So, using a waterfall approach, writing a caching solution that uses background processes to expire cache may be scheduled to be written early in development as part of the application framework. But that's not really a customer-centric feature, per se. That's more of an implementation detail. If those types of tasks take longer than expected, you may end up with a complete framework, but no application to sit on top of it. That's bad.

So far from what I've written, it sounds like it should be an easy sell. It's not. Customers do have an ingrained tendancy towards the waterfall approach because that's what has been preached to them for so long now. It will take a while to get them to come around to the agile approach. And the way to do that is to become a trusted advisor to your client. If they trust that you know what is best for them, then they will listen to you when you say an agile methodology is the best approach.