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:

  1. What did I do since our last meeting
  2. What am I doing until our next meeting
  3. 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.

image thumb1 Making Scrum Meetings Effective

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.

My solution

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…

Commitment!

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:

  1. What did I commit to doing yesterday and did I or did I not meet that commitment.  If not, why not.
  2. What will I commit to getting done today.
  3. 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?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.
  • http://gravatar.com/configurator configurator

    Well, duh.

    If on Monday you say “by tomorrow I’ll finish the frobber, and on Tuesday you say you worked on the widget instead, the team lead will ask why you worked on the widget instead of the frobber. It’s not always formalised as a commitment, but it definitely should raise questions if you fail to do the tasks you assigned to yourself just a day earlier…

  • http://designcoderelease.blogspot.com Nathan

    Reading your post as you kept bringing up issues I couldn’t help but wonder what sort of environment you’ve worked in that would enable you to BS in the standup and not be called on it by other members of your team.

    If you have a decent agile process then you should be looking to report truthfully the answer the 3 simple questions, and if you BS on them other members of your team *should* challenge you on them.

    Agile processes that effectively empower people working within them rely on trust, honesty and visibility so that the team shares all thats going on. You use an example of “fooling with the build” why didn’t you just state that was what you were doing and why you were doing it? Of course if you weren’t actually doing any work that you were hadn’t already commited to do then why was it being done in the first place?

    What uncle bob has written about in The Clean Coder is how scrum is *supposed* to be run, everybody in the team commit at the sprint planning to doing the work in the next sprint and honestly report what they do, that way you can work out if the team is having to do work that they hadn’t anticipated to feedback into the planning process.

    Whilst personal commitment plays a part I would see the root cause of the problem as with the team, everybody needs to be honest about what they are doing and if somebody isn’t doing something that helps the team achieve their sprint/iteration/cycle goal then it needs to be highlighted and the team decide if it realy needs to be done or should be dropped.

    Bottom line if you are being dishonest about the work you’re doing all you’re doing is hurting yourself and your team.

    • http://simpleprogrammer.com jsonmez

      Hi Nathan, I definitely agree with everything you said. Only problem is that it is not always that straight forward. Often times the BS part is not about lying about what you did, but it is just a matter of saying things that don’t really apply to the sprint at hand or being to vague in what is said.

  • http://kenfaw.wordpress.com ken

    Hi John. At first, I thought I was going to give you just a straightforward agreement, but looking at the comments it occurs to me that it took a decent amount of courage to write all this. Your stock keeps going up in my eyes.

    Commitment, to me, is the foundation of business professionalism in any domain. So when I start a new agile team, I start with notions of commitment and trust.

    To me, commitments starting to breakdown is a symptom of schedule pressures, lack of confidence in problems we might not know how to solve or some other fundamental or mechanistic breakdown that a coach needs to notice, diagnose and act on.

    I agree with Nathan and configurator, but I also accept that when I’ve taken over agile teams that were having trouble, I’ve had to address different situations that ultimately led to failures of commitments and the BS you describe. So not every agile environment is a healthy one.

    If commitments and trust are in your foundation, then breakdowns in commitments and trust can be a “signal flare” to the project coach that your attention may be needed.

    Or if there is no root cause except the developer can’t make and keep commitments, I will remove them from the team… because they are not really a team member anyway.

    Kind regards,
    –Ken

  • http://gravatar.com/hazelm hazelm

    I agree with some of the points in your posts. However, I’ve worked in a large respectable, financial institution for abut 30 years and we do not have an ‘attendance’ roll call which is what I consider the standup meeting to be. Regluar status meetings are established and team members state the percentage of task assigned and explain any obstacles that he or she cannot handle. If it has to be escalated, the PM will undertake to follow up at a higher level. Two things I will mention: some of our staff work on multiple projects so it is not practical to attend standup meetings, also helf the project team telecommute these days.

  • Pingback: Where Is Agile Now? | Making the Complex Simple()

  • Vo

    Scrum, scrum, scrum…
    Too much scrum and your development team becomes a help desk.

    It seems that Nathan is the last romantic in software industry. I would like to see how his team manages the project in that straightforward way. Life (read software development) is more then just a scrum meeting.

  • Pingback: How to Take the BS Out of Your Scrum Meetings | OpenView Labs()

  • Pingback: Scrum Masters: What Makes a Good One? | Simple Programmer()