What do salmon do once they make it up the waterfall … they DIE. And that is what often happens with Waterfall software development (also known as Software Development Life Cycle – SDLC).
Traditional Waterfall development requires lots of documentation, followed by development, user acceptance testing and final documentation (user manuals). Sound reasonable – right? But it turns out that going upstream in Waterfall is really hard because as each phase is closed out, there is little mechanism for changes. It assumes that perfect initial documentation (planning) will lead to perfect coding and so on.
In reality, the world changes as the documentation is being written. So a more flexible approach allows for changes in the world as the project evolves. That flexibility reduces waste, reduces change costs and provides faster feedback for quick course corrections.
That’s three bold statements, let’s see how it works.
The more initial documentation a software project needs before coding can start, the longer it generally takes. And that allows the world more time to change. Put another way, unless you can freeze time, the more time spent in the documentation phase, the more off target the software will be. That’s because, like jumping off a moving train, most software is released into a moving environment. The target moves, things change and elaborate plans crash when they meet reality. The US military has an expression, “No Battle Plan Survives Contact With the Enemy.”
Agile methods release functional software, in fast increments. Each release may be low in functionality, but it’s enough to test with end users. While the users test, the software developers and planners start work on version two – making changes shaped by end user feedback as it comes in. This still means that there will be changes, but at least the changes are small because the software development is fluid – meant to adapt.
New automobile designs are made with paper sketches first – where changes only involve an eraser. Sketches become clay models, then 3D rendered computer forms. At each stage the design becomes more refined, and also more expensive to change. In some cases, a factory recall of a vehicle, can cost more then it cost to manufacture the vehicle. Recalls are an attempt to fix an error at the latest stage of the buying process. The farther into a process, the higher the cost to fix an error. Which brings us back to Agile.
The primary goal is to deliver a solution that succeeds in the market. Anything you do that helps you better define the problems, and validate the solutions is “better.”
Because Agile software development is iterative, where the first phase is small but repeated often, more time is spent visiting the early stages. And the it is the early stages that allow for low costs changes to the process. It’s like how you drive a car – constantly making small changes to stay in your lane. Very little effort is required to drive.
And that’s also my argument for my last assertion – Agile projects are adaptable because, instead of spending a lot of time in one phase, the project visits each phase more often. The same amount of time may be spent in all the phases as in a Waterfall project, but by cycling through each phase, small corrections yield less painful ones. Also, because corrections are noticed and made faster, there is less waste.
The trick is we are not only measuring that the team creating the product (design, development and testing, to simplify) is being efficient. We are measuring the efficiency of the larger team (the agency, the company …) at solving the larger problem that eventually will create a success in the market. This definition of scope encompasses both development agility and business agility. It requires that the product team (product manager, product owner) also be agile. That they effectively identify the important problems, for the right customers, in the right markets. This requires both up-front deterministic insights to get the team started in the right direction) and emergent insights to course-correct as the team gets smarter about market needs.
The primary goal is not to save money (sorry if I raise eyebrows here), or to deliver faster (What ????). The primary goal is to deliver a solution that succeeds in the market. Anything you do that helps you better define the problems, and validate the solutions is “better.” Getting faster is nice, as long as you’re getting faster at building the right product. So I suggest leaving heroic, upstream swimming to the salmon, and take a fast ride downstream with Agile development.
Very soon I would like to blog about “What’s Make A Good User Story?”, please feel free to comment below or drop me a line if you think about another topic !