Those of us working in agile environments hear words like ‘sprints’, ‘scrum’ and ‘coach’ at work but probably don’t give a lot of thought to their original meaning – and today I want to ruminate about sprints. A sprint, originally, is a race over a short distance. All that matters is getting over the finish line; it doesn’t matter whether you spend all your energy getting there.
As a working mode for companies delivering a piece of software with finite releases, this fits. Your team sets an achievable goal for the sprint, and focuses on this goal. The end result is clearly defined. Anything that didn’t fit into the sprint or came up during the sprint could be part of the goal for the next sprint, but in this sprint the team focuses exclusively on the current goal.
In the best case, the sprint goal is able to be stated in a short sentence, and it will be clear to everyone what is to be achieved in the sprint. “Dye the tallest alpacas blue” could be a sprint goal for a company whose overarching goal is to create multi-colored alpaca herds, and in the sprint you’d have tasks like “Prepare the dye”, “measure the alpacas”, and “buy large bathtubs”.
When producing software that is not neatly packaged for release, but instead is a living repository which may be deployed multiple times a day, it’s hard to have a sprint goal which is a clear iteration on your final goal. Important bugs (or, depending on the quality of your processes, small irrelevant bugs) crawl into the sprint. Business people start asking for features that they urgently need this week. Developers squeeze in critical security updates next to their daily work.
Our alpaca company’s sprint might still have the goal “dye the tallest alpacas blue” but in addition to tasks that directly relate to that, there are now more tasks, like “Fix the flaky paint on the red alpacas’ hooves”, “patch the fence around the undyed alpacas”, and “dye one alpaca each color for a marketing event next week.” The goal becomes only one part of the sprint, because these ad hoc tasks have crowded in.
It seems logical to me that there should be room for work towards both long-term goals and short-term reactive tasks in daily work, and also that the two need different structures.
At work, our tech teams are struggling with this problem at the moment. We have ambitious long-term goals for our tech platforms, but must also support a load of business requirements plus code and system maintenance. We’re trialing a system made up of core teams, task forces, and something our CTO is calling away teams, because he is also a big nerd.
Core teams focus on the long-term goals, like dyeing all the alpacas. They can structure their work in scrum, kanban, a mix: whatever works for them. Task forces chip away for a couple hours per week at an important but non-urgent task not directly related to the long-term goals, like replacing the alpaca shears with a newer model. Away teams are formed as needed and have a clearly defined short-term goal, like finding a better dye for the orange alpacas. While working on this task, they are not available for other work apart from short messages.
We can already see that there are still issues, such as catching the pink alpacas who broke through their fence, which don’t fit neatly into this structure. But the beauty of an agile mindset is that we are flexible and iterative; we can try out a couple of solutions and change things as we go.
Stay tuned!
(Also, live long and prosper.)