{"id":616,"date":"2010-04-07T10:42:36","date_gmt":"2010-04-07T17:42:36","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=616"},"modified":"2013-08-01T10:03:37","modified_gmt":"2013-08-01T14:03:37","slug":"dont-go-chasing-waterfalls-mini-waterfall-vs-agile","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/dont-go-chasing-waterfalls-mini-waterfall-vs-agile\/","title":{"rendered":"Don’t Go Chasing Waterfalls (Mini-waterfall vs Agile)"},"content":{"rendered":"

There is a large amount of confusion in the software development world today about the difference between Agile\u00a0and mini-waterfall. \u00a0Just because you are having iterations, doesn’t mean you are being Agile.<\/p>\n

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

What does mini-waterfall look like?<\/h2>\n

\"diagram<\/a><\/p>\n

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. \u00a0The cycle begins again for the next user story, or next iteration.<\/p>\n

At a surface level, there doesn’t seem to be very much wrong with this picture. \u00a0In fact, you may have just said to yourself “that is exactly what we are doing, and we are Agile.” \u00a0Here is the problem: \u00a0The user doesn’t get what they want.<\/span><\/p>\n

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?<\/p>\n

By the time you get all the way through the chain, you’re pretty unlikely to still have the original vision right. \u00a0That is assuming you have a user, product owner, or business who can state exactly what they want upfront.\u00a0 \u00a0Which is highly unlikely.<\/p>\n

The only difference between this approach and waterfall is that you are going through the cycle more often. \u00a0Your feedback loop is tighter, but not tight enough.<\/p>\n

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. \u00a0That is a long time before the end user is happy.<\/p>\n

What does true Agile look like?<\/h2>\n

\"\"<\/a><\/p>\n

The picture is not all that different, but you can see that there is not a distinction between the phases of software development. \u00a0Instead, with a true Agile process, we are focusing on very tight and short feedback loops. \u00a0The 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.<\/p>\n

There is no need to separate out the design, coding, and testing because these things should be happening\u00a0simultaneously\u00a0as 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.<\/p>\n

John… John… John… you crazy dreamer… You can’t test something before it is built…<\/h2>\n

Yes, true. \u00a0But what is “something”? \u00a0The size of the something is what matters. \u00a0We want that something to be as small as possible, so that our process is continuous. \u00a0It is a flow rather than a rugged bumpy road.<\/p>\n

Think about it this way. \u00a0If you have some background in math, you might be familiar with limits<\/a> or if you’re into banking, you might be familiar with the idea of compounding interest\u00a0continuously<\/a>. \u00a0I 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\u00a0instantaneous\u00a0as possible.<\/p>\n

The same idea we should be having with software development in our iterations. \u00a0We want to have our feedback from our user or business be as close to continuous as possible.<\/p>\n

Yes,\u00a0ultimately, 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. \u00a0In fact, if the tests are driving the design and development, this process starts to become natural.<\/p>\n

If you want to stop thinking mini-waterfall and start thinking Agile…<\/h2>\n

stop thinking about building software serially, and start thinking about doing it in parallel. \u00a0Stop thinking in terms of:<\/p>\n