The Paradox at the Heart of Scrum

"People's ability to participate increases over time if they are developed properly, but giving too much responsibility before they are prepared can cause some real problems."
- Ross Silberstein, former VP and Director of manufacturing, Sherwin-Williams Automotive Aftermarket Division, as found in Kimball Fisher's Leading Self-Directed Work Teams

Agile Scrum is a methodology built upon having self-directed work teams deliver software in small iterations, inspecting and adapting their work at the brief pause between iterations.  A way of working that’s simple to learn but difficult to master, Scrum feeds off of the strength of an engaged team of diverse developers (the theory states that anyone on the team should be able to do the work of anyone else when necessary) and of building confidence that you’re building the right solution though the constant validation of working software at the end of every iteration. In theory, it’s a simple way of working that provides a lot of benefits. I experienced many of these benefits myself working in a small company (>40 people) that built an excellent CRM software product.

And yet over the last few years I've seen nothing but complications in my current work helping with an Enterprise company with its Agile transformation. Some of these changes are perhaps inevitable when you take a system designed for a small team and scale it up to a group of 7K developers – the need for more and more status meetings, planning at ever higher levels to keep the individual development teams in sync with the large company and solution strategy, etc. (There’s even a scaled version of Scrum called SAFe that’s gaining traction with many larger companies.) But the main issue I think is what seems to me to be a paradox at the heart of Scrum: The need for strong individuals to help empower Scrum Teams.

Arguably the most important factor in implementing Scrum is the need to move accountability from the individual – be it a single developer or a general manager calling the shots – to the team or larger group. Scrum requires that the team own their work in a way that unleashes their creativity and passion to solving business problems. The ideal Scrum Team is made up of entrepreneurs who take great pride in their work. However, it’s been my experience that it’s very difficult in a corporate environment to promote this type of ownership without a few strong people leading the way. Call them coaches, guides, or teachers, these people need to bring both a credible and deep knowledge of Scrum as well as charisma (an ability to persuade people) to the table. In short, the teams need to respect this person and her ability so that they want to emulate them.

Many companies feel that they can build these coaches by taking their highly skilled technical people and training them. But faith in technical acqumen does not provide these figures the skills they need to lead people on the journey from individual to team accountability. Knowledge workers have been taught, both implicitly and explicitly, that they are valued for their technical skills. Once we stop promoting employees that are skilled coders into management positions and assuming that this skill alone will ensure success will we move in the right direction. Instead, corporations should be looking for and upskilling leaders – even those that have no deep technical skills – to guide their companies down the Scrum path.  My experience has led me to believe that the necessary skills include a deep knowledge of group dynamics and effective hands-off management (servant leadership, if you will) is the most effective way to get past the barriers to success in larger organizations.  This is a hard skill to teach!

But it doesn't mean we shouldn't try. Developing a cadre of Agile leaders is the key to successfully coaching self-directed Scrum Teams to achieve true independence. Without it, the potential for teams to get caught in an endless storming phase is high. Seems to me like investing in a few Agile coaches is worth the price.