Sometimes when we try Agile, our initial process might look a little bit like something I call an “Iter-Fall” Sandwich – a mixture between Iterative Software Development and Waterfall.
In an extreme case, we might have the following “iterations”…
1. Requirements “Sprint” / “Iteration”
2. Analysis “Sprint” / “Iteration”
3. Architecture “Sprint” / “Iteration”
4. Design “Sprint” / “Iteration”
5. Multiple pairs of …
5.1 Code “Sprint” / “Iteration”
5.2 Test “Sprint” / “Iteration”
6. Integration “Sprint” / “Iteration”
7. End to End Testing “Sprint” / “Iteration”
8. Hardening “Sprint” / “Iteration”
9. UAT “Sprint” / “Iteration”
10. Deployment “Sprint” / “Iteration”
You might have come across a similar process in your organization or that of a friend / client. It might be an interesting avenue of exploration to quantify the size of this sandwich in terms of calendar months, effort, dollars of investment or risk exposure…
The key question is what happens if we inject a defect or an invalid assumption in the early stages of the iter-fall sandwich and only detect it towards the end…
How might this impact our business and stake-holders? How much might it cost us to recover from the damage…?
So now we come to the key question – is the Iter-fall Sandwich Agile? Will it help us get Agile Outcomes…?
Let’s go back to the basics and look at this approach through the prism of the Agile Principles…
#1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
#3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
#7. Working software is the primary measure of progress.
Similarly, is the Iter-fall Sandwich Scrum? Let’s look at it through the prism of the Scrum Guide –
- The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.
- Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.
-
Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
- Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
- Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together
What this approach highlights is the contrast between waterfall thinking and agile / scrum thinking. Waterfall thinking is like building a huge stadium. Scrum thinking is like building modular homes, module by module and expanding just in time based on home-owner feedback as their family needs expand….
Sometimes, when we try to migrate from waterfall to agile, we feel that all we need to do is demolish all the documentation needs and check-points / controls that are part of waterfall. We feel that this demolition will help us deliver more software faster.
However, we choose not to install the culture, values, roles, events and artifacts which are the pillars of Agile and Scrum. So what we are left with is a strange hybrid – the Iter-Fall Sandwich…
The outcome is neither a stadium nor a modular home. It is a ruin which suffers from the worst risks of both approaches…
So if your organization is on an Iter-Fall Diet, what should you do? Well, if you are satisfied with the outcomes, you don’t need to change anything.
However, if you are not satisfied with the outcome, it might be worthwhile to reflect in your retrospectives – is there a problem with the Agile / Scrum framework or might there be a problem in the way your organization is implementing it?
One possible diagnostic is an approach I have created, called “The Trojan Retrospective” In this approach, we reflect on our existing processes through the prism of Agile, Scrum and Lean Fundamentals –
1. Agile Manifesto
2. Agile Principles
3. The Scrum Outcomes
4. Scrum Values
5. Scrum Guide
6. Lean Software Development
If you use the approach and the free excel template on my blog, your team’s results might look something like the chart below.
This might create transparency that could help you inspect and adapt your processes to reduce the deviation between your desired results and actual results.
If you would like to learn more, go back to the basics. As a team, read and discuss the Agile Manifesto, Agile Principles and the Scrum Guide…
So, the purpose of my post is not to trigger yet another religious debate between frameworks and methodologies. Whatever be the methodology / framework you might be using, if it works for you, don’t change it. If it ain’t broke don’t fix it.
But whatever “it” is, call it by the appropriate name. We are in a multi-billion dollar industry. Many of us are Engineers and there is a scientific foundation to our profession. We owe it to ourselves, our customers and our stakeholders to be rigorous and consistent in our terminology.
If you are using waterfall, call it waterfall. If you are using Agile / Scrum, call it Agile / Scrum. Please don’t use Iter-Fall and call it Agile / Scrum. It causes all kinds of grief. And adjust your expectations of the outcomes to match the inputs.
Either way, I would love to hear your thoughts. Let’s talk!
Keep calm and Scrum On!
Ravi Verma
The Org Whisperer
Comments