Scrum: Tempo Codified

I can’t think of a more clear example of rhythms in software than Scrum. Scrum is an attempt to codify tempo and wield it as a project management tool. Scrum sets the rhythm with recurring ceremonies: planning meetings, daily scrums, sprint reviews, and sprint retrospectives. You can take on a conductor role by studying these processes and become a certified Scrum Master. 

Scrum’s Rhythm

Scrum wants to maintain a minimum tempo. Sprints should be no longer than one month. This structure is where Scrum runs into conflict with Agile development. Where Agile development wants to be always open to change, Scrum instead creates a cascade of small waterfalls, typically in two-week increments. It is a compromise between the necessary iteration that software needs and the predictability that organizations crave. 

One issue I have always seen in Scrum is that work can not always fit into neatly defined boxes. Imagine you have a sprint of two weeks, and the next highest priority items in your backlog are for 8 and 4 days. Working on the eight-day project is a given, but then what? Do you choose to make some progress on the next more important thing, or attempt to Tetris in smaller, less critical work so that it fits the mold of time (or “points”) you have allotted? 

Scrum’s rhythm directly impacts software quality

If you team works like this, how would changing the length of the sprint affect both the velocity of your delivery, and the quality of your software? Would larger blocks of time mean you finished higher priority work more often? Or would shorter, more iterative sprints allow to leverage feedback more quickly, and be more willing to ship half-features? 

Either way, it is another example of how the tempo of the software development process affects the end product.