I’m not talking about the 15 minutes you spend in stand-up meetings every day, and I’m not even talking about the few hours that you spend every iteration in planning and review meetings together.
The importance of planning distractions
If you’re practising Scrum, you may feel like any time not spent in these “standard” ceremonies should be devoted to uninterrupted development (design, coding, testing, etc.) In a sense, you’re absolutely right. Managers who interrupt the flow of teams for “chats” and “quick catch-ups” (or worse – the dreaded “all-hands meetings”) are breaking the rules, and harming productivity with these unplanned distractions.
But Scrum doesn’t prohibit planned interruptions from the normal flow of work. These may still cause some inefficiency, but the team does have a chance to pro-actively account for the event by adjusting their velocity and iteration outlook. In this respect, the best type of diversions from heads-down development are regular planned activities. If the team knows that there is an interruption window of, say, two hours each iteration in a predictable location, their velocity will automatically make allowances for that outage in straight development.
Dealing with backlog refinement
Why would you want a development team doing anything other than development? Actually there are lots of great reasons for breaking from the normal flow.
Most Scrum practitioners will be familiar with the idea of “Backlog Grooming”. This phrase always generates some tittering from the less mature members of our team (i.e. all of us) as it might not sound out of place at the top of some alarmist headline from The Daily Mail. I prefer almost any term to “grooming”, and have been known to use “backlog refinement” and “backlog workshop” instead.
The constant refinement of the backlog is one of the most critical (and often neglected) Scrum activities. This is the place where nebulous requirements can be discussed, de-constructed and estimated: ready to join the small and important subset of the larger product backlog I call the “Sprint-ready Backlog”. Some people think that the Product Owner should do all this work themselves and spoon-feed the results to the team, but this is misguided. The PO may not be technically qualified to do this, but more importantly bypassing the team and asking them for “solutions to order” means that they are not sufficiently invested in defining the problem. Good engineering is as much, if not more, about defining the problem as it is designing the solution. This is also why I prefer to involve the entire team to refine the backlog, because if it’s always a chosen few team members, an unhealthy dynamic evolves whereby a portion of the team becomes more invested in backlog ownership than the remainder. This has a severe effect on team morale in the long-term.
The problem with this refinement activity, as important as it is, is that it can be quite boring. It’s pretty intense to sit in a room for extended periods breaking down customer problems (some of which are interesting, some less so…). This drains energy after a while. Estimating in particular can be incredibly dull – even using the well-established planning poker technique which attempts to make it seem like a bit of a game. So there’s a conflict here – long backlog refinement sessions quickly become tiring but it’s inefficient to spread this effort too thinly or unpredictably over an iteration. Thankfully, backlog refinement often comes along occasionally and in big chunks (as roadmaps jerk forward in response to major releases, strategy changes and new sales opportunities) and so it’s not necessary to spend hours and hours each and every iteration breaking it down.
If it does consistently take this level of effort, I would humbly suggest you check whether there isn’t something dysfunctional at work here. Are you breaking down work that ends up never getting committed to? If so, shorten your planning horizon. Are you going into far too much detail? This is easy to do, but incredibly wasteful because it not only ties up the team unnecessarily, but too much up-front analysis has the effect of stifling creativity and later opportunities to be agile. It’s better to do analysis with a “little-and-often” approach – from backlog refinement, through iteration planning and just as importantly at a day-to-day level. This is called “Just In Time” analysis.
Extending to team-time
Having come to the conclusion that it’s better to book planned activity like backlog refinement in a predictable block and also that backlog refinement doesn’t always fill this block, the question then arises: how do we fill the remainder of this regular slot, so carefully earmarked? This is where the idea for a regular general-purpose team session came from. In our two-week iterations, we book out the second Monday afternoon (mid-Sprint) for team activities. This often includes a little (or occasionally a lot) of backlog refinement, but in general can be used for anything from hacking sessions to presentations to discussions about strategy or policies. Part of the idea is to just get the team into a room in a more casual setting than the standard Scrum meetings.
Everyone knows about Google’s 20% time. The idea of a regular team time is not too different, although the emphasis is on team development rather than personal development (and at an afternoon every fortnight, this constitutes more like 5% than 20%)
Introducing “Dev Bake Day”
Recently, I had the idea to start bringing doughnuts and other calorific snacks into this meeting as even when the activities are “fun” I’ve noticed people start to wane in the afternoon. The snacks help to make it seem less like a meeting and more like a social gathering (food is an excellent social catalyst) and it’s uncanny how easily a developer can be torn from his desk by even the whiff of free doughnuts.
Krispy Kremes are the popular choice, but they’re expensive and I’m starting to wonder whether they’re not a little tiny bit unhealthy. Next session I want to open up to home-baked goods. I myself like to bake muffins when I get the chance and I know some other team members to have brought in some wonderful stuff from home before.
These regular sessions have been going on for a long time now, under many names from “Grooming Session” (gag!) to “Backlog Refinement” to the more general “Team Workshop” and less descriptive “Monday Afternoons”. With the new emphasis on baked comestibles I’m thinking of re-christening them “Dev Bake Day”.
The idea is satisfying to me at two levels: not only does it describe what gets eaten, but also what gets achieved. Fundamentally, creating regular times and spaces during which the team can simply interact has the effect of consolidating and binding the disparate ingredients together with the end result being hopefully something sweet and satisfying that we can all enjoy!