What are you doing? Stop it. Stop hitting yourself. Stop hitting yourself!
But seriously, why are you doing that? Waterfall development, defined loosely as frontloading all specifications and performing all development with little-to-no iteration or deviation from the aforementioned specs, is the Prohibition of development methodologies. It works great on paper, but in practice you end up blind from drinking bathtub gin.
All your hopes and dreams (likely including your job and retirement fund) end up dashed on the rocks of Iguazu and you’re just left there floating in the frothy bubbling water in your nice work chinos, and your iPhone is soaked, and your ironic ‘70s polyester tie is never going to be the same.
All this could have been avoided. You could be sitting pretty right now, collecting your profit share, dry, playing Minecraft in your office where no one can see you, but you had to go with the Waterfall firm.
Let me tell you what went wrong. It really boils down to just two things. Things that seem obvious in retrospect, I’m sure, but they wreak havoc in the moment.
1.) WHEN DEVELOPING SOFTWARE, YOU NEVER, EVER, EVER STOP GATHERING REQUIREMENTS!!!!
Because often you don’t know what your requirements should be until you start seeing them in action.
So you went into this massive rewrite of your company’s entire custom enterprise resource planning (ERP) system and thought you could just jot down everything you needed in Apple Notes once, pass it over to your developers, and POOF the problem is out of your hands. You were wrong. Because, about a month in, your boss knocked on your office door, you hid the Reddit tab on your screen, and he said, “Hey, I’ve been thinking about that ERP project. Wouldn’t it be cool if. . .” and at that point your collar felt tight and your hairline started to recede because you got a fixed price bid on the features you ALL DECIDED ON TOGETHER THREE MONTHS AGO, and the train is already moving. Oh, and ECRs are billed at triple time, and you can’t talk to your development firm because their workday ended when yours started. You’re in trouble.
The feature set on a project of any size is always in flux and that rate of flux increases exponentially according to the size of the project. Now, just imagine if you’d gone with that nice Agile firm out of Pasadena that said you could make changes any time you wanted and that they could just tack them onto the next milestone. Sure, it still increases the cost of the project, but the changes are billed at the same rate as the rest of the development, and they give your project the room it needs to develop organically according to your current needs as opposed to the needs you decided on last summer. When developing software, you’re always going to want to change something, add one more thing, or find out that what you thought was a good idea turned out to be totally unintuitive and inefficient for your users. Luckily that nice Agile firm had a great idea that could solve your user problem elegantly.
And what if your budget is suddenly cut, and you need to slash your features in half. Agile can do that. Agile can scale up and down according to your needs and means. But that Waterfall firm you signed a contract with doesn’t have a good way to scale back the project because the plan assumed you were sprinting to a fixed finish line. They want their money, and they don’t care that last quarter’s profits were down by 10%. It’s like starting a race thinking you’re in a quarter-mile straightaway and suddenly finding that you’re on an off-road course. That rocket-fueled roadster sure goes fast, but it doesn’t corner for beans.
2.) YOU WANTED AN XBOX, NOT A NINTENDO DS!!!
Yep, so, let’s just say for argument’s sake that yours was the exception to the rule. That your feature needs stayed steady from the day you defined them all the way through to the day of your production release. Sure, okay, fine, whatever. Everyone’s so excited! You’re all sitting at your desks, waiting for the system to go live. Your dev team, whom you haven’t talked to that much over the last six months as they “wanted to keep their heads down and in the work” pings you via Slack and says go for it, the site is live!
You refresh the URL and wait as the page loads, and wait a little longer, and a little longer, starting to feel the first signs of a stomach cramp, and it finally comes through and the colors start to build, and the text displays, and what the h#!! is this? It looks like your MySpace page from college! It’s an entirely black background with white text, and bad Flash animations displaying your company’s logo, and the slider keeps jerking through slides. Oh goodness. Oh no. You ping the Developer immediately, knowing your boss will be calling you in the next five minutes to end your career, and you’re all, what is this?! This is not what we asked for? Why did you build this monstrosity? What have you done?!
But he says, with a hint of indifferent exasperation, “This is state-of-the-art web development. We followed your spec to the letter. This is exactly what you told us to build.” Regardless of whether or not they used the latest web technology, the results would probably have been the same if they followed an ill-conceived spec to the letter without allowing for any variations.
You hang up and close your head in the big drawer of your desk over and over again as the phone rings and rings and rings. Here’s the thing: No matter how well you write down what you want, no matter how closely you layout the wireframes for your project, there are points where assumptions will be made, where the subjective nature of the process will lead to a divergence between the picture in your mind, and the picture in your developer’s mind. Thus, frequent, regular communication is essential to development. One man’s HTML5 is another man’s Flash. One woman’s elegant is another’s grotesque. You have to spend time with your developer reviewing your assumptions and theirs, and this is an ongoing process. You have to be given releases to review and critique to actually get the site you’ve staked your job on. Waterfall doesn’t allow for this, but Agile does, indeed it counts on it. It takes the divergence as a given and adjusts for it, mandating regular calls, and frequent releases: ITERATIVE DEVELOPMENT!
For a process named after water, Waterfall methodology is surprisingly rigid. The nature of water is to fill all the cracks, flow around the stones, to go wherever it chooses. That is the opposite of Waterfall development. It is a process based on fairy-tale thinking, where the good guy always wins, the couple always lives happily ever after, and the dwarfs continue to slave away in a mine (that was weird right, like why are these dwarfs stuck being coal miners? Where’s OSHA on that one?). It assumes there will never be a hiccup, that the first idea is always the best idea, that nuance doesn’t exist. Agile, on the other hand, conforms to reality. It adjusts well to problems, heck, even assumes as a given that they are going to pop up. It thrives on misunderstandings, subjectivity, and changes. It assumes there will be growth. It relies heavily on constant communication. Most importantly, Agile takes very seriously the fact that you often only have once chance to get it right. It follows the water as it flows, rather than damming the river and calling it a lake.
So look: If I’m going to leave you with one thought, it’s this: Would you leave a contractor with detailed blueprints to build you a custom home and just walk away for six months, waiting until he was finished to finally see the place, or would you drop by once a week or so to get an update on how things are going? Would you hire a nanny to watch your kids and leave that nanny with a list of rules on how you’d like them raised, and then disappear until they are 18? Of course not. You need to be involved in these things because situations have a way of changing needs, and your input is vital to the success of your project. You are the expert in what you need. The developer is just the expert in how to build it. Your responsibility doesn’t end with the signing of a contract or the payment of an invoice. It ends when the product is done, and THAT IS THE WAY YOU WANT IT!. Otherwise, you are going to end up with Space Jam when you asked for KFC.
