Scrum botherings

Zen master Corey is at it again, this all really resonates with me and mirrors my experiences.

There were a number of things that were bothering me about Scrum:

• I wanted to change the backlog more often than the timebox allowed
• At any given moment, only one item in the backlog needs to be prioritized. Further prioritization is waste.
• I wanted a specific mechanism to limit multitasking
• I hated estimating
• I hated negotiating Sprint goals
• Sprint planning implicitly encourages people to precommit to work assignments
• The ScrumMaster role is prone to abuse and/or waste
• Burndowns reek of Management by Objective
• Preposterous terminology

The thing that I wanted most was the smoothest possible flow of pending work into deployment, and Scrum just didn’t give me that. So, I proposed a simple spreadsheet-based method:

• A daily standup
• A single (roughly) prioritized backlog
• Each person on the team is responsible for exactly two work items by the end of any standup
• Every work item is associated with a workflow, and work item status is indicated by workflow state
• A work item requires some kind of peer review and approval in order to be marked complete
• New items can be added to the backlog at any time
• There is a regular project review
• The backlog must be regularly (but minimally) re-sorted
• Status reporting is by cumulative flow only