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!!):
- Customer Satisfaction
- Problem Identification
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.
We are going to try to implement these this coming week, to see if it improves parts of the process. The impact might not be immediate but Rome wasn’t built in a day (I’ve used that quote too often recently!).
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?