If you’re new to retrospectives, you might think it’s just about solving problems. Of course, largely, it is, but it’s kind of bigger than that. Following on from my last post, I did some thinking about the real reasons, the underlying reasons, we do retrospectives. I think it’s ultimately about team improvement, both addressing problems but also finding ways of amplifying and repeating successes. If you follow the practice of categorising retro topics under smilies and frownies, even then, you could easily populate the smilies column with things to celebrate (hey, celebration is good) and miss the opportunity to post new techniques or working practices that were successful (e.g. “I cut my coding time in half by having a deep conversation with marketing first”).
There’s a follow-on to the objective of improvement too. The question “Do we need to do retrospectives ?” becomes “Can we improve ?” and I think the answer to that is almost always yes. Granted, I guess there will be some teams for whom this kind of inspect/adapt cycle happens spontaneously without the formality of a retrospective, but for the vast majority of teams, retrospectives pay dividends.
So anyway, I tried to sum this up in a statement which could be read out with the prime directive, or rolled into working practices, or whatever.
We would like to think we could be the perfect team, but we accept that almost nothing is perfect, and we can improve how we work.
Since the last retrospective, we did lots of things, and lots of things happened. Some were good, and maybe some were bad.
Let’s look at the most significant of those things, and see what we can learn about improving how we work as a team.
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.
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.
I’ve been nominated to contribute to Agile Retroflection Of the Day 2.0 by Levent. Todays subject is
What Do You Do When You Don’t Know What To Do?
So here goes …
Don’t Know What To Do because there’s nothing demanding my attention ? I take a step back. What was I doing last ? Is it truly finished ? Could it be made better ? What about the thing I did before that ? And before that ? What about the skills I use to do all these things, could they be improved ? Would I get better results if I studied some more or practised some more ? What has gone wrong recently ? Is there a pattern to those things ? If there’s a repeating pattern, maybe there’s something that can be done to prevent the problem recurring ?
Don’t Know What To Do because I’m stuck on, or confused about, my current task ? I take a step back. What is it I’m trying to do ? Not the immediate thing I’m working on but the underlying purpose of that task. If the task came to me from someone else, I talk to them. And in any case, I try to work out the the real boundaries of the problem and see if there’s a different approach that may yield results. If it still looks hard, is it worth digging deeper for another purpose underlying the one I’ve already found. And of course, what about other people who’ve attempted the same task, colleagues, friends, family or people like me who are online ?
There you go. Nothing earth-shattering, you’d think, but I know from personal experience not everyone explores all those avenues. And I’m sure there are more that I don’t do that I should. You’ll detect the technical angle in the above (not surprising, since I’m a Developer and a Dev Team Leader) but I think the principles are broader than that.
Thanks for the opportunity Yves and Levent.
I’ve achieved two of my objectives in implementing Kanban, and they’re both down to the visualisation of workflow.
The products stakeholders were introduced to the Kanban board yesterday.
All I had to say was “pink and purple are emergencies and support tickets, yellow is the coding you want us to do, and the flow is left to right” and they got it. They got a message that coders have been trying (unsuccessfully) to convey to them for many years. Yes, ad hoc stuff gets in the way of scheduled development. (The green, by the way, is tasks the team has found they need to do to facilitate other work)
The second success came at the end of the stakeholder meeting when they spontaneously decided (no prompting from me) that they needed to prioritise the ad hoc stuff against the scheduled stuff, and we walked over to the Kanban board to do it.
The power of visualisation.