Making Retrospective Changes Stick

Posted by Mike Bria on Sep 24, 2008

Sections

Process & Practices

Topics

Agile ,

Teamwork ,

Agile Techniques

Tags

Continuous Improvement ,

Retrospectives

Agile teams often find that its easy to talk about change during their retrospectives, but not always so easy to make that change happen after the retrospective. Esther Derby, well-known thought-leader on the human aspects of software development and co-author of books such as Agile Retrospectives: Making Good Teams Great, recounts an experience from her personal improvement efforts to illustrate this and offer a few suggestions on how to succeed with making change actually happen.

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.

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.

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:

• 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

Esther completes her advice with a final suggestion to use something like a Force Field analysis to identify the factors that will propel the change forward and those that will restrain the change, and to use that information to your advantage when establishing your go-forward plan.

Be sure to check out the article for yourself, and let others here know what you think.

1. Back to top

   Link broken

   by Johannes Link

   The link to the article seems to be broken.

   Reply

2. Back to top

   Follow-up next retrospective...

   by Kevin E. Schlabach

   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

   Reply

3. Back to top

   Re: Link broken

   by Mike Bria

   Hm, they all seem to work for me. Exactly what happens when you click the link?

   Reply

4. Back to top

   Re: Follow-up next retrospective...

   by Mike Bria

   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
   
   
   

   Reply

• Older >