Improve the improvement process

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Do you do Scrum? I would guess that 90% of Swedish programmers would answer yes.
Do you have retrospectives? Again most developers’ answer is, yes.
Will you empty the impediment backlog before the next retrospective? Silence.

This post is for those of you who remain silent after the last question.

The first improvement is to see the impediment backlog (or improvement backlog which I feel is a little bit more positive name for it) as the sprint backlog for the Scrum Master.

This leads to a changed attitude. No developer would allow non-concrete items in the Sprint Backlog. Developers want to know what to do, what the definition of done is and how the task should be demoed. The same should apply for the impediment backlog. The Scrum Master should make sure he/she knows what tasks need to be done and when the item is considered done.

If the item is about changed behaviour, like “We should be more polite to each other” it can be hard to find actions to take. Having a corner of “wishful behaviour” on the Scrum Board can solve this. My suggestion is to have a maximum limit of three wishful behaviours. If we have more we lose focus. As a Scrum Master, you can remind the team about this behaviour change and check if they feel the behaviour has changed or not.

Conclusion: only accept impediments with concrete action points!

Good luck Scruming

/Tomas Björkholm

Thanks to Yassal Sundman for language corrections and to Mattias Skarin for the idea of how to handle behaviour changes.

2 Comments

  • 1
    2012-03-27 - 08:35 | Permalink

    It is only a small minority of impediments or improvements which come with concrete action points.

    Small trivial issues with obvious action points don’t usually stay on the backlog for long anyway. A good impediment backlog should have around 10 entries on it. (I think I got that from Boris Gloger’s list.) A good third of them will probably stay for the duration of the “project”, and you can attempt an experiment to solve it on the next project, but if the experiment is not conclusive or didn’t solve the problem the problem should stay on the backlog.

    What about cultural or organisational impediments? Those things you can usually only chip away at bit by bit over a long period of time.

    I am still not sure what the correct answer should be to the question “Will you empty the impediment backlog before the next retrospective?”. First of all I don’t know what you mean by silence. Under what circumstances would someone not be able to answer a concrete yes or no?

    For me “no” is the answer, and as far as I know it is the typical, usual answer.

    If someone were continually to answer “yes” to that, I would be interested in seeing what they have on their backlog.

    For me an empty impediment backlog means perfection has been achieved. If anyone has managed that then that would be an interesting blog post.

  • 2
    2012-04-05 - 06:38 | Permalink

    Hi Kurt

    Thanks for reading and commenting my blog post.

    My experience is telling me that it’s a good idea to have just a few impediments in the backlog. I prefer to see three impediments that are fixed instead of ten that are just hanging there. My point is that, what the team and especially the Scrum Master don’t think they will manage to solve during the next sprint, should not be on the impediments backlog. I know this is not in line with Lean but I anyway prefer to focus on the most important ones and forget about the rest. If they are important they will show up during the next retrospective anyway.

    It’s interesting to hear that you think that a good third is hanging for the whole project. That’s actually my experience as well until I decided to handle impediments just like backlog items. Now when the team breaks them down to concrete actions and decides a definition of done, it’s so much easier to get them solved.

    It would be fun if you tried it and let me know the result.

    Good luck
    /Tomas

  • Leave a Reply

    Your email address will not be published. Required fields are marked *