Scrum is boring.

Well, more specifically, planning meetings are boring.  A colleague pointed this out to me and it was indeed a big shock to me.  I think I must have been too busy sleeping through the planning meetings to notice it for myself.  It’s a technique I perfected working my previous menial-labour-for-hire job; being able to appear like a functioning person whilst actually being sound asleep. The empty coffee cup in front of me is just for show.

But why is planning so boring?  The same colleague postulated that surely it should be exciting, taking a fresh look at all the wonderful new work we, as a team, are about to embark upon.  Surely this is where our Scrum happiness sourced – this is a meeting all about anticipation. Google is very happy to produce results which suggest that happiness is derived from the anticipation, not the event proper. And yet the fact remains – every single person I talk to about having their planning meeting has the same, resigned tone in their voice. Oh no, it’s planning day again.

So now I suppose I should be asking the really probing questions – what, specifically, makes the planning meeting a less pleasant alternative to a tooth extraction? What makes it worse than other meetings? (which, granted, aren’t exciting, just merely irritating) The following presumptions are based on my own experiences, and your mileage may vary.

The meetings are large. I don’t mean that they go for a long time (though that is a common side-effect), I mean that they often have too many people there. There are too many people for everyone to be engaged all the time, meaning that at any given moment, I would estimate that about two thirds of the folk are bored. This is a direct result of having a bunch of people in the meeting – it is a logistical reality that not everyone is working in a similar area at the same time and this only increases when the team size increases.  So when I talk about meeting size, I really mean the number of people whose mind has wandered off the subject at hand.

Planning meetings require precision.  Albert Einstein once said “never memorize what you can look up in books”.  Our brains are wired to filter out data we don’t recognise as important, otherwise we’d never have made it out of the oceans, let alone come down from the trees.  So our daydreaming is an instinctual mechanism, by which our brains are telling us “I don’t need to know this to the nth degree – I’ll learn about it if I pick it up”.  Which is where Scrum and planning meetings stop working.  Having a group planning session is intended to bring the whole team up to speed with the work that’s ready now, such that we can collectively come up with a reasonable size estimate and unlock some of the mystery (given the collective knowledge and experience in the room) in the stories.  It’s extremely difficult, tiring, and an overload trying to keep up that level of concentration for more than about 45 minutes.  On a good day.  And even with breaks, this number only declines as the meeting length and “size” increase.

This precision is important because it forces us to understand, in detail, what a given story is about.  Having that story then pass through one or two more people means that you probably can explain it to a six year old (that’s another Einstein reference, but works equally well, given that I’m only four).  We still get surprises, because in software, the only way to truly know what the story involves, is to actually do it.  This knowledge has a second use.  It’s not just about understanding the story so we don’t get nasty surprises when doing the work, but so we can inform the business of what work will be done when.  If we know what work is left (and that’s a substantial if) the the project can co-ordinate around our delivery schedule.

The Kanban way of thinking is quite different from Scrum, in that it doesn’t even have a planning meeting.  Surely such a fundamental difference would cause it to fail – surely the team wouldn’t have a clear picture of what’s going on?!  I’ve worked under both systems, but I’m not confident we ever really got the hang of Kanban properly.  It’s whole ethos was to reduce work in progress, but we tended not to be strict about flimsy ideals such as Work In Progress limits.  Sigh.

Those who work with me might have noticed that I have a personal Kanban board taped to the computer next to my monitor.  This certainly doesn’t require planning – I know the jobs I mean.  It’s as much a memory system as it is about productivity.  Although, I don’t have a product owner coming along and ordering the post-it notes in terms of the business value, it’s far more likely one of my colleagues being funny or gently encouraging me to look at their problem next.  Sure, I’m embracing the chaos, which definitely lightens my cognitive load – but there’s just one problem.  I have a permanent “In Progress” job, called “Team Scrum Work”.  It’s a mix of the two cultures, which doesn’t quite fit nicely together, but the alternative of double handling all my scrum work, such that it also appears correctly on my Kanban board is little short of a total nightmare.  The ‘pull’ ideals become somewhat diluted at that point.

So now I’ve established that I don’t like Scrum’s planning, but it’s a necessary evil because in order to be precise, we must tease out the gritty details of the story so we can tell the business when we’ll be finished.  And that I don’t like Kanban because it lacks planning.  Wait, what?  That wasn’t a conclusion I expected to draw.  So I think that means I prefer trying to fight the chaos, by using the Scrum system for anything that’s remotely complex.  Sure, it’s possible to do such analysis in the kanban way of life, but frankly, if it weren’t for the social pressure, I probably wouldn’t do it.

Planning is boring, and, armed with this knowledge and its stark admission, can we arm ourselves with strategies to work around this?  Yes.  Probably.  Mild stimulants and baked goods are part of a strategy that our team has been employing recently.  We’ve also been (somewhat unconsciously) embracing the fact that we’re not all going to know everything about the story, and actually, we’re reasonably happy to more or less stick with what the submitter suggested – with the proviso that we need the threat of everyone scrutinising the story in a stressful public forum, in order to be so nonchalant.  Planning is part of the social pressure, so it requires that the technical folk ask difficult questions, and people who are willing to ask the obvious dumb ones, ideally when they’ve been forgotten as well as a general audience.

And as a third attempt to conclude my thoughts, I’m going to say this: Planning is boring, but necessary for a working scrum team dynamic.  Let’s keep it inside of a single bout of concentration and above all, let’s make it anticipatory, the source of all happiness!