Making Scrum Meetings Effective
I’m not really the biggest fan of Scrum meetings.
It doesn’t have anything to do with my like or dislike for Scrum itself. Plenty of teams that aren’t following Scrum have Scrum meetings. Plenty of teams that don’t even really follow any kind of Agile process have Scrum meetings.
The reason why I am not a big fan is because most of the time they are very ineffective.
The idea behind a Scrum meeting is simple
The idea is that you have a daily stand up meeting where you basically determine how the work is progressing and if divine intervention is required to keep things progressing.
The idea is to provide a transparency where anyone can see what exactly the team is up to.
The basic format of a scrum meeting is pretty simple. Each person on the team says three things:
- What did I do since our last meeting
- What am I doing until our next meeting
- What is impeding me
On the surface these seem like sensible and valuable things for each team member to talk about, but…
So often these three things end up being BSed
No offense to anyone I’ve ever worked with. Heck, I know I have BSed them myself. It’s just too easy to do it.
When I say BSed here, I don’t necessarily mean blatantly lying about what you did and are going to do. (Although that happens plenty as well.)
What I am talking about is saying what you did or what you intend to do without really having a purpose of why you are saying it.
How many times has this happened to you? You walk into your Scrum meeting and panic hits!
Oh crapola! It’s coming around to me! What am I going to say?
I didn’t really get much done yesterday. I was fooling with the build, then I kept getting interrupted. Then I was answering a bunch of emails and I ended up helping Joe with that task he was working on. Then we started talking about how we’d like to start using this framework.
I don’t even know what I am really planning on doing today. I’m just going to keep working on the backlog I am working on. I don’t want to say that though, I need to say something more important.
So what do you do? You kinda make up something important sounding, and you mix in some of what you did do and try and make it relate to things happening in the sprint. You prattle on about stuff that no one really cares about, because you need to say something. You’ll look like an idiot if you don’t.
This kind of thinking is contagious
Pretty soon you end up with the whole team just prattling on about things that aren’t really important to anyone else or just saying something like:
I continued to work on backlog X, I’ll continue to work on backlog X today.
Waste of time, waste of breath. A scrum report is only valuable if it is providing usable information about the progress of an iteration and helping to bring impediments that can be resolved, to light.
I really don’t mean to sound harsh here but I want to be truthful. We don’t benefit anything if we can’t examine what we are doing with a impartial lens and tear it apart if needed.
I am a firm believer that pointing out problems without offering solutions is just whining. It has no value. I wish I could say I myself was never guilty of it, but the truth is, I do my fair share of it.
With that said, I am offering a solution to this problem…
By happenstance, I just finished reading Clean Coder by Bob Martin. (I’ll post a review on that book when I get a chance, but excellent read. It hurts to read it, because it will call you to a higher level of accountability, but read it.)
Anyway, that book has a great chapter on commitment, which coincides nicely with a technique I came up with awhile ago to help make Scrum meetings much more valuable and harder to BS.
The basic idea is pretty simple. I replace the 3 topics in a Scrum report with my sub-classed version:
- What did I commit to doing yesterday and did I or did I not meet that commitment. If not, why not.
- What will I commit to getting done today.
- What is impeding me that can be improved by bringing it up in this meeting.
Commitment can be scary
But, it is something that carries with it accountability. See the problem with your normal Scrum meeting is that it is far too easy to BS. There is no accountability, so you can basically make up whatever you want.
I’m sorry if this offends some people, but I am not placing myself above BSing a Scrum report. I would venture to guess that a majority of Scrum reports given on this planet are heavily weighted to the BS side of the scale. Once again, not necessarily saying people are lying. I am just saying that your Scrum reports contain the value of feces from a male bovine. Just saying…
What I try to do with my solution is add some accountability by focusing on commitment.
The idea is that it makes you think about what you are actually reasonably going to get done in the day. It forces you to think about priorities and schedule. It requires you to break down your work and think ahead a bit so that you can come up with something that you can commit to.
It also tends to make sure that what gets worked on is what should be getting worked on. You don’t get to say what you worked on yesterday, you only get to talk about what you committed to that you either did or did not get done. This prevents team members from talking about all the other non iteration related stuff they did.
It really makes you think before you jump off down some rabbit trail if you really want to say in Scrum the next morning that you didn’t do anything you committed to.
It really makes you think first before implying you are going to get something done. Instead of saying “I’m going to try and finish up backlog X today,” you are more likely to break down some component of backlog X and say “I will commit to getting done task A in backlog X.”
The difference here is critical, because in it lies the value. The value is that someone listening to your report can actually get an idea of the true progress of the team and of the backlogs being worked on by the team. If every day team member just report they are working on backlog X and backlog Y, we aren’t really learning anything about if backlog X and backlog Y are really progressing. On the other hand, if team members are required to make a commitment about what they are going to get done on backlog X and backlog Y, we start to get a real picture of how that work is progressing.
Keeping it relevant
The other thing this Scrum meeting modification does is to keep everything talked about relevant. By talking about what was committed to and what is going to be committed to, it doesn’t leave much room for talking about other unrelated issues that are best left to another meeting.
A Scrum meeting is effective because it is a short status meeting. When other stuff bleeds in, people start tuning out and pretty soon we are all standing around talking to the mirror.
I make a point that no one should be talking about impediments that cannot be reasonably be expected to be helped by bringing them up in the Scrum meeting. What is the point of talking about something that can’t be fixed?