Waterfall in sprints isn't Agile

I've worked in unstructured, Waterfall, and Agile software processes since 2009. One I found ineffective is 'Waterfall in sprints', confused as Agile. When I saw a meme about it, I realised it's a common Agile anti-pattern. Here, I'll unpack what I mean by 'Waterfall in sprints' and what's needed to make it Agile.

Cycles

Software development has a cycle of requirements gathering, analysis, design, coding, testing, and operations/maintenance.

Waterfall executes this in a macrocycle where all analysis is done before design, all design before coding, and so on. Alternatively, this macrocycle's steps can be repeated across the length of a project in microcycles, known as iterations or sprints.

You need more than sprints to make you Agile. The teams of some questionable processes I worked in believed we were doing Agile because we worked in sprints. In retrospect, we were doing 'Waterfall in sprints' because of how we used them.

Sprints

The purpose of a sprint is to produce feedback.

The following is true when we plan: We don't know what we don't know. As a result, we base our plan on many assumptions or hypotheses.

In Agile, we figure out what we (including our customer) don't know with the feedback from sprints. We use it to test our assumptions early and continuously.

The feedback includes:

• Customer feedback
  • From seeing working software.
• Data
  • Velocity (the average amount of stories or story points completed per sprint).
• Misc. learnings
  • If the design is right.
  • How time-consuming it is to code.
  • Missed requirements.
  • Etc.

Waterfall in sprints

I define 'Waterfall in sprints' as a process with Waterfall thinking and sprints.

Waterfall thinking, in my definition, is the disregard of feedback, the tendency to delay the release of value, and the belief the initial plan can work.

Disregard of feedback

Waterfall lacks continuous feedback. If a team ignores the feedback from sprints, it's as if that feedback doesn't exist. Such a process is virtually 'Waterfall in sprints'.

Delayed Releases

In Waterfall, there's a big bang release. If an 'Agile' team produces features in sprints but delays their release until the project's end, their release pattern is identical to Waterfall.

Initial-plan confidence

Waterfall invests a lot of time in up-front analysis and design to produce a 'perfect' plan for development. With such an investment, a team may believe the plan will work.

They may think tuning their plan is unnecessary when they see themselves deviating from it during development. To adjust it would be to admit it's flawed.

This Waterfall thinking may motivate a team to catch up to their plan by drastic means, such as:

• Quality shortcuts

• Excessive overtime

The Agile Way

How can one convert 'Waterfall in sprints' into Agile? By fixing Waterfall thinking.

Ron Jeffries (an author of the Agile Manifesto) defined Agile as being consistent with the Agile Manifesto:

Let's use "Agile" to mean "consistent with the Manifesto".

. . . People are devising new values, principles, ideas and tools all the time. These may well be consistent with the Manifesto. When they are, we call them "Agile".

Let's work with this definition. The following is an alternative to Waterfall thinking, consistent with the Agile Manifesto.

Feedback

Pay attention to the feedback from your sprints. Learn from it and respond.

Responding to change

The Agile Manifesto says responding to change is more valuable than following a plan. If feedback informs an Agile team their plan won't work, they respond quickly to this change in project knowledge.

How? By tuning the plan. By turning the knobs of the iron triangle:

• Scope (Requirements)

• Skills (Resources)

• Schedule (Time)

Sprints give managers the feedback they need to turn these knobs early and continuously. They tune it by changing the scope, getting more resources (early enough to mitigate Brook's Law), or asking for a deadline extension.

Releases

Don't do big-bang releases at the end. Release value (usable software) to your customer early and continuously.

Principle #1 of the Agile Manifesto says:

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

Principle #3 says:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Initial-plan confidence

The initial plan is not perfect. Expect it to be flawed. Please resist the temptation to force it with excessive overtime or a compromise on quality.

Excessive overtime leads to burnout, which reduces the pace of the team. Sustainable Pace is an Extreme Programming practice to prevent this.

Principle #8 of the Agile Manifesto says:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Quality compromises can ruin a team's ability to sustain a good pace. The resulting technical debt will require interest payments in time. We should never compromise on quality.

Uncle Bob (another author of the Agile Manifesto) says:

. . . Low quality means low speed. Always.

The only way to go fast is to go well.

Not only is this consistent with Principle #8 of the Agile Manifesto, but also with #9:

Continuous attention to technical excellence and good design enhances agility.

Conclusion

We considered 'Waterfall in sprints' as the application of Waterfall thinking to sprints. Here's what's needed for such a process to go Agile: An early and continuous response to sprint feedback consistent with the Agile Manifesto. To more agility and less 'falling'!