Argument against Waterfall
As I am reading Robert Martin’s old Engineering Notebooks on Iterative and Incremental Development I came across a business argument, perhaps the best non-engineering argument of which I have many; against following Waterfall software methodology. You are welcome to download all his PDF docs from ObjectMentor’s site via this googleq:
The iterative process is producing data about the schedule. The completion times of the slices are giving us unambiguous empirical measurements that help us predict when the project will be complete. There is a wonderful thing that mangers can do with these measurements – with this data managers can… manage. They can stop dictating, stop motivating, stop losing control Don’t let this article mislead you. If you follow the advice above and begin developing projects in an iterative and incremental way, bluebirds will not fill your sky. Schedules will still be missed, there will still be bugs, problems, and mis-aligned expectations. Software is, after all, software; and software is hard. However, what you will be doing is using a process that produces data; whereas waterfall produces none. With that data, managers can try to manage the project. (…)a process that produces data can be managed. A process that does not produce data, cannot be managed.
I dig this argument: producing data about the schedule. I can see why in Scrum you should be keeping track of past Sprints and why you should be looking at how many backlog items are “YET TO BE DONE” and not DONE VERSUS PLANNED as happens to be the model in Waterfall. I think this is an important distinction. - In traditional Waterfalll you Plan what will be done with the assumptions that no changes will occur - but what if you can produce data everyday about how many items are yet to be done? how many are planned? you can calculate your running conversion, hence burndown chart, hence velocity as a measure of effectiveness.
I don’t have much experience with Scrum since most of my work has been on Test Design in what I would call Waterfallish type of project, however I must admit that my engineering process for Testing software has been iterative. I devised plans that were based in uncertainty but I never tracked data about my schedule, partly because I never designed it nor have never been on teams that designed it. Since Test Management is about repeatablitlity let me make a strong recommendation to myself and my team now to implement such a measure.
Comments (2) to “Argument against Waterfall”
Post a Comment
You must be logged in to post a comment.
dkemp wrote:
It is difficult to imagine a project where results are repeatable. Haveing spent the past ten years testing software on teams using every methodology known to man including no apperent methodology. Waterfall, iterative, its just a label that all equals teams running around like heads with their chickens cut off stomping out fires. I recall a conversation with my Test Manager about process where I had suggested we attempt to ‘plan’ how we intend to impact quality. I said, “We are always reactive; why not proactive?” He said “When the house is burning down around you you need to get as many people as possible to help throw water on it.” I said, “If the house if fully engulfed and the outcome obvious isn’t it more productive to walk away and build a better house that is more fire resistent?” I was thinking about the ‘Three Little Pigs’ fairy tale. He said, “The people who pay the bills for that house are paying for us to bail water, not build a better house.” How do you argue with that logic? This scenario plays out every release leaving a chared pile of half built product nobody wants to occupy. The customer is paying the bills and therefore has every right to burn it to the ground and complain to us that they aren’t happy with the result. They could care less about managing process unless it makes them look productive and can keep getting paid. The idea that ‘processes’ alone make better software is in my opinion an academics argument that has no chance of survival in a real world situation where millions of dollars are at stake and the people shoveling the pile (paying the bills)haven’t commited to it. The money doesn’t care what labels we use or about process. All they want is happy people buying their product like hotcakes and paying them big bucks for it. Screw process! Make yourself look busy and keep bailing! Is the check good? Whats to worry about process? Oiy.
Posted on 08-Feb-08 at 9:30 am | Permalink
Gregory Robinson wrote:
Great Post!
Posted on 19-May-08 at 3:56 am | Permalink