It's Christmas time here in 2023 and as such I typically spend this week making loads of sweets and treats for family and friends. It's not a labor; I love doing it. Since many of the items I only make one time a year, it takes me a few iterations to get back in the groove. This blog was inspired by one such story.
I love gingerbread (cookies too, but this is the actual gingerbread). There are many variations of this recipe, I have five myself that I alternate through. This year though, I tried a new one that had black pepper in the mix. Black pepper? Intriguing, so I thought I would try it.
I followed the recipe step by step, but this one had an odd wet ingredient process outlined by pouring boiling water over the sugar, molasses, and butter. Then let it sit for 25 minutes before adding 2 eggs. Let's face it, ingredients are simple to follow, techniques are what make these recipes, so here we go.
I followed the recipe to a T and checked on the gingerbread after 25 min of baking. It was still very much batter in the center, so I cooked it 10 min more. It was still sticky and soggy, so I must have done something wrong. As I looked to the recipe on the counter, I noticed the 2 eggs still sitting there. The 25 min I had to wait for the wet mixture to turn luke-warm made me forget about the eggs.
I was thinking to myself how this is very similar to a traditional / waterfall method of delivering a product. Predictable, repeatable, perfectly defined, but prone to human error still. At this point, I really only have two options when fixing this problem. Serve the cake at poorer quality and just call it a sticky toffee gingerbread (hey maybe I made my own new concoction) or throw it away and start over.
I couldn't integrate the eggs well into the already planned, mixed, and baked product. I couldn't simply crack the eggs over the cake and serve it (well I could, but that would be terrible). Ever face a similar issue on a waterfall project (making a widget, making a car, etc...)?
In the world of project management, Agile and Waterfall methods represent two distinct approaches to planning and guiding project processes. To better understand these methods, let’s use this metaphor of making gingerbread (defined process control) and curing cancer (empirical process control).
Defined Process Control: Making Gingerbread
The Waterfall methodology is akin to following a recipe for gingerbread. In this approach, every step is clearly defined and must be followed in a particular order. Just like a baking recipe, Waterfall requires you to gather all your ingredients (requirements) before you start, and once you’ve started, there’s no going back. If you forget an egg, you can’t just add it to the gingerbread after it’s baked; the entire process depends on following the steps correctly the first time. This type of process is really perfect for the products that are hard to change, but you must keep that in mind when developing the processes for people to follow.
Key Characteristics of Waterfall (Gingerbread Making):
- Sequential Phases: Like baking steps, Waterfall moves through stages such as requirements, design, implementation, verification, and maintenance.
- Detailed Planning: Before any action, a thorough plan (recipe) is laid out, much like measuring all your ingredients beforehand.
- Predictability: If you follow the recipe, you expect a specific outcome, similar to how Waterfall projects have predictable outcomes based on their detailed plans.
Empirical Process Control: Curing Cancer
On the other hand, Agile methods are more like the ongoing process of curing cancer. This process is complex and unpredictable, with treatments often needing to be adjusted based on patient response and new findings. There’s no fixed recipe here; instead, doctors use empirical process control, adapting their approach based on observed results. Basically we really don't know what we are doing, we are experimenting with assumptions and then validation of those assumptions (or not).
Key Characteristics of Agile (Cancer Treatment):
- Iterative Development: Similar to how treatment plans may change, Agile breaks projects into small, manageable iterations or sprints.
- Adaptability: Just as doctors adjust treatments based on patient response, Agile teams adapt to changing project requirements and feedback.
- Continuous Testing and Feedback: Ongoing testing in Agile mirrors the constant monitoring and adjustment in cancer treatment, ensuring the project is moving in the right direction.
While making gingerbread with its defined process control offers predictability and a clear plan, it lacks flexibility. Conversely, the empirical process control in cancer treatment allows for adaptability and responsiveness to change, albeit with less predictability and fear of failure (but at least its earlier).
Understanding these differences is crucial for project managers and teams in choosing the right approach for their projects. Whether it’s the structured, predictable path of Waterfall or the adaptable, iterative journey of Agile, both methods have their unique strengths and suitable applications.
What About Risk
When we compare the methods of Agile and Waterfall using the metaphors of making gingerbread (defined process control) and curing cancer (empirical process control), it's important to address the concept of risk, particularly in larger projects. The failure of a gingerbread recipe may seem trivial compared to the complexities and stakes of large-scale projects, but the underlying principles of process control and risk management remain relevant.
Understanding Risk in Defined Process Control: Beyond Gingerbread
In the Waterfall model, risks are identified and addressed primarily in the initial planning stages. Much like following a gingerbread recipe, the assumption is that a thorough upfront plan can foresee and mitigate most risks. However, in larger projects, this can be problematic:
- Unforeseen Changes: Just as you can’t add a forgotten egg to baked gingerbread, large projects often struggle to incorporate late changes or new requirements in Waterfall, leading to costly reworks or compromised quality.
- Limited Feedback Loops: There's little room for mid-course corrections. In complex projects, unlike baking, this can lead to significant issues if the initial requirements or plans were not perfectly aligned with the end goals.
- Predictability vs. Reality: While the predictability of Waterfall is comforting, it doesn’t always account for the unpredictable nature of real-world scenarios, much like unexpected issues that can occur even in a well-followed recipe. Many stakeholders view the Waterfall planning activities like a warm blanket. They want them and need them, but often don't realize its really just an illusion of warmth.
Empirical Process Control: Navigating Uncertainty in Complex Projects
Agile methods, with its empirical process control, offers a more dynamic approach to risk management, suitable for complex, unpredictable projects like cancer treatment:
- Iterative Learning: Agile allows for learning and adapting as the project progresses, similar to how doctors modify cancer treatments based on ongoing results.
- Flexibility and Responsiveness: Just as medical treatments must be flexible to patient responses, Agile methods are designed to accommodate changes, making them ideal for projects where requirements are likely to evolve.
- Continuous Risk Assessment: In Agile, risk is not a one-time assessment but a continuous process, allowing for quicker responses to new challenges or changes in the project environment.
It's About the Type of Work
It's crucial to acknowledge that the stakes and complexities in real-world projects are significantly higher than making gingerbread (flour, egg, water, and sugar is cheap). Agile, with its empirical approach, offers a more adaptable framework, especially suited to large, complex projects where uncertainty is a key factor.
By understanding these differences, organizations can better assess and choose the method that aligns with the nature and needs of their projects. I am not a dogmatic Waterfall vs. Agile person, but I do see that much of our work this day and age are highly complex and require various skills and knowledge. In addition, the consumer forces us into a hyper-competitive environment. If you are building a house, bridge, or some other complex product that is very difficult to make changes to, stick with Waterfall until that technology changes to allow for cheaper change.
If you are building software, knowledge work, marketing campaigns, data centers, etc... Agile can prove a viable method to help spread risk and planning across the entire project. In the end it's about the type of work and then deciding the correct approach based on that work. Waterfall is a great process, it's been used for many years and still valid for many settings. The problem is, it was all that existed until the late 1980's / early 1990's. Helping people unlearn static behaviors; that's the journey.
Hungry yet? LOL