Don’t Go Chasing Waterfalls (Mini-waterfall vs Agile)

mini-waterfall diagram

There is a large amount of confusion in the software development world today about the difference between Agile and mini-waterfall.  Just because you are having iterations, doesn’t mean you are being Agile.

I wrote earlier about how to hang a picture, as an analogy to completing user stories in an Agile way.  That example happens to be a good example of mini-waterfall vs Agile, but I’ll go into a bit more detail here.

What does mini-waterfall look like?

diagram depicting mini-waterfall

You can see what is happening here is that the user is giving some requirements, then design is done, then development, then testing and finally the completed story is delivered back to the user.  The cycle begins again for the next user story, or next iteration.

At a surface level, there doesn’t seem to be very much wrong with this picture.  In fact, you may have just said to yourself “that is exactly what we are doing, and we are Agile.”  Here is the problem:  The user doesn’t get what they want.

Have you ever played that telephone game, where you have a bunch of people standing in a circle and you pass a message on, and when it gets back to the person who originally said the message, it is different?

By the time you get all the way through the chain, you’re pretty unlikely to still have the original vision right.  That is assuming you have a user, product owner, or business who can state exactly what they want upfront.   Which is highly unlikely.

The only difference between this approach and waterfall is that you are going through the cycle more often.  Your feedback loop is tighter, but not tight enough.

Using this kind of method, if the user has a feature that will end up having 5 changes in it, it will end up taking at least 5 iterations.  That is a long time before the end user is happy.

What does true Agile look like?

The picture is not all that different, but you can see that there is not a distinction between the phases of software development.  Instead, with a true Agile process, we are focusing on very tight and short feedback loops.  The user provides some feedback, or initial thoughts about the user story, then the team works on changing the application or building something to meet what the user wanted.

There is no need to separate out the design, coding, and testing because these things should be happening simultaneously as much as possible, and each one of these aspects (not sequential phases) of software development could result in going back to the user to get feedback.

John… John… John… you crazy dreamer… You can’t test something before it is built…

Yes, true.  But what is “something”?  The size of the something is what matters.  We want that something to be as small as possible, so that our process is continuous.  It is a flow rather than a rugged bumpy road.

Think about it this way.  If you have some background in math, you might be familiar with limits or if you’re into banking, you might be familiar with the idea of compounding interest continuously.  I won’t go into detail here on those concepts, but the idea is that you are reducing the period in which you perform a calculation to be as close to instantaneous as possible.

The same idea we should be having with software development in our iterations.  We want to have our feedback from our user or business be as close to continuous as possible.

Yes, ultimately, you have to build something before you can test it, but if you can make the something you build as small as possible, you can start to mix design, build and test together so they are appearing to happen together.  In fact, if the tests are driving the design and development, this process starts to become natural.

If you want to stop thinking mini-waterfall and start thinking Agile…

stop thinking about building software serially, and start thinking about doing it in parallel.  Stop thinking in terms of:

  • Step 1: Get the requirements
  • Step 2: Design the solution
  • Step 3: Develop the solution
  • Step 4: Test

Start thinking in terms of:

  • Step 1: Figure out the first thing the user wants
  • Step 2: Build a small piece, making sure it is right
  • Step 3: Check with the user to see how to make it better
  • Step 4: Continue until user is happy
About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."

  • Pingback: Presentation on Waterfall vs Agile « Making the Complex Simple()

  • Pingback: 5 Things That Will Make Your Agile Development Project FAIL!()

  • keith williams

    semantics. the reason people are confused between agile and waterfall is because the first time they get introduced to agile is when a consultant tries to sell the company scrum. agile is a mindset not a methodology but its a lot harder to sell a mindset, a lot harder to explain. scrum IS mini waterfall, no matter how hard you try to hide the design code test deliver bits. in a pure agile team they dont do sprints, they accept change by the hour if that’s the way the business wants to operate. they deliver as soon as the code is ready which could be minutes, hours or days.

  • Pingback: Agile scrum? |()