This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Addressing upper management challenges with Scrum
Common challenges often laid at the doorstep of upper management as an organization starts to see the benefits of Scrum are a noisy host of problems that usher in the need for a trio of mind-set changes: resource utilization vs. throughput, competition vs. collaboration and command-and-control vs. servant leadership. In my experience, most of the reasons middle managers give their bosses for “why Scrum won’t work here” boil down to the clash between their past conditioning and the need to adopt these new mind-sets to get the most from Scrum. Some examples:
Heard from the Director of Quality Assurance: “If my people are on only one Scrum team, what are they doing when there’s nothing to test? It’s a waste of their skills to have them hanging around waiting for the team to produce work complete enough to test. My people must be 100% utilized, otherwise I can’t justify having them on staff. So, they have to be on more than one team. Probably more like three teams.” The mind-set change needed: optimize for total throughput, not individual resource utilization. See that optimizing for resource utilization slows down overall throughput which hurts the company’s ability to get work done.
Heard from the VP of Customer Care IT: “Thank you for raising the issue of whether we incorporate changes from operations now or move ahead with the system changes before the ops changes take effect. We need to move on this now. So, while I appreciate this will mean some work-arounds for ops, my direction to you, team, is to focus on the IT changes and get those out.” The mind-set change needed: instead of competing with peer managers, collaborate with them to yield more complete and impactful overall solutions, rather than focusing on the solutions that make your department look like heroes at the expense of other people’s departments and at the expense of the company as a whole.
Heard from the Sr. Manager of Data Warehousing: “I have four Scrum teams now, and honestly, I don’t think it’s worth it. They aren’t producing anything great, just more of the same. I’m still the one coming up with all the good ideas. Maybe I should just go back to managing all of them directly.” The mind-set change needed: move from command-and-control to servant leadership to give people room to come up with ideas better than your own.
All of these mind-set changes require that each of these managers look outside their personal kingdoms and take in the landscape of the corporation at large. That’s why the most effective way I have found to address these challenges (and many more like them) is to “take it to the top.” It often takes upper management to give explicit permission to middle managers to 1) focus on optimizing for overall throughput which 2) requires they collaborate with one another and 3) requires they learn to be servant leaders to their “reports.” In short, giving them permission to undertake these essential mind-set changes and move away from resource utilization, competition and command-and-control. Giving explicit permission is one of the most powerful ways to clear though a whole host of challenges such as those few listed above.
Whether or not upper management permission is forthcoming, I often employ two other approaches to meet such challenges: coach middle managers to help them see how undertaking these mind-set changes can be valuable to them personally and coach the teams to be relentless impediment revealers. These two, together, provide just the right amount of discomfort and friction for the middle managers that they do not (often) retreat to their head-in-the-sand posture. Or, if they do, the team serves up to them the latest impediment and asks that they resolve it which means the head must come out of the sand at least long enough to deal with that impediment. Doing so usually puts them face-to-face with the needed mind-set changes as they work with their peers to eliminate an entrenched impediment or work with the team honoring that the team members are the experts in their own work. Then, when they lean toward the side of throughput, collaboration or servant leadership, I help them discover how doing so helped them personally.
ps. This blog post is taken from my Certified Scrum Coach (CSC) application which is in process. You would think that after writing the Coaching Agile Teams book that I would have nothing more to say on the subject of coaching. Apparently not so. The CSC application is rigorous enough that it causes me to codify what I do unconsciously when I coach people in certain situations. This blog post is an example of one of those “unconscious competence” areas that I did not know I possessed.