I’ve just attended a discussion about process improvements in general and retrospectives specifically, together with a few ScrumMasters. I wanted to take the time to jot down some of the good ideas that popped up as we talked.
Blocked is status of a work item - not people
Being blocked is status of a card (work item) - not a person. I’ve yet to meet a person who, when blocked on one work item, just sits down and does nothing. Most of us will pick up new work (thereby increasing work in progress) or switch to another task.
Here’s the thing; when you adopt a focus on the flow of value, naturally you focus on the work. It is work that gets blocked. Work will not start working on something else, it will be blocked until we (or others) resolve it. Hence focusing on resolving the work that is blocked will naturally gather the team to help each other and hence flow work smoother and faster.
Blockages are nuggets of improvement gold
Blocked items are an exception to how we want work to flow. Waiting should not be a column in your process, but an exception. And in being that we should also be careful about collecting the reasons for the blockages. Blockages hold a story that we can use to ensure that they don’t happen again, not so frequently, or go to the root cause of the problem and maybe fix the larger problem of which our blockage was a symptom.
Retrospective is a great way to build a team
In a retrospective, we invite criticism, improvement suggestions (yes - changes), and bringing up celebrations and problems. Allowing this to happen and taking responsibility for trying to make it better is a way to build a team.
Therefore be thoughtful of if/or when inviting outside people into your retrospectives - it’s a safe space for the team to improve the team. It forms the team together into a well-functioning group that trusts each other and works together toward a goal, i.e. a team.
One improvement is enough
Many retrospectives die on the table since we come out with too many things to fix. Setting the goal of “one little thing that we can improve until the next retro” both sets the scope of the retrospective meeting and makes for an achievable goal.
It is much better to have one little improvement that we do than 15 totally awesome ideas that would change the world of computing that we never do.
Sphere of influence - zone of control
One of the most common problems I’ve seen that makes retrospectives boring and irrelevant is that we try to affect things outside our sphere of influence. If only the entire backend was rewritten as GraphQL or Someone should really change the way we do procurements may be useful, but they are rarely something that an individual team can fix until the next retrospective.
But it’s a good start for what is really nagging us, maybe there’s something that we can do something little about to make our lives better in there. Don’t give up just because it’s a big thing outside of our sphere of influence, but think about what is in our zone of control. And make that change.
Summary
As I was taking these notes I was reminded of the motto of Bob Bemer:
((((DO SOMETHING!) SMALL) USEFUL) NOW!)
It is not as snappy but here’s a suggestion for a similar thought about retrospectives:
((((HAVE RETROSPECTIVES) SHORT) FREQUENTLY) TO CREATES SMALL ACTIONABLE IMPROVEMENTS) NOW)))
Have retrospectives- like, at allHave retrospectives short- do them shortHave retrospectives short and frequently- then you can run them frequently, rather than seldomHave retrospectives short and frequently, to create small actionable improvements- ensure that they create small improvements that we can doHave retrospectives short and frequently, to create small actionable improvements now- do it now. Just start. It’s a good train, get on it.