Yesterday, an important and interesting story passed through the scrumdevelopment yahoo group. It seems that a team was experiencing substantial pain using Scrum. This story shows an interesting and effective method of addressing that pain during a retrospective. Pete Deemer, who is Chief Product Officer of Yahoo!â€™s 700-person Research and Development organization based in Bangalore, India, tells the story:
I wanted to share an interesting experience I had 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.
It was a really wonderful moment!
For a process facilitator using any agile method, this is an important tool to be able to use. It is simple, and gets to the heart of the unspoken concern that many new teams have that agile is causing all the problems. In fact, most often, agile is simply exposing all the problems that are part of the organization, the environment, the team dynamics, the technology being used, or even the people on the team.
About Pete Deemer:
Pete Deemer is Chief Product Officer of Yahoo!â€™s 700-person Research and Development organization based in Bangalore, India. In this role, he oversees product development and innovation for products in both the US and Indian markets. Pete served previously as Yahoo!â€™s US VP of Product Development, guiding product development practices company-wide, including the adoption of Scrum. He has served in executive roles at CNET, Ziff-Davis / ZDNet, International Data Group, and was Publisher of the Letâ€™s Go guide series. Pete has an honors degree from Harvard University, and served for a number of years served as a lecturer at the University of California â€“ Berkeleyâ€™s Haas School of Business and UC-Bâ€™s Graduate School of Journalism, teaching classes in product development and strategy.