Waterfall vs. Agile: a case for simple development

I haven’t written much on development practices lately. Time to catch up on one of my personal hobbies. I’ve been challenging the current trend to call everything “agile development”. Anyone who has followed my posts (on my old blogging site) will know: I’m not an agile methods poster boy. Too often I’ve seen projects burn and fail because a project or company decided to introduce agile methodology without setting up the team for success. No matter which development style you follow: introducing a new set of processes takes time, dedication and a lot of work. I don’t think that agile methods can’t work. But taking a look at the hype-curve these are for sure at the crest of the wave.

My first question is: would a developer develop differently depending on which management style you use? Yes and no. The factors that define how a developer develops I would say are:

  • the requirements,
    No matter what, at the end of the day what gets developed is directed by the requirements. How and what requirements are requested for by the user is strongly dependent on the level of understanding by the user. So his understanding will actually dictate – and I think very, very strongly – how and what a developer develops.
  • the amount of time to develop the solution,
    If time is available, the developer will make sure that the solution is future-proof (as far as he can), flexible and consistent.
  • the flexibility of the architecture
    No matter what – at the end the overall architecture will determine what the developer can do
  • and his motivation
    Depending on how motivated a developer is, he will either go out of his way to make it right or just code a simple solution.

The question is: how much do agile methods influence these factors?

  • Requirements: The way the user requests the requirements depends strongly on how much the user understands the system. Sounds trivial, but this happens more often than one might think. Especially in the beginning of a solution users tend to have sky-high expectations and ideas and don’t realize the amount of work it creates and how little some features might actually create value.
    Here many agile methods profit from an iterative approach. Because the user is confronted with reality early and often, the amount of communication effort is reduced and simplified.
    The down-side is that the developer must develop a feature in such a fashion that it is presentable to a user in a short time. Especially in the beginning of a development cycle solutions require quite a set of skills from developers. For example: if I write the feature “Print data” I first need to set up logging, tracing, error handling and other plumbing. If I don’t take a careful look, develop with foresight and have a few tricks up my sleeve how to set up a skeleton, this will not work well and lead to a lot of rework further down the road.
    At the end though, iterative development is not something necessarily limited to agile methods although it has popularized it. One can still use a phased and more formal development style and still take an iterative approach. It is really much more dependent on developers who are used to working in that fashion.
  • Time to develop: the more time a developer has, the better the solution one would think. Actually that is not necessarily the case. There is research that make a case for not providing too much time as the overall return drops off after a certain point. Many managers therefore deduce that you have to keep the pressure up by giving the developer less than necessary time. (The Scotty-Effect) The result is a sub-optimal solution with early success but a heavy price to pay further down the line. A great book on the subject of software estimation and finding the magical “necessary time” is “Software Estimation: Software Estimation: Demystifying the Black Art” from Steve McConnell and in this connection the chapter “Is It Better to Overestimate or Underestimate?”. The point here is: agile methods doesn’t really help you to find the optimal effort for a give problem. Where it does help is to break down the work in to more easily estimated portions and get a grip on these more easily. But to be honest: take a read of the book, even big estimates can be up to 10% accurate if done correctly.
  • Architecture flexibility: without loosing too much words on this, the skill and experience of the architect and the developers is the most important determinant for this. No two ways about it. The only question is how to get the optimal mix of oversight and independent work. Different methodologies have a different concept here, but at the end this is truly not dependent on the method.
  • Developer Motivation: is often dependent on the “interesting, new code hacking/administrative work or maintenance work” ratio. Depending on the developer of course. This is the most seductive part of agile methods. They raise the prospect of not needing as much administrative work as other methods and in turn raise developer satisfaction and unleashed the shackled developer. In fact, agile methods require much more discipline even if you fill out less documents, as any Scrum Master will certify. The major question therefore is “how high is the necessary administrative work”? Again this is not dependent on the method you follow but how you implement them. Even a complete, fully processional setup will and can tailor the necessary non-code relevant work to a minimum. I still wonder how much overhead conventional methods have compared to agile methods for this to actually give a noticeable edge to be honest I don’t believe noticeably much. On the other hand, a feeling of more freedom and space can be very motivating for developers.

So … reviewing the pros & cons, I would say agile methods have important and relevant points to contribute. I believe especially that an iterative approach can be very valuable. On the other hand, agile methods tend to be adopted by the development team without the buy-in of the customer. Often import communication tools with the client like risk and change management are considered superfluous having the project run against the wall not because of development skill but poor client management skills. Especially in consulting scenarios (and not in-house development), the efforts involving communication with the client can be more than the actual development..

Conclusion: what I’ve mentioned several times, is that it is strongly dependent on the goals of the client, the skill of the involved developers and how the project manager organizes the processes. Agile methods provide an option and point to solutions to everyday problems in development. They are another Tool in the project managers tool box.

Each approach has its strengths and weaknesses. And understanding when which mechanism is appropriate is the challenge. No method with all processes in place fits all projects and is appropriate in every situation. Choose the one that solves the set of problems most, adapt it and adapt it as the project progresses. In an innovative, completely new area of work I would go with a more iterative, agile approach while in a more settled and business critical system I would take a more waterfall like approach. Whatever you do: keep it to the minimum necessary to achieve your goal.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: