This post is about Scrum’s scrumptious forcing function….the “potentially releasable product increment”. From 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.To meet this requirement (rule?), teams attempt the following strategies:

1. Reduce sprint length to limit work in progress (less time, less work)
2. Reduce the amount of attempted work until they can confidently meet the requirement (less work) and then slowly “ramp up”
3. Assure that stories are independent, and attempt less “holistic” sprint goals…meaning that they always achieve the goal even if some work is still in progress (fewer dependencies, likely less work)
4. Extend the length of the sprint (in theory keep work equal)
5. Treat the rule as more aspirational…attempting an ambitious but theoretically achievable goal, succeeding sometimes, failing other times (equal or more work)
6. No real change in approach and generally ignore the forcing function (but stay very busy) My guess is that #5 and #6 predominate. “Hey we’re Agile!”

#1-#3 challenge “business as usual” which typically involves big batches, keeping people busy, individual assignments, infrequent integration, fetishizing stretch goals, output/velocity fixation, high work in progress, teams with low autonomy, and low psychological safety. They can easily be construed as putting even more pressure on developers and/or asking them to cut corners. Abuse of the team is possible. In short…#1-#3 have high potential for continuous improvement, but are hard.

#1-#3 will involve moments where the team appears — from the outside and inside — to be “doing nothing”. Developers will be asked to swarm and pair…to really work together. There will be uncomfortable moments when folks ask “what should I actually do now?” The team may have to accept a seemingly mundane or trivial goal for the increment. But long term…things will improve.

Teams can do #4-#6 for a long time without ruffling any feathers.

I often advocate against Scrum because #1-#3 may not be feasible in the current environment. It isn’t safe enough to make #1-#3 possible. Instead, I suggest staying true to the Increment. If it takes 14 days…fine. 8.5 days…fine. We can operate without being distracted by constraints we have no intent to work with.

But, if you’re willing to make it safe for #1-#3…then maybe give it a try.

Basically…if you’re going to do Scrum. Do Scrum.