EFFECTIVE SCRUM

Scrum Meetings can be effective and ineffective at the same time.

Idea behind a Scrum meeting:

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 with little information

How many times has this happened to you?

Oh God! 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 someone  with that task he was working on or learning something that i have to work on.
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.

This kind of thinking is contagious!!

Pretty soon you might 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. Nothing is blocking me."

which just does not have any important information .

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.

Add on's to the meeting (just my idea)

Commitment!

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 myself to doing yesterday and how much did i actually finish. If something is left over, why did that happen?
2. What will I commit myself to getting done today?.
3. What is blocking me in fulfilling my commitment.

Commitment is something that carries with it accountability.

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.

Planning a Sprint:

I think planning a sprint is one of the major steps in Scrum.

My idea is to have a day between the end of the previous sprint and the start of the current sprint.

We should have time to look at the product backlog and come up with an "Achievable" iteration backlog. Generally, the sprints are planned for 2-4 weeks and when we don't have at least a day to plan the iteration backlog, it becomes tough for the whole team to visualize how much can be done in that time span. Sometimes the team gets overloaded without proper planning and even after extra hours of work we might not be able to reach the target (not satisfying the commitment.) which eventually will have an effect on the morale of the team and also the clients.

If we don't have a day to plan for the sprint, then, most of the times, we end up planning iteration backlog during the time when we should have been actually working on the tasks.

This reduces the time that we have for burning down the tasks.

Also, whenever a sprint is planned, there should be a task which tracks the time for deployment process.

For example, for a sprint with some major tasks burned down, we might need to give half a day for deployment at the end of the sprint to ensure that the deployment goes well without any issues. Leaving this task out of the iteration backlog or the tasks for the sprint will mean that the team has an extra 3 hours of work which is not evident in the burn down chart. So, they have to work three hours in advance. Sometimes, this can be an issue especially when you have to do a clean build and redeploy the whole thing.

To be continued..............................