We keep having weekly retrospectives about the Kanban board.
Last week’s retrospective probably went a tad off target, or maybe it produced ideas which don’t improve the process of our team, rather than general ideas about the board. Note: no idea is wrong or right during these retrospectives – it’s just the focus might have been lost on the purpose of Kanban.
Last week we looked at things that “went well”, things that “went wrong” and things that we wanted to “improve”. We then voted on which improvement ideas we wanted to implement. You can see what we implemented in my last blog post.
This week we invited Andy (our very own Lean/Agile samurai) to the retrospective, partly to see how we should run a retrospective, and partly to get some focus back on Kanban.
The following was the rough structure of the retrospective. The first was a discussion between pairs about “Why we wanted to do Kanban?” and also “What we wanted to change?” These where put on post it’s and stuck to the wall randomly.
We silently organised as a team the post-it’s into groups. I found it especially interesting the commonality between the post-it’s that each of the pairs came up with – probably not very interesting since we all share the same goals & grievances!
The team then came up with the following list of categories for each of the groups of the post-its (in no particular order – I just wrote them down this way!!):
- Teamwork
- Customer Satisfaction
- Problem Identification
- Prioritisation
- Predictability
- Speed
- Transparency
The team scored each of these with either an “x” “–“ or “tick” depending on how we felt things were currently. We scored the majority with a “-“on some categorices and “x”’s on other categories – as you would expect. None we scored with a “tick” – we had some small ticks though!!!
We then paired again (with different pairs) and asked each other how we could improve the process targeting the above categories.
We fed this all back in to a whiteboard – and came up with a list of things to improve. We each had 3 votes again and got to vote on an idea we’d like to implement. The ideas we are going to implement are as follows:
- Measure cycle time overall and between different work types & stages.
- Limit number of items coming in to the start of the workflow & each stage.
- Cut things down into smaller chunks of highest value.
An important thing for me is that we start to get some stats about the work we do in our “development system” – i.e. how long it takes for us to complete different work – what is the cycle time for a specific type of work?
Great summary Dave.
I think the key difference between this week's retrospective and last weeks was that the improvement ideas were targeted towards agreed goals; i.e. the categories we came up with as a team.
This resulted in ideas that will take us closer to a full Kanban implementation.
One other aspect that I think really helped was Andy's explanation of Little's Law. This explains why limiting WIP is a good idea.