Making Retrospective Changes Stick


Recently, a reader wrote to me with a concern about retrospectives. "We make decisions," he wrote, "but we don't have the discipline to carry them out. The team is starting to feel like retrospectives are a waste of time."

If the team fails to resolve issues and make improvements after their retrospectives, they are wasting their time. But 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. I'll share my story of two personal changes to illustrate what I mean.

A Tale of Two Changes
Last fall, I decided to make two changes in my life. First, I decided to save some money by giving up my personal trainer and going to the gym on my own. I thought this would be easy because I know how to design a good workout. I'm familiar with all the equipment in the gym, and after working with a trainer for years, I know enough exercises and variations to avoid falling into a rut.

I also decided to lose ten pounds. I expected losing weight would be quite difficult. In my thin days, I'd listened as friends complained about losing weight. I'd watched other friends go on and off diets and witnessed the gustatory gyrations of a colleague following Atkins as she traveled twenty weeks a year. I knew it would be hard, but I had to try.

It's now been a bit over six months since I resolved to make those changes, and I can report that I followed through on one decision and the other fell by the wayside. I failed on the "easy" change. After making it to the gym once in three months, I re-hired my trainer. However, I exceeded my goal on the "difficult" change by losing 25 pounds.

What enabled me to succeed at the difficult goal? What allowed me to fail at the easy one?

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.

Brainful Change
I succeeded in my goal to lose ten pounds by giving myself structures and supports that would help me reach my goal, and I developed a strategy for when I knew it would be hardest to hold to my resolve.

I used a point system to track how much I was eating and exercising. Tracking made me much more aware of my eating actions and helped me make choices. I also bought a scale so I could measure my weight and see my progress.

When the team members are deciding what to do in their retrospective, set aside a few minutes to consider how they'll evaluate success and track progress.

One team chose a goal of increasing their automated unit testing by writing at least one test for each story they worked on. They added a column on their task board to track the unit tests for each story. A team that wanted to improve code quality by pairing created a tracking sheet and made a check mark each time they caught a defect that would have been missed without another pair of eyes. Structure
I established a "weigh-in day" to help hold myself accountable.

A structure can be anything that creates an opportunity for the team to do what they've committed to do. The team who started pairing created and posted a pairing schedule. A team who wanted to improve their design skills did cooperative reading and set up a weekly lunch to share key ideas.

I am lucky to have a husband who will eat pretty much anything I put on his plate and is willing to grill whatever I bring home from the store. Support can be an "atta boy," or it can be access to books, training, coaching, and experts. The team who wanted to improve their refactoring purchased books and supported each other by walking through their refactorings with each other.

A Counter Balance
That was fine for when I was at home, but I travel. That's where the extra pounds came from in the first place.

As soon as the waitress set the plate in front of me, I'd cut the portions down to size: a serving of meat is the size of a deck of cards. A cup of pasta is about the size of a tennis ball. I didn't have to rely on will power to stop eating; I had a handy heuristic and a specific action to help me stick to my food plan.

When you review retrospective actions, think about what will make it hard to stick to the resolve. Use a Force Field analysis to identify the factors that will propel the change forward and those that will restrain the change. What can the team do to strengthen the drivers, and reduce the retraining factors? See the hand-drawn chart of a force field analysis below:

Most changes aren't no-brainers, even when they sound simple on the surface. Save a little time in your retrospective to identify how the team can use feedback, structure, and support to help them make the change. Consider it insurance for the investment you've made in a retrospective.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.