Do you ever wonder about some of the buzzwords within software development that describe differing methodologies for gathering requirements and running projects?

Sometimes, these methodologies can be confusing to people outside of the software development realm. This post is meant to take the basic concepts and explain using situations we all have dealt with in some way. I’ll speak to some of the differences through the lens of… a hungry person.

Ever want to change your order? Can we do that?

The first methodology we’ll consider is waterfall. Anymore it seems like waterfall is very frowned upon due to the lack of feedback and allowance for change within the process. The concept of the methodology is important nonetheless so that we can also explain competing methodologies. To explain waterfall, place yourself in a very nice restaurant. You’ve been seated by a hostess and a wait staff member comes to take your order. Your order is what is referred to as scope (what you want) in software development.

The wait staff writes the order on a pad of paper, documenting what you want. It is important to point out that after this point, changing the order might be difficult depending on how far along in the process the order is. Any change after this point will require you getting the attention of the staff and communicating to the kitchen what the change is. If your steak has already been cooked to well done and you want to change it to medium, the whole steak will need to be discarded and re-cooked, delaying your order to do so.

The kitchen appreciates knowing what you would like upfront so they can prepare the entire order and get the timing correct for all of the sides to be hot when the steak is done. What you don’t get to do is walk into the kitchen and offer feedback on the amount of salt being used on your green beans or the seasoning on the steak. Initially, you have defined what you want to come out and must trust that the end product will meet what you ordered. If you are not satisfied with your order when it arrives you must send it back and wait for it to be corrected.

So, you changed your mind?

In software development, if what was delivered is what you ordered, and the unhappiness is due to changing your mind there will likely be a cost implication. While a restaurant may be able to accommodate you wanting asparagus instead of green beans at the last minute, this is often not the case in software development.

Waterfall is a methodology that centers around the customer ordering up front, the requirements being documented and communicated to the developers, and delivery of what was ordered at the end. This is traditionally used when a customer seeks a fixed price so that the software company can understand the order in its entirety before giving a price to be agreed upon. This also means that changes to the order may mean additional cost because it was not in the original order. The end product will be prepared to meet the original order so if you want light salt and no pepper on your green beans it would need to be detailed in the information given to the kitchen right out of the gate.

Not sure what your order is yet? That’s ok.

Let’s talk Agile, and, I am purposefully capitalizing Agile in this case to differentiate the base concepts of the methodology over any individual implementation based on these concepts. This is very important because Agile is based on very basic principles which prioritize face-to-face interactions over written documentation. To explain Agile, imagine yourself in your local cold cut sandwich shop. You walk up to the counter and are asked what you would like. At this point you have given foundational details only- what type of sandwich and what bread selection. And, this plenty to get started.

Requirements as you go – some assembly (and lots of interaction) required.

Your order isn’t written down anywhere. The sandwich maker in front of you is slicing the meat and stacking it on the bread of choice in front of you. If you decide not to have ham, you can immediately tell them to skip it. If I want to change your bread it is a little more difficult once there is meat stacked on it, but it can happen without wasting toppings and condiments in the process. You’re heavily involved in the process and see what is being assembled right in front of you. Your feedback is welcomed- and needed!

Until now you haven’t been asked what toppings or condiments you want on your sandwich. They are gathering the information as it is needed to make sure the information they have is current. As toppings go on you the opportunity to offer feedback in the form of more mayo or less lettuce, etc.

When the price is calculated based on your choices as you went you had the opportunity to give feedback and make modifications as the sandwich was being made and were kept in the loop about cost drivers along the way- extra meat? Yeah, that was a cost driver but was a choice.
Agile centers on interactivity, giving the customer what they want, and allowing feedback during the process to make adjustments along the way at responsible moments. This means that what is delivered will meet the needs of the customer at the time the product was delivered, not at the time the order was placed. Agile tends to not lend itself to up front pricing because feedback could lead to additional work that wasn’t priced up front. You might be able to get estimates of cost but there will be caveats and allowances for unknown desires which might make that estimate seem higher than a waterfall quote might be.

Find what fits best.

Understanding these methodologies and how they differ is important for customers because most times the desire for a fixed quote drives more of a waterfall approach with resistance to change. This can cause a project to seem overly painful due to a desire to keep to the ordered product.
There are ways within both methodologies to mitigate cost increases related to uncovered system needs. The easiest of these is trading off lower priority items to fit in the new system need. Traditionally, this is a time for time trade off and is fairly easy to negotiate. If there are no low priority non-system critical items which can be traded out, additional cost may be incurred to fit in the additional functionality.

Remember, neither Agile or Waterfall guard against finding more work during the creation process, rather, they tend to dictate the way the discovery is responded to. Just some food for thought!