Fall forward quickly

DilbertOne 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.

When agile projects become mini waterfalls

Few people who have experience of delivering software projects would promote using the Waterfall Model and Big Design Up Front for managing software projects – accountants, bureaucrats and those that believe ‘designers’ possess crystal balls aside.


Most experienced technical project managers and developers recognise that a more agile approach is needed. One where the focus is on delivering working software, not ‘artifacts‘ and, where the project seeks to deliver via a series of rapid iterations not rapid recursion. This is because in addition to being more realistic and recognising that software is delivered by people rapid iterations reduce complexity and therefore risk.

There are of course a wide range of agile methods available and plenty of consultants and training companies out there promoting them. However, I fear that too often the way agile methods are employed, on the ground, is more akin to a sequence of mini waterfalls. That is there is a tendency, within each iteration, to lead with design (often creating Photoshop files) before coding up the application based on those designs. I suspect that this often happens for a number of reasons, including:

  • engineers and developers like to solve problems and are happy to solve the problems whether they are set by the client or a designer;
  • the waterfall model is still prevalent and people ‘expect’ design to start the process;
  • people tend to prefer working in isolation – agile methods require people to work in close collaboration.

These and other reasons mean that if a team is left to their own devices they tend to default to the modus operandi of design up front (even if it’s small design up front) because it just feels more natural. And of course since agile methods encourage teams to decide how they are going to tackle the work this is too often the sequencing of work they settle on. But that doesn’t make it right.

It is better for the Project Manager to encourage the team to reverse this sequence by, for example on a web project, having designers working directly with the mark-up (designing with css) where the mark-up is being delivered by web apps which have been built by software engineers. And the software engineers, they need to work with the designers, information architects and client to define what data is needed on each page – by understanding the problem and the domain model.

Photo: Plitvice Waterfalls, by mpancha. Used under licence.