One of the problems with the waterfall model is that it forces your client into think through all possibilities at the beginning of the project – and then commit to those requirements and designs or face the potential pain and cost of change control. Unsurprisingly most clients don’t like this situation. But then nor do the development teams, most of whom would rather adopt a more agile approach.

There are plenty of reasons why we end up in this situation. The process might have been foisted upon a project because its seen, by the company, as a way to maintain control over the project costs, scope and delivery time frames; even if there is evidence to the contrary. But I also think it happens because people get use to delivering projects using the waterfall model. So much so that people don’t really understand what it means to work in a more Agile fashion. They don’t really believe that results will be delivered throughout the course of the project, nor that the team should learn what works and doesn’t, and throw away the later.

Instead clients believe that they must ‘get it right’ during the requirements and design phases of the project because they fear that this represents their only chance to influence the final product. Clients therefore tend to throw all their ideas into the pot before the project team sets off on a development death march. It is difficult to get clients to trust that there really is a different, better approach.

It seems to me that to get out of this conundrum you need to demonstrate the approach, to fall forward quickly and deliver tangible outputs en route. This means breaking your project up into independent partitions each with a deliverable every six weeks or so and accept that if you make mistakes early you will get to the solution more quickly.

But how to start? It can help to find an ally and agree a bit of guerilla development to demonstrate the approach to the wider team or client. Just be careful that the entire project isn’t delivered that way. Or when gathering requirements – spend your time in situ and produce wireframes to illustrate the product so that when your done you can build an executable prototype rather than a requirements catalogue. That way you can demonstrate how you plan to proceed.

Then keep moving forward maintaining your deliver timetable. Remain flexible if you get stuck and risk not making your milestone: descope that feature, hit your milestone and put it into the next sprint.