Roles By Any Other Name… Would they smell as sweet?
I remember back in high school when my good friend was working as what he called a “petroleum transfer engineer”.
He was a gas station attendant.
Titles are not sexy, usually. And, they frequently mislabel what we are capable of or what we do.
Let’s face it, titles suck.
No where else is this more true than in Scrum.
The Scrum Team is all three roles: ScrumMaster, Product Owner, and Development Team.
All three of these titles are just crappy.
Not the MASTER of anyone. They are the master of their craft, which is Scrum. In fact, the ScrumMaster is actually like the servant to the team. They should have been called “ScrumServant”. However, after 20 years of using these titles, we are kinda stuck with them at this point. (Yes, Scrum is 20 years old as of this year.)
The SM coaches the team and to do so, can NOT be part of the team. If we think about professional sports, even though the players are highly skilled, best-of-the-best players, they still have full-time coaches. These coaches aren’t out there on the field doing. They are observing, challenging, mentoring, teaching, inspiring, helping, etc.
The ScrumMaster is there to remove everything from the Scrum Team’s path that may impede them from being a high-performing team. They are the oil in the machine, not the machine itself. If we look at the Sample Checklist for ScrumMasters by Michael James, a good Scrum Master MIGHT be able to be a SM for two Scrum Teams. But a GREAT ScrumMaster is a SM for only one Scrum Team; devoting ALL of their time to helping that Scrum Team become GREAT.
The Product Owner is another horrible name. They don’t OWN the product. The company does. They have the financial responsibility to ensure that the product is making money or maximizing cost savings or making the desired efficiency gains. How they track that is really up to them and sometimes subject to regulations or stakeholder needs. The Product Owner is CONSTANTLY focused on what will yield the most value in terms of features at any given time.
The Product Owner is a difficult role to play because there must be a delicate balance between someone who can actually write the Product Backlog Items (often User Stories) but also someone who has decision making authority. They must have access to “the customer” whomever that might be and also be accessible on a regular basis to the rest of the Scrum Team. The Product Owner is also a full-time role and can NOT be the Scrum Master or someone on the Development Team. Again, there can not be the necessary balance between the three roles if someone is serving a dual role. It just doesn’t work. I say, let’s call them the “Product Shepherd” because they are the caretaker of the product more than anything else.
Another crappy name. It’s not ALL developers. It’s ALL the skillsets necessary to ensure that each feature meets the Definition of Done for EVERY Sprint. If it doesn’t meet the DoD, it ain’t DONE. Period. The Development Team has ZERO resources on it. Let me say that again: THERE ARE NO RESOURCES ON THE DEVELOPMENT TEAM. They are called “people” and these people have “skillsets”. Resources are like coal, oil, sugarcane, pork bellies, orange juice. They are commoditized. Can be bought and sold. AND, when a resource has been used up and consumed, there is refuse which is discarded as garbage while we seek out additional resources. It’s an ugly picture.
People are INDIVIDUALS and I read somewhere that we need to be focused more on Individuals and Interactions here. The Development Team is self-organizing and self-managing. They don’t need to be micromanaged or cajoled into doing what management thinks they should be doing. They need autonomy, mastery, and purpose in order to be intrinsically motivated about their work. (Dan Pink) They went to school for this. They can see through the stick and carrot tactics.
Furthermore, the people closest to the work should be the ones making decisions about the work because they are the most informed source there is. The Development Team might better be called the Delivery Team because what they are doing is delivering features which are valuable, not just meeting the DoD, but delighting the customer all the time.
I propose some new, way more sexy titles that would still reflect the nature of what these folks do. How about:
- Uber-Product Overlord (Product Owner)
- Technology Wizards (Development Team)
- Supreme Ass-kicking Bulldozer (ScrumMaster, clearing the way for the team)
Ok, maybe too… wishful?