Many agile teams fall into the trap of using retrospectives to talk a lot about the past without leveraging that information to achieve the real objective - to learn how to improve going forward, and make a plan to implement that improvement. In short, teams unable to make any changes after their retrospectives are, by and large, wasting their time by even doing a retrospective.
Esther highlights that "the problem may not be with the retrospective; the problem might be with how the team views the changes they've identified in the retrospective". To illustrate this she uses a personal story about two changes she had attempted in her own life; one "easy" change (to do the gym without her personal trainer) that she failed at, and one "hard" change (to lose 10 pounds) that she succeeded with.
From this experience, Esther recounts 2 useful lessons:
Lesson #1: I didn't have a well-formed goal for the first change. I saved money by not paying a trainer whether I went to the gym or not. I guess you could say that's success. But there was a second, implicit part to the goal, which was stay in shape. I might have done better if I'd stated my goal differently--perhaps "Achieve exercise independence." Teams need to look at the implicit goals and values behind their retrospective actions to make sure that both explicit and implicit goals are aligned.Esther goes on to give a set of suggestions for increasing your team's chance of succeeding with your attempted improvements. A slim summary of these suggestions:
Even with a better goal statement, I suspect the outcome wouldn't have changed unless I addressed Lesson #2.
Lesson #2: I thought the first goal would be easy. Because I thought it was a no-brainer, I didn't use my brain to plan the change in a way that would propel me to success. When teams think they face an easy change, they may not recognize how hard it is to change even a simple habit. And by treating the change as simple and easy, they make it easy to fail.
- Feedback: understand upfront what feedback mechanisms you'll use to evaluate success and track progress
- Structure: institute some form of structured way to give yourself explicit opportunity to do what you set out to do
- Support: make sure you've got people (at least each other) to provide a support network for encouragement
Be sure to check out the article for yourself, and let others here know what you think.
Community comments
Link broken
by Johannes Link,
Follow-up next retrospective...
by Kevin E. Schlabach,
Re: Follow-up next retrospective...
by Mike Bria,
Re: Link broken
by Mike Bria,
Link broken
by Johannes Link,
Your message is awaiting moderation. Thank you for participating in the discussion.
The link to the article seems to be broken.
Follow-up next retrospective...
by Kevin E. Schlabach,
Your message is awaiting moderation. Thank you for participating in the discussion.
A by-product of working agile in a FDA regulated company was addressing this issue with documentation and therefore leading to a solution to this problem.
In retrospectives I ran then and still run today, each idea/topic is given an owner by the end of the conversation. Normally this is someone who volunteers, but sometimes we have to assign the closest person. The only time this wasn't true was if everyone agreed to do something, then the group was the owner.
In the next retrospective, we quickly review the prior retrospective topic list and review the outcomes. (Did we do it? Is it working?) If items are considered closed, we remove them. Sometimes items flow another iteration cycle or cause new conversations. The point is that there was an owner that should have run with it for the good of the team.
I call it the accountability cycle.
Kevin E. Schlabach
Agile Commentary Blog
Re: Link broken
by Mike Bria,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hm, they all seem to work for me. Exactly what happens when you click the link?
Re: Follow-up next retrospective...
by Mike Bria,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, fully agree. This speaks mostly to the "structure" point.
Putting a name next to the item is a magically easy way to improve its chances of being accomplished.
I assume you mean that the name doesn't necessarily indicate "the person who will <em>do</em> it", but rather just "the person that will be the bug in everyone's ear if its not being done". The "watchdog".
Now that I say that aloud...I suppose this also speaks to the "feedback" point quite a bit too.
Heck, if you add that this person should be the "cheerleader" for the initiative - then I suppose it also speaks to the "support" point as well!
Wow, and who ever said "What's in a name?.." ;-)
Cheers...
MB