Yeah, I think I'd be more comfortable with fairly well defined requirements up front. They might not be that detailed, but you have to know what you're aiming at. And I think you've and interesting point that I'd maybe not really realised – that actually, a traditional approach and agile approach maybe aren't all that exclusive.

And your third paragraph made me laugh. That's pretty much exactly what we're seeing – the idea that “Agile” somehow makes use 200% more productive, and technical debt building up, which is hard to get buy-in to get paid off. “Refactoring the data access layer – what does that give me?” and “Proper packaging – well it deployed last time, why would we want to do that?” – both not sexy subjects, but essential to a well run system.

Still, it's all interesting.

On your point, the customer absolutly has to “GET” agile. This really is the biggest challenge to adopting agile is getting the customer to understand the benefits of the iterative approach, and the best way to do this is to start delivering and continue delivering.

A lot of projects work this way, if you talk to Eric Shrupps he works more this way with farily well defined requirements up front. What you can still do is set priorities (I know the customer wants it all) and then deliver stuff often but based on this priority. The first project may even follow a very traditional style with the customer not engaged and not changing anything on the backlog, but showing them the solution as it developes will provide confidence and start to get them involved.

What agile won't do is allow you to achieve more than is possible, if the customer says we need all this in this timescale, and it is impossible what aspect do you drop? Quality! What you actually do is borrow from future projects and build up technical debt, this debt needs to be repaid at some point. However most customers just see that hey, if we say it loud enough it will happen, heck the devs are just on Twitter all day anyway. Eventually it will come back to bite, the problem is customers have had years and years of history and experience that is hard to break down.

And yes a Scrum meeting, or daily stand up or whatever you want to call it is a brilliant way to help get shared commitment and understanding within a team even if the project is not following an agile approach.

We've been doing our first 'proper' scrum project recently, and actually, I think that your series of posts might miss this little issue.

In our case, the customer knew that the didn't really know what it was they wanted, and felt an agile approach would work best. Unfortunately, they've got internal deadlines, and not everyone has bought in to the agile approach. We find ourselves with in a position of doing agile but “we have to have all the features, and it must be by that date” (and that date is pretty close). Consequently, we've actually ended up with something that kind of approximates waterfall, rather than agile.

So, I guess my point is that the customer really has to “get” agile, and have someone with authority to set the product backlog leading the project at there end. But I guess this isn't an issue if you're the customer too!

And I reckon that Scrum meeting would still be useful in a waterfall project, for smallish teams.