BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Making Retrospective Changes Stick

Making Retrospective Changes Stick

This item in japanese

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.

Rate this Article

Adoption
Style

BT