Scrum has 3 roles: Product Owner, Scrum Master, and Team Member. Scrum specifically says the team needs all the necessary skills to do the work, which is why people are referred to as Team Members.
What happens in large organizations that have oodles of specialists? What do the BA’s do? What does the Architect do? How is Change Management involved? Role confusion is one of challenges with Agile Transformation, especially in medium to large organizations. Agile calls for T-shaped people (multi-skilled in many areas, deep skill in one area), or bridge-shaped people (multi-skilled in many areas, deep skills in a couple of areas) and that might be difficult when your org chart contains more boxes than the storage room of your favourite pizza place.
It’s natural for people to want to know what’s different for them when Agile is brought in, and there’s a different way to think about how existing roles need to change.
First, focus on what the teams need to do. Agile or not, software teams still need to build, test, analyze, sell and market stuff. They still need to consider legal, compliance, release management, change management and all the other thing necessary for releasing software.
That sounds obvious, but remember that software teams need testing, not necessarily testers. They needs to be some form of project management, but not necessarily project managers.
The idea of core team members, and floating specialists (or service teams) isn’t new, but it sure is hard to implement sometimes. Here’s a way to think about it:
Family: The core team. These people are in the house, and they own everything in the house.
Friends: These are the people who pop in once in while to help you move a couch, mooch your food, or pop in to say hi to see how things are going. On a software team, these are the people the team asks for help from every once in a while. These can also be the people who need to see what’s going on in the house, especially if the family is renting the house!
Acquaintances: These could be the aunts and uncles you see once every year or so. These are people that are occasionally interested in what’s going on but they don’t really need to be around much. In software, it’s possible that the stakeholder who’s paying for the project simply doesn’t want escalations so they might not even care what the Family is doing. Yes, stakeholders should be involved, but suppose there are 200 Families in the neighbourhood. It’s unlikely the stakeholder is going visit all of them every two weeks.
In a large organization I was once asked to help out with a new project. There were 8 people on this project. 5 of those people were project managers! Why? Because every business area that was interested in the project needed to have a project manager from their division involved.
This is the role trap that organizations fall into.
We assume because we used to have these roles on a project in the old world, we need the same structure in the new world. That might be true, that might not be true. After you’ve considered who’s in the Family, who are Friends, and who are Acquaintances, you can then focus on agreements and expectations:
This was created using a game Shawn and I used with a few teams. We called it The Newlywed Game, and yes, we played the awesome theme song!
After the looks of “why did we hire these guys again?” wore off, the teams loved it! This particular team was moving towards Scrum so we did an overview of Scrum, and the Scrum roles so they would have enough information to have an informed conversation. They discussed how they’d work together, and what they expected from each other.
The key part of The Newlywed Game is that is forced everyone to think about what they expected from others versus simply having the other people describe their role. If you haven’t seen the Newlywed Game, the spouse answering the question has to guess what their spouse would say. In our version, for example, the Scrum Master had to guess what the Team Members expected from their Scrum Master.
The point is, we tend to over-emphasize process, roles and mechanics when we move towards Agile. Agile teams solve problems in creative ways, and Shawn and I could have put role activities in bullet points on a PowerPoint, but the more we focus on helping our teams use their creativity for solving problems, the processes, roles and mechanics will matter a lot less.