I often hear the same complaint about Agile Retrospectives: They are not held at the right level in the organization! Or, at least, that is the conclusion that people draw from one fact: Many issues brought up in the Retrospective need resolution at a much higher level in the organization. There is no one in the room who can address or resolve them.
[bibshow]
Today, I found an article that really caught my eye [bibcite key=”citeulike:13057341″]. Menzies et al take a look at extracting lessons learned (with SBSE) from software code at three levels: local, cluster and global. Their conclusion was that the best lessons learned are to be found at the cluster level. If that holds true for agile retrospectives as well, then the implication would be that retrospectives should be held between teams rather than within teams.
As I was looking for research to support or refute my hypothesis above, I ran across another article where Brewer et al show a heavy bias from any feedback on performance received immediately before (an individual) performs retrospective introspection [bibcite key=”citeulike:13057362″]. If that’s applicable to agile retrospectives, then we should never perform them immediately after the demo!
References
[/bibshow]
Retrospective lessons learned and improvements are possible on all levels. I think it is not either team or organization/project, but both have value.
Teams should focus on what *they* can do rather than tell other what to do. Team retrospectives deliver actions that the team can do themselves and retrospectives give power to the team by supporting them to self-organize and find better ways of working.
When you have agile projects with multiple teams, you can improve collaboration with the retrospective of retrospectives. This is a good way to share learnings across projects, and to solve problems that projects are facing.
Due to planning difficulties, we have moved our retrospective a day ahead of the demo. Because the team missed the ‘great demo’ positive stickies (the demo was already 2 weeks gone, so less top-of-mind), I looked for ideas to fix this and since that day we are happily & successfully using a continuous retrospective tool. In our case a ‘snake’ biting its own tail, divided into the days of the sprint. There we can post notes as they come up and discuss them in the retrospective meeting in addition to the notes that we think of at that specific snapshot in time.
We got the idea from Rachel Davies: http://agilecoach.typepad.com/agile-coaching/2013/10/kickstart-your-retrospective-with-continuous-timeline.html
As a follow up to this: I can proudly announce that the team has evolved the ‘snake’ I mentioned in my previous comment into an “Agile around the block” (Agile blokje om in Dutch). They have also added the team values poster we created a while back to its center. And rarely a sprint goes by without one or more notes on this continuous retrospective timeline. Go team!
Thanks for sharing this. Looking forward to see your blog post with some photos and more to better understand your achievement.