Waterfalling The Timebox In Agile — Anthony Software Group

“What does “waterfalling the timebox” mean in Agile context?
I have read at some places that “waterfalling the timebox” in an iteration should be avoided. a) What does it mean? b) How to avoid “waterfalling” in the iteration?

To avoid the lure of the waterfall, look for waterfall “smells” and address them during retrospectives. Some clues include delivery at the end of the iteration, stand-ups where everyone reports in to the Product Owner or Scrum Master, or phased delivery plans.

Tony Amos

People naturally revert to the familiar when learning new skills, even when the familiar works against our goal. Familiarity creates comfort which creates habit. Successful people lean into the discomfort and break through it, while many others continue to overlay prior unproductive habits, then wonder why they aren’t hitting their goals.

So, what is “waterfalling the timebox”? Generally, it means treating the iteration as if it were a mini-waterfall project.

Waterfall is a familiar practice, and with Agile, we are moving away from waterfall. Scrum defines a timebox as a fixed and maximum unit of time for an activity. The Sprint or Iteration is timeboxed, and so are Daily stand-ups, Sprint Planning, the Sprint Review, and the Retrospective. Waterfalling, however, usually only applies to the iteration.

So, to waterfall means to treat the work as a series of “gates” or phases to be passed in order to reach an end-state. For example, we may take a 3-week iteration and plan the first 4 days for design, then the next 8 days for development, the next 3 days for testing, then release. That is waterfalling. We take our familiarity with waterfall and apply it to the iteration, thus waterfalling the timebox.

One intent in Agile is to avoid targeting delivery at the end of the iteration. Instead, consider what feedback can be elicited quickly. And the only way to get feedback is to deliver something. But don’t guide the iteration so that all delivery is at the end. Create, get feedback, refine, and release when ready. Keep in mind that our goal in an iteration is to do the minimum work necessary to deliver value. The timebox facilitates that.

When waterfalling, we say we will deliver something at the end of each iteration. But Agile encourages an environment of continuous delivery and feedback. This is a different way of thinking. It does not necessarily provide a list of features and dates, but it does require trust and effective communication in order to work.

To avoid the lure of the waterfall, look for waterfall “smells” and address them during retrospectives. Some clues include delivery at the end of the iteration, stand-ups where everyone reports to the Product Owner or Scrum Master, or phased delivery plans. I’ll bet you can think of others.

Agile team members address each other at the stand-up and the PO or SM doesn’t interfere except to help clear blockers or resolve problems with requirements. Stakeholder reviews can happen at any time, and with modern DevOps tech, so can releases. If feasible, work towards continuous delivery if you’re not there yet.

The team does not have to turn on a dime. It’s ok to slowly make changes as each iteration passes. Too much change at once causes confusion, so gauge the team’s ability to absorb changes and incorporate them gradually, but consistently. You will see the difference in team morale and productivity as you move further and further from the waterfall.

Originally published at https://anthony-software-group.com on April 8, 2022.