Free, Cheap, Scheduled: retrospective technique

I was telling Esther Derby about a little trick I worked out some time ago at one of my clients. The retrospectives had gone stale, with team members offering the same "we should..." list iteration after iteration.  I suspected that they didn't feel that they really had the authority or permission to change their process for the better.

I had a good relationship with the CIO and wandered into his office.

I said, "we have some changes we want to make, and they won't really cost any money or affect other departments, and I just wondered if you think it would be okay to do them."  The CIO looked at me incredulously, "Of course. That's a silly question to ask."

"Alright, then there is this other change.  It might take a few man days out of each iteration, but it will be helpful for the team.  Would that be okay?"  He sighed, "If it's a few man days per iteration, we can afford that. Go ahead and take that time. You don't need my permission for that."

I paused a few seconds for effect. "We also have recognized some tough changes we need to make.  They might take a few man weeks out of an iteration.  Would those be okay?"

This time I got a few seconds of silence in return. "Tim, we can do that kind of change, but we have to schedule it. We can't put releases at risk, and we have promises to fulfill, so we just need to make sure we do them at the right time.  They need to be worth it, but we can do that."

I thanked the CIO and wandered back to my team in time for the retrospective.  The team identified many of the same problems, and proposed the same solutions they hadn't worked on the last few times. I went up to the flip chart and divided it into three sections called "Free", "Cheap", and "Scheduled." I explained that these categories had been approved by the CIO and we should begin making changes immediately after the retro. I asked them to pick things they really wanted to do.

The team put changes into the correct buckets, and we picked the ones they felt that they had the energy to work on. The scrum master took the task of moving the "scheduled" items into the schedule, the rest we started on immediately.

If your team is having trouble believing that they really have permission to "spend money" making changes to they way they work, maybe you will find this technique useful.