We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:
Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.
Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.
This is the story of one such retrospective.
Obviously you can perform many Agile practices, but not be Agile. However, there are a lot practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.
In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also colour coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.
Special thanks to Jurgen Appelo for providing the initial list I worked from:
Here is a link to a google doc with the prep work I have done, to save you some time:
Reducing the complexity
With over 50 cards, there was a lot of information. We split into groups and started categorising the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.
- Doing (Working Well): Things we are currently doing, and quite happy with they way they currently work.
- Doing (Could be better): Things we are currently practising, but could use improvement.
- Not doing (By choice): Things we are not currently practising, but have made a choice not to use in our context.
- Not doing (Not tried): Things we are not doing, and have never really tried.
- WTF!?!: We have no idea what this is, or what it means.
Deciding what to focus on
We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:
- We should start and or alter this practice in some way. (Indicated by a dot)
- We would like to learn more about this practice. (Indicated by a +)
I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.
Discussions and action points
We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:
Root Cause Analysis/ 5 Why’s
We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might revel something we would have otherwise been unaware of.
1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand ups, then we should also consider doing a more in-depth analysis of those items.
We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.
1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.
Behaviour Driven Development (BDD):
This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.
1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.
This retrospective was reviewed well by the team, everyone generally liked it.
It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.
Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future we would probably recommend only focusing on these things.
There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully a bit cheaper for you, as we have provided the work we have done. Once again: https://tinyurl.com/l8loec6
It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list before hand.
Despite there being so many items, the list was no even close to exhaustive, and it was hard to leave off some practices that really should have been included.