On Thursday, September 11th, I had the pleasure of speaking to an audience of around 75 PMPs at the Silicon Valley Chapter of PMI (http://www.pmisv.org/). Anup Deshpande was kind enough to invite me. As it turned out, I was greeted by a great audience with so many questions that we didn’t get to the Ball Point Game I had planned. That might not seem like a big deal. After all, I was able to talk about the history, principles and basic mechanics of Scrum for two hours. Why should we care about a game?
After the class, I talked with several traditional project managers who were obviously intrigued by Scrum. Many said, “What you described sounds so close to what we’re already doing on my team.” And indeed, I imagine that many software professionals are out there, using Scrum principles and even practices without knowing to label it Scrum. But what I realized I hadn’t communicated to the audience were the less tangible parts of Scrum – the non-mechanical parts that differentiate it from traditional management.
Ken Schwaber calls Scrum a “pathway,” a word that might sound a little soft to traditional managers. Put another way, Scrum is not about management, but, rather, leadership. Scrum asks Product Owners to lead by clearly articulating what the business needs by specifying the outputs. Scrum asks the ScrumMasters to lead by asking them to make visible the process and the agreements the team and organization have made together about delivery. And finally, Scrum asks the team to lead themselves by applying their professional expertise to important decisions about how the team is going to deliver what they agreed to. As you can see, each role in Scrum is responsible for some form of leadership. In that sense, Scrum is also about empowered teamwork.
There are other important abstract concepts in Scrum as well. “Teamwork” and “pride” are often empty buzz words in the arena of human capital management theory. Do you remember Hawaiian shirt day in the movie Office Space? Scrum isn’t about Hawaiian shirt day or doughnut Friday (not that we object to silliness or sugar), but rather about getting a team of professionals truly excited about what they’re doing, driving them toward a common goal, and allowing them to experience achievement’s own reward. When team members work closely and succeed, they develop a bond–of respect, trust, and shared responsibility–that far outweighs the lighthearted diversions of most corporate team-building exercises. I should add that Scrum is also about respecting individuals as professionals, which is why you’ll never hear me call an employee a “resource.”
Finally, Scrum is about inspecting and adapting to reality. In terms of implementing Scrum, the unfortunate reality is that adults do not learn very well without experiencing the material in a highly interactive way. This is why, in the Scrum community, we’re willing to play what can appear to be childish games, even if the CEO is walking by while we do it. Ultimately, these activities teach professionals concepts that couldn’t be communicated as effectively–if at all–through a lecture. They translate concepts that help teams work together better and, consequently, create better products. I doubt your CEO will object to better products. So next time I see you, Silicon Valley PMI, we’re going to play.
Download the PDF version: The Value of Games_blog