In my work as an ALM consultant I will often be asked the question or told that a team can’t go and practice agile they have to do waterfall. I think they are looking at this in the wrong way. One of the things to think about in waterfall versus agile is what these two methodologies are really all about. Is waterfall really all that bad? The answer to that question is: No, waterfall is actually a great methodology and a great pattern that has worked for some projects. Not a lot in the software field; simply because in Waterfall you need to know all the requirements up front and work towards completing that plan. In other words you are working the plan and the schedule becomes king not the actual priority or benefit that you can provide to the end user.

.

Inspection and Adaption

In an agile setting, we know up front that we will not know everything that there is to know about this solution that we are designing and coding until we start. We recognize and acknowledge that as we start to develop and get early feedback that we may have to go back to the work that we have done and make changes. This is part of the Inspection and Adaption that goes on in Agile regularly. This is totally missing in Waterfall.

Before you start attaching me with your arrows and spears, yes I know you can make changes in Waterfall, heaven knows how many times I have heard the excuses that projects were not completed on time or at all because the scope kept on changing. However, lets explore that thought process for a minute. Lets go through the steps that it takes to make a change in a Waterfall project.

First off someone has to invoke a change request in order to make that change. This is likely coming from the development team as they ran into a road block and would not be able to complete the project by the way the requirements were written. This change request would almost never be coming from the end user because they won’t likely be able to provide any feedback until the application has moved into testing, which is always done near the end of the project. Next there has to be an impact analysis on how this change may affect the rest of the project. What I find interesting here is that we are still bound to theories. The requirements were developed on theories of how things should work in the minds of a Business Analysis and now we have an impact analysis which is also based on the same air, how we think it should work. One of the things about any agile project is that it is based on living breathing code. If something isn’t working the way we need it to we can make changes and continue to get feedback until everyone is happy.

Big Design Up Front

With waterfall, things need to happen in a very precise set of steps. After the requirements are gathered and everyone is in agreement on what should go into this application, it goes to the architects who will come up with the design. Many of the choices that are made during this step are made based on the specific known aspects of the requirements documentation. The problem here is that the organization may not know if these are all the requirements and there is a high level of possibilities that they aren’t.

There is a myth that the Scrum community states in their training material. The myth is that the longer you spend studying and analyzing the problem the more precise your solution will be.

The worst part of “Big Design Up Front” is that there might have been weeks and maybe even months of work to create this design. Which might be okay if the project was to come together in exactly that way. Chances are, there is going to be a change request that comes along that is going to break the design, sending the architects back to the drawing board. In any agile environment, we expect that the application and the design will probably change many times as we continue to inspect and adapt during development. The big difference here is that agile does not spend a lot of time up front on the design but continue to design and redesign as the project moves forward.

But We Need those Big Requirement Documents

Oh really? I have challenged many of my clients to prove me wrong on this. No one likes to read these because of the amount of boiler plate material that is in the document. Way back when I was leading teams on a new project I would often get these 60 to 70 page documents. I would go through them with my highlighter and find about a page and a half of things that we needed to do, the rest was filler. I am not alone in this thinking as I have seen lots of teams doing something similar to my highlighter exercise except they may put them into tools similar to Team Foundation Server. These teams would love to have the BA’s enter the requirements directly into TFS, but they struggle with having to have these big documents.

Again I ask you who are you writing these documents for? Many hours are spent to put these documents together to only end up in an archive somewhere. Developers don’t want them, they want the actual requirements or stories pulled out and track the things that they need to build. Testers tend to follow closer to what is going on in development than the big document simply because there is so much boiler plate stuff in these documents that makes it hard to work with. Now, you might be getting upset with me again because there is important stuff in that boiler plate text. True, but I don’t think it belongs in this document which is just a document. The problem with a document is that unless it has some way of being enforced it is just ink on a piece of paper. Everyone who has spent any time with your company knows what these requirements are that have to be in every product so wouldn’t it make more sense to have them in a Regression Test that gets run at least once before we release into Production. How about the really important ones being in a series of smoke tests which must get run before the Testers are even going to look at that build. This way those boiler plate requirements will be enforced.

Conclusion

Okay, I will admit I used the title of this blog post to attract development teams that are determined to work in a waterfall methodology and you probably thought this post would give you some much needed ammunition to fire back at the agile folks. Waterfall works great if everything is known about the project and you have done this same kind of thing many, many times. In those circumstances it is going to work great as you will know exactly how long it is going to take you and when the end user can have it in their hands. However, I have to say that very little of that kind of development is done in the United States or Canada. Those are the kinds of projects that can easily be done off shore for a lot less money because it then becomes just a labor exercise.

Real development involves going where no one has ever gone before and doing things you were not even sure could be possible. That is why you need to adhere to an agile approach and take a couple of steps forward, and expect to take a step back, adjust and move forward again. Development involves trying things and retrying things until you get the results that the end users are expecting.