"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

Pete Deemer shared a retrospective story on the Scrum Development list today:

"I was doing a retrospective with a team that's about 2 months / 3 sprints into scrum. Coming into the retrospective the team seemed to be feeling pretty low – they had yet to hit their sprint goals, and were seeing other unpleasant things -- and comments like "IF we keep using scrum" were coming up in their conversation.

Over the first hour or so of the retrospective the team came up with two lists: "what's working" and "what's not working". The "what's not working" list wound up being about 17 items, almost twice the length of the "what's working" list. Most of the discussion centered around the things that were not working; it was an imposing list, made all the more so by the fact that it was a lot longer than the other one, and we spent most of the time talking about it. Once the lists were complete, the group spent a moment or two staring quietly at them.

Then, I tried something I hadn't done before. I suggested the team go through both lists, and mark each item as either "C" (caused by Scrum), "V" (made visible by Scrum, ie would be happening with or without Scrum), or "N" (not related to Scrum, ie the weather, etc).
Then we tallied them up.

Under "what's working", the score was C=7, V=1, N=2.

Under "what's NOT working", the score was C=5, V=12, N=2.

We stared at the results for a minute. Then one of the junior members of the team volunteered, a little tentatively: "so it looks like Scrum is actually CAUSING the good stuff, but the bad stuff is mostly just things it's MAKING VISIBLE. [pause] That's exactly what we want, isn't it?". The rest of the team nodded and murmured in agreement. In an instant, the group's understanding of its situation went through what felt like a polar reversal.

Three things strike me reading this story:

1) This story shows how teams can really gain insights through stepping back to reflect on how they are working. Sometimes its hard for people to believe in this possibility until they see it happen.

2) Even though you lay out the basic agenda for a retrospective ahead of time, when you're leading a retrospective you need to be able to flex to the current situation, and be able to see opportunities to help the group think and learn together. If Pete had stuck to his original plan, they might just have prioritized issues, made some actions plans--and then tried to move forward, weighted down by feeling dispirited. To flex to the current situation and see opportunities, it helps to have a repertoire of activities and strategies that you can use or adapt in the moment.

3) It's really common for people to misattribute the cause of problems, especially after a change. Sorting like this would help people make that distinction and help them focus their efforts to tune the change or address underlying problems--whether they are adopting Scrum or making any other change or experiment.

I'm adding Caused By-Made Visible-Not Related to my toolkit. And thanks to Pete for sharing his story. I'd love to hear more retrospective stories!

posted by Esther Derby at 1:39:00 PM  

|