Scrum's fourth role: the MetaScrumMaster

After a hard days’ work, it’s nice to have dinner with a thought leader to restore the batteries. Jeff Sutherland – father of Scrum – was with us for a few days to give a Scrum training and to be a speaker at our annual Gartner session. During a pleasant dinner the conversation ranged from Jeff’s life on the road and project experiences to politics, bad wine snobbery and – of course – Scrum. (BTW, talk about an inspiring speaker: after his keynote I could hardly contain a loud YEEHAAW-YES!-YES!-moonwalky thing… Highly recommended ;-))
I was wondering about the buzz on a fourth Scrum role: I had heard that there’s a new “Manager” role to be added to Scrum, and asked him what it’s all about. Jeff explained that the incentive came from CMMi level 5 compliance: for this level the new role was needed, but I now understand that in general this role is important for Scrum adoption and implementation in an organisation.

To understand the new role, you need to understand the MetaScrum. The MetaScrum is a meeting where the chief Product Owner and all the company stakeholders come together to deal with the effectiveness and direction of Scrum in the organisation. When I asked Jeff if the Manager role presides over the MetaScrum, Jeff answered no, the chief Product Owner does. The Manager is responsible for enabling Scrum in the organisation. That’s when it clicked in place for me. The Manager is a ScrumMaster once removed: what the ScrumMaster does for teams and projects, this MetaScrumMaster does for Scrum in the whole organisation.
Let’s look at the parallels between the ScrumMaster and the Manager/MetaScrumMaster. The ScrumMaster:
– is not responsible for the product (the team is) but for the process,
– coaches the team on Scrum,
– removes impediments for the team,
– challenges the team to improve the way they work,
– facilitates meetings,
– does reporting and administration.
The Manager has a parallel, but wider organisational scope. The Manager:
– is not responsible for the success of Scrum projects themselves, but for the successful use of Scrum by the organisation,
– makes sure that the use of Scrum in the organisation aligns with the business objectives,
– removes impediments to the adoption and effective use of Scrum in the organisation,
– enables resourcing on Scrum projects,
– challenges Scrum practitioners to improve the way they work.
I still don’t get the CMMi level 5 connection (Jeff is working on a paper with a CMMi auditor, I guess we’ll see by then), but boy do I appreciate the need for adoption champions in organisations… I feel we’re at the front of the wave for agile adoption, and what makes it relatively hard is that agile is so much a people and culture thing. Adopting technologies is relatively easy: go from JEE to COBOL to .NET to Ruby and back? Piffle!
In my experience in getting agile thinking, principles and practices adopted by an organisation I’ve seen the following issues where a Manager would be a great help:
Enabling real teams in fragmented organisations. I’ve seen quite a number of large organisations that are divided along functional lines: DBA department, UI designer department, ivory tower, WebSphere operations, Unix operations, testing department, business intelligence, and so on ad nauseam. I’ve found that many cases of “claiming resources” are actually “pushing tasks into departments”. Everybody stays at their own desk, and project leaders run around trying to connect everything. Project leaders also spend lots of time negotiating for resources at every department. I’ve even seen insanity like a whole request-quote-haggle cycle for 8 hours of work, or work queues of two years because everybody claims resources with every department “just in case”… (I call this Big Claim Up Front: it has striking similarities with the relation between BDUF and unused features in a system). A Manager can help to make sure that teams become true teams by allowing them (even forcing if necessary) to co-locate, and by fully assigning people to a team instead of letting projects kill themselves, one micro resource claim at a time.
Assigning and empowering Product Owners. Once you see what a good, empowered Product Owner can do you start noticing the severe lack of them in almost any organisation. There are people who manage changes during the project and maintenance phases of a system, but they’re almost never the owner of the system, and the true owners are generally far off in the business somewhere.
Supporting ScrumMasters by helping to solve organisational items on their impediments list. A typical ScrumMaster will have two or three items he or she can solve, and a whole bunch of items that have their roots in broader organisational insanity. ScrumMasters generally don’t have the hierarchical leverage to solve these issues and need a champion in higher management.
I’ve personally experienced the fact that ScrumMasters are the most fired people of all. Even though many times I’ve filled the role only informally, challenging the status quo in an organisation will likely get you a knife in the back unless you’re very, very good at politics. Fear of change does strange things to people…
Jeff, please step on it with the Manager role… I need my MetaScrumMaster!