Beads on a string

In traditional western musical composition, each score typically has a time signature that defines the overall tempo of the music. One number defines the length of the beat, the other the number of beats per measure. So, you might have three quarter notes ( 3
4 ), two half notes ( 2
2 ), seven eighth notes ( 7
8 ), etc. The idea is that the music is divided up into strictly defined chunks, and that these define how the composer should compose, and the musician interpret, the music. (Yes, of course, it’s tremendously more complicated than that, but let’s not get caught up in the rich, fascinating details, shall we?)

But why should this be a defining characteristic of a musical piece? Why do we even need measures? Or if we do, why not just make each measure as long as you’d like? You could, of course, and there’s nothing stopping you from changing time signatures in the middle of a score (Rush, in particular, seems to have taken this on as a personal mission) – in the end, there aren’t any unbreakable “rules” in music composition, just patterns that people seem to respond to, and that seem to have worked well in the past.

Enter Philip Glass. In his breakthrough (and, frankly, unlistenable) opus Einstein on the Beach, he completely eschewed the idea of a time signature. He would, he said, connect the music like beads on a string, giving each measure as many notes as he thought made sense. Some measures were longer, others shorter, but there were no pre-set limitations on the way he organized his musical phrases.

I thought of this recently, as my team went through a transition from a more reactive, support-oriented role, to a scrum-light project-oriented focus. Each week we’d handled emergent issues, waded through the ticket queue, and chosen projects based on what we judged would be most useful to the business – sanding down a corner here, upgrading a part of the infrastructure there, shaving time off a process to relieve some developer pain.

Now, however, we’ve switched to big quarterly goals, each divided into milestones, themselves divided into week-long sprints. This isn’t waterfall – we’ll be constantly evaluating as we go and defining projects based on what we learn – but it’s going to be a much more structured, planful, traditional approach. The short sprints are a way to keep ourselves focused, and to prevent ourselves from letting tasks unrelated to core goals creep in. To that end, one engineer per week owns the ticket queue, while the others focus on project work.

The old method of attacking the most important thing next was a useful reactive strategy – we were able to prioritize emergent needs, put out fires and effectively handle short-term goals. But it also created some bad habits – it’s too easy to get distracted by urgent but less important work, or to be sidetracked by requests from our customers. It was a tactical strategy that worked well for a time, but was less effective once the big fires were put out. The new method (or rather, the traditional project management approach) is better suited to big, long-term projects, and ambitious goals. It allows you to set expectations up front, get buy in from stakeholders, and measure progress against intermediate milestones. The “beads on a string” method isn’t wrong per se, and can work well when you’re toying with different ideas, fighting fires, or are tasked with prioritizing customer requests – but big goals need a strategy, milestones, and the constant rhythm of regular small successes building to a final crescendo.