Don’t Go Chasin’ Waterfalls

Fellow LITA blogger Leo Stezano has been knocking it out of the park lately with his insightful posts about Agile Development. Agile is a word that gets thrown around a lot in the tech world, and while many people in the library world may have a kinda-sorta understanding of what it is, far less have a solid understanding of why it is. Agile seems to make a lot of sense on the surface, but one can only appreciate Agile when one knows where it came from and what it was rebelling against.

In the beginning, there was the dreaded Waterfall model:

As you can see from the diagram, you start with requirements and work on them until they are done. Then you move on to design and work on it until it is done, then implementation, etc. and the fun rolls downhill from there. The basic assumption of the Waterfall model is that we even can be truly “done” with any of these discrete phases of the development process. This old-school way of handling projects is sometimes derogatorily referred to as “Big Bang Development” (no relation to the TV show) because you get the requirements for the project (which you understand completely, right?) and then you go off into your cave to meditate for months and re-emerge with a shining, beautiful and perfect deliverable. That’s the dream, anyways.

What really happens if you try to run a project like this is that you would re-emerge with a product that does exactly what it was supposed to do (according to what you were told), but not what it actually needs to do. Let’s use an example: say your boss tells you, “I want you to make a pizza.” Awesome! What kind of pizza, boss? “Pepperoni, and make it big enough for everyone in the office to have some.” Alrighty, cool. You have your requirements, you go to the store to get the ingredients, and you build a big honkin’ pepperoni pizza. You deliver it to your boss, who promptly asks you “Is it organic? Gluten-free? Can it have feta cheese instead of mozzarella, and maybe capicola and olives instead of pepperoni? Also, I’m not extending your deadline or giving you more money to buy more groceries.” Bummer. You thought you knew what your boss wanted, and they probably did, too, but it turns out no one really knew what the successful project should look like at the beginning. The client (your boss) only knew what they wanted in response to what you give them.

This fact of life that clients don’t really know exactly what they want at the beginning of a project (or aren’t capable of accurately conveying that information to you, which is just as destructive) is a truth that the Waterfall model can’t accommodate. Fortunately, its a truth that is foundational to Agile Development. Agile assumes that clients only have a vague idea of what they want, and the entire development process is based around iterations where you build a little bit of something, show it to the client to get feedback, and then build a little more based on that feedback. It may not be as clean or discrete as the Waterfall model, but it works incredibly well by recognizing the psychological phenomenon that people are better at describing what changes they want to an existing thing than they are at describing what they want from scratch. In fact, this is why the process is called Agile; it’s a workflow that can stop on dime and change direction based on the client’s changing needs. The Waterfall model of development is like a freight train barreling down the tracks defined by the requirements at the start of the project; once it leaves the station, there’s no stopping it.

Let’s try the pizza project again, but from an Agile perspective. Your boss wants a pepperoni pizza. You go back to your office and draft up an ingredients list with links to the ingredients you’ll use on Amazon. You email it to your boss who looks at the list and emails you back to say that it looks good, but let’s make a few changes. They email you back a word document with the new ingredients they want. You go to the store and get them, you make a small test pizza and let your boss sample it. “I like it extra crispy. Cook it longer.” You make another test pizza cooked longer. “Perfect!” You make a giant pizza, everyone in the office loves it and they throw a parade in your honor. Iteration has saved the day!

While this is a heavily simplified view of both the Waterfall and Agile models of development, I feel that this iterative perspective on projects is one of the most important takeaways of learning to be Agile, and it’s a principle that applies to all projects, not just software development. So long as you remember that humans aren’t perfect and aren’t always great at explaining what they need, you can use this fundamental Agile principle for every kind of project (even making a pizza for your coworkers). When you take on a new task, start small and iterate small. It’s the fastest way to correctly get to the big picture.