This week in a CBS Money Watch blog, I outlined a simplified form of Scrum teams. By combining this process with Tribal Leadership, a modified version also works for executive tribes (groups over 20 people).
Even before publishing that piece, I anticipate hate email coming in from people who do what Daniel Mezick calls “genuine and authentic Scrum,” saying that I didn’t even go through the basics. There was no mention of product backlogs, burndown, or Daily Scrum, just to name three missing pieces.
I wrote that piece for a general management audience, so I ask for your indulgence. Change is incremental. Also, let me be very clear that I’m a newbie to Scrum. I don’t pretend to be an expert here.
On the point of incomplete Scrum, I understand from many friends in the Scrum world that most Scrum implementations fall short of the real deal, and are called “Scrum but” or for the more sarcastic, “Scrum butt”.
Practitioners of Tribal Leadership have to deal with the same issue, which we’ll call “Tribal Leadership But”—when people implement some, but not all, of the system. One example is when “I’m great” executives dictate that a “We’re Great” tribe will be created, or heads will roll. The research-based way to get to what the executives want is to have the tribe discover their own values, build relationships with those values at the center, and then plan micro bursts of activity to convert those values into tangible outcomes. Any attempt to force a “we’re great” effort through tyranny is “Tribal Leadership But.”
The purpose of this blog post is: (1) to highlight why Scrum and Tribal Leadership are perfect for each other, and in fact, need each other; and (2) to see if we can jumpstart a conversation about implementing “Tribal Scrum” instead of a deviant and non-functioning “Tribal Scrum But.”
Why Scrum and Tribal Leadership Need Each Other
Scrum feels a little bit like déjà vu. My first job in college was IT, and I wrote one of the first dissertations about business process reengineering (BPR). I saw BPR’s potential to change not just processes but management itself. Unfortunately, BPR’s implementation was content-heavy—lots of techniques, tools, and processes, mostly implemented by outside experts. Unfortunately, the data on BPR showed huge failures. I’m convinced that the key reason for this failure is that BPR lacked a focus on the necessary culture, values, and working relationships.
What determines success is first making sure the context is ready for change, and then having proven content that become the actual steps. So the rule is “great context and then great content.” In an “over my dead stinking rotting body will I ever do this again,” I spent the years since emphasizing organizational context, so that when something with the potential to transform organizations came along, it wouldn’t go the way of BPR.
For those who don’t know Scrum, take a look at a Scrum overview, the Scrum Guide, the Agile Manifesto, and the values of Scrum. Scrum feels like what I’ve been waiting for. It’s got a soul that’s based in core values, and process that emphasize testing, learning, and iteration. As Daniel told me, “The soul of Scrum is ‘greatness’ and the spirit is ‘collaboration.’”
Also, Scrum promises to provide people a sense of progress, which is the single most important factor in motivation.
Scrum was originally used for software development, with origins in Hirotaka Takeuchi and Ikujiro Nonaka’s “The New New Product Development Game”, and so some might wonder if it’s relevant to executive meetings. I would remind people that “quality” began as a concern of airlines and automakers, and is now a key topic in executive meetings in most organizations around the world. Concepts like “value creation” “product differentiation,” “systems integration,” and “project management” came from functional parts of organizations, and are now part of general management. Let me add my voice to a growing chorus of people who say Scrum, or a version of it, has as much potential impact on general management as quality did years ago.
This grand plan carries a big warning. If Scrum follows the BPR road, and emphasizes practices over principles, it will fail. Early signs of problems would be a rowdy community of Scrum practitioners, “thinking ‘me’ and preaching ‘we’,” in the language of Tribal Leadership. Doing so throws contributions and insights into the darkness, where no one will hear them or benefit.
Many friends within the IT industry love Scrum and are also concerned about the state of the Scrum community. In the words of several people, “Scrum But” is more common than Scrum, especially in discussions within the community of practitioners. For people with that concern, Tribal Leadership may be worth some attention: it highlights how to upgrade the context to a point where a group is nimble, nonpolitical, and hungry for new approaches. In particular, the book (and the resulting movement) show how to discover core values, craft a “noble cause” that adds passion and purpose to work, and also shows how to build “triads”—three person relationships in each person has the back of the relationship between the other two.
This is a critical point. What will kill any organizational change process is the “me first” mentality. As Jeff Sutherland, one of the inventors of Scrum, told me: “We work with some of the best companies who are loaded with heroic developers who think 'I am great and nothing could make me greater.' This inability to work on a team cripples their capacity. They produce elegant designs that no one else can support. We have to bust them lose from this thinking." That’s the best summary of Tribal Leadership I’ve ever heard. The experts in Scrum have the opportunity to become leaders of a business revolution—but only if they move off the “I’m great” point of view.
One of the other potential problems with Scrum is that it relies on three specific roles playing nice with each other: the Scrum Master, the Product Owner, and the Team.
Readers of Tribal Leadership will immediately identify this as a potential triad. If these three build an “I got the back of your relationship,” Scrum will immediately increase its effectiveness. In a triad, the Scrum Master would have the job of ensuring the quality of the relationship between Product Owner and the body of team members. Si Alhir, a master at triads and Scrum, has a great blog post on this subject.
Likewise, many people read Tribal Leadership and ask, “now what?” They got their tribes to Stage Four, are implementing short-term project plans, building triads all over the organization, and aren’t sure what the next step is. What’s missing in Tribal Leadership has been a specific game that great tribes can play against other great tribes. I believe Scrum is that game.
In particular, I’d encourage Tribal Leadership readers to become familiar with Scrum, and to see “genuine and authentic Scrum” (thanks, Daniel) in action, in its native setting of software development. Appreciate rather than critique. Second, if people in both the worlds of Scrum and Tribal Leadership are interested, let’s put the best of Tribal Leadership, along with the best of Scrum, in a blender, add in executive management concerns, hit puree, and see what comes out.
For those who think they already have the answer, please remember: this is about tribes learning together, not about gurus having the answers in which they present to others who are amazed by their brilliance. The latter is “Tribal Leadership But,” and also, I suspect, “Scrum But.”
How to Invent Tribal Scrum
What I’m suggesting in this blog post is that if Scrum and Tribal Leadership are combined, and focused on the concerns of executive leaders, a transformation in organizations will result. The same methodology that is largely powering innovation in software development will allow real-time learning in which new management systems are invented, tested, refined, and spread across organizations. Just as Peter Drucker’s work brought management into the 20th century, the results of “Tribal Scrum” would bring management into the 21st century.
So…how can this happen?
First, let’s be clear that Tribal Scrum will not result from a single person piecing it together and declaring that they have the answer. John King and I tried this approach for almost ten years until we learned to take the “blender” approach to combining what we both knew, trying stuff, refining it, and letting the community determine what worked and what didn’t. What emerged was something different and better than what either of us had contributed. (For those who want to read my version of how Tribal Leadership came about, for possible insights into how Tribal Scrum may evolve, take a look at this 2009 interview with Imno.org. Scroll down to “How did you come up with the Idea for Tribal Leadership?” As is usually the case in collaborations, John has a different recollection of the events. But the point is that it took years of collaboration, back-and-forth, until Tribal Leadership finally emerged as a book that would go on to become a New York Times bestseller and launch a sizeable movement in organizations around the world.)
Second, everyone needs to get immersed in both Tribal Leadership and Scrum. As a part of this process, Daniel Mezick and I are planning a “Mega Mash-up” of what we know about the two areas. You can sign up for alerts on this event here. It’s a starting point, not a set of the answers.
Third, Tribal Scrum will result from lots and lots of experiments—some successful and some not, by combining the two approaches. A key principle is that we need to share what we learn (especially failures) and document what works, that an open-source approach to knowledge sharing.
Fourth, the community needs to determine the winning approaches here, based on adherence to values and contribution measured by merit. Many people in the Agile world have told me that the Agile community has become fractious and contentious … even dysfunctional in some ways. My response is that this evolution is completely natural, and has happened in most knowledge-based, accomplish-oriented fields, including law, medicine, academia, engineering, accounting, and IT. Readers of Tribal Leadership will identify these as the most common fields to have Stage Three cultures, dominated by “I’m great (and you’re not)” conversations. Such discussions involve extended speech-making, almost no listening, and strong-willed personalities trying to dominate the group with manipulation, back-room deal-making, and force. Such approaches will derail the emergence of Tribal Scrum, and the community needs to decide that such behaviors will not be tolerated.
Fifth, we should eat our own dog food. We need a venue, identification of community values, selection of a noble cause, commitment to Scrum (not “Scrum But”) and Tribal Leadership (not Tribal Leadership “But”).
In the spirit of open dialogue, I invite any comments, including those saying I don’t know what the hell I’m talking about. The one rule we will enforce is that comments have merit, and personal attacks won’t be allowed.
So…where do we go from here?