Ones and Threes

I discovered recently that some team members had never heard of the retrospective prime directive or it’s essential concept of ‘no blame’. To me and the facilitators of our retros the idea was implicit, and never stated so I introduced the concept at the next retrospective.

While doing that, I found myself apologising for the wording of the prime directive, which I found slightly patronising.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

It turns out I’m not alone in having a problem with the current wording. There’s plenty of discussion and some alternatives here and here but I didn’t find any alternatives the really hit the spot for me.

For me the essential driver in this is that we should be able to talk about anything in the retrospective, but that idea could lead directly worries about a blame-fest. So here’s the wording I came up with.

We should be able to talk about anything that happened, even the bad stuff, in a blame-free environment.

We shouldn’t get blamed as a result.

We shouldn’t need to blame anyone. Anything that we saw happening that we didn’t like, happened because somebody had good reasons to do something, that seemed right at the time, given the context.

I’m sure that could be tweaked some more, but that’s what we’re using for now.

Technorati Tags: agile, lean, prime directive, retrospective

I’ve been meaning to write for some time about the way we handle the feedback loop normally known as ‘retrospective’, and I’ve finally been spurred into action by a similarly themed blog post. Here’s how we do it.

At our daily ’standup’ one of the steps (after we’ve reviewed the Kanban board) is that I ask if we’ve got any ‘wishlist’ items. This is the shorthand we’ve adopted for anything we wish would happen to make things better or anything that regularly gives us pain that needs to be addressed. Anything we come up with goes on the ‘wishlist’ which in our case is an AgileZen board with columns for each team member.

Also, if anything arises during normal work that’s an issue that can’t be resolved without deep discussion, that too goes on the wishlist.

Each team member looks after their own wishlist column and keeps the most important stuff at the top.

Then once a week at our regular team meeting we review the top items from each list. We have a small team so there’s no defined process for item selection. Sometimes I pick one that looks important to me, often I ask the team (since we’re all looking at the same board) what’s the next most important item. The ‘product owner’ is part of this meeting, and as a result if we come up with an item that needs a fair amount of work, he can decide if it’s something that goes straight onto our Kanban board, or whether it’s an item that is put back to the product backlog to compete for priority with other work items.

We address ‘wishlist’ items in under a week typically, and if items do get passed over in the team meeting, that’s fine, there was obviously more important stuff to be done. We don’t use the wishlist for true impediments or blockages, those are treated in a stop-the-line fashion, either fix on the spot or at the very least, escalate to the product owner during the daily standup. And any issues that come up during the week that we can resolve within the team with a few minutes chat or perhaps up to an hours action obviously don’t make it to the wishlist board either.

This is working fine for us in our context, closing the loop in a week usually. I hope that gives a few ideas if your own ‘retrospective’ process isn’t working so well.

Technorati Tags: agile, kanban, lean, retrospective