In my last post on retrospectives I said that at the end of each retrospective the team should settle on an action that they believe will help improve the next sprint: the retrospective objective.
James Shore and Shane Warden’s advice on choosing a retrospective objective in The Art of Agile Development (2008) is two-fold:
- During the retrospective, don’t worry about the detail: a general direction is good enough at this stage.
- Choose just one objective: it helps the team focus, and improve incrementally without feeling overwhelmed.
As a team, we’ve not been terribly good at doing either of these, to be honest. I think we’ve been guilty of trying to bite off more than we can chew; taking on too many changes at once.
In a recent conversation with one team member mid-sprint they told me that they felt a quite overwhelmed by how often our processes change, and that they didn’t feel able to keep up. That backed up my feeling that we were agreeing to too many objectives each retrospective.
As did this tiny piece of empirical evidence: we had a list of 22 outstanding retrospective objectives going back three months.
Twenty-two. Over three months.
Each fortnight we were faithfully gathering together, reflecting on our practices, and distilling our deliberations down to a handful of actions that we felt would improve how we worked. But there were so many suggestions that we couldn’t complete them all during a single sprint, so some would spill over to the next sprint, and the next sprint, and eventually we had a list of 22.
A retrospective on the retrospective objectives
So at the end of sprint 22 (codename ‘Manuel Quinziato‘) we agreed to not have a retrospective. Instead, we sat and collectively went through each objective on the list and addressed it there and then:
- Has this objective been completed already?
- Is this objective still needed?
- Can we do this action right now?
About a fifth of the objectives had already been completed, so we deleted those. Around a third were about collectively reminding the team about our agreed house rules and processes (how we use Trello; how to manage interruptions; rules around meetings, daily stand-ups and planning.) So we spent probably half our time that Friday morning reminding ourselves what these rules were, and revising them where necessary.
At the end of the hour we were left with just one objective: review our ‘universe of work’ and a decision that this should be looked at more closely in our next weekly strategy meeting on Wednesday.
I’m encouraged that our team can see so many opportunities to improve our processes, and have a drive to keep on improving — “ever to excel” as the University of St Andrews motto says — but even with the best will in the world we still have only fixed time and fixed resources. And we’re human: one change can be hard, a list of 22 can feel overwhelming.
Next sprint we’ll try to limit ourselves to selecting only one retrospective objective. And before the retrospective close-out we will figure out how to track it, who should work out the details, and who should action it. By taking on less, this should give us a better chance of allowing the changes become a part of the team processes, and allow us the space to better evaluate whether they are working or not.
This has been a valuable lesson, and has got me thinking about how we might go back to the basics on some other elements of Agile and try to improve our understanding and commitment to those too.
The Agile adventure continues…
Originally posted on the University of St Andrews web team blog.