I talk to a lot of teams and role confusion is common. If you haven’t come across role confusion (lucky you) or have, but didn’t know it had a name (unlucky you), Role Confusion is where people aren’t sure where responsibility lies because there is a lack of clarity or context. You can tell when there is role confusion because people start tripping over each other. People get upset that someone is making decisions that they thought they would be involved in. Power struggles, subterfuge and mutiny start chipping away at morale.
One way to solve this is for the top banana to clearly define each role so the confusion is gone. This makes things clear, but doesn’t always solve all the problems.
Here is another way, inspired by reading some case studies in Jim Benson’s ace book, Beyond Agile. I’m calling the technique “Group Role Visualisation”. It is a combination of Agile principles and practices and I think it is new – but am happy to hear if other people are doing it (or something similar).
Group Role Visualisation
The principles of group role visualisation are:
Here is how you run a group role visualisation session.
- Name the roles
- Name the people
- Name the tasks and responsibilities
- Inspect and adapt
Group role visualisation is a “whole team” activity. You simply cannot do this without involving everyone whose name will end up next to a role. If you can’t do it as a team, you’re all fired.
Name the roles
The first stage is to define the roles on a big whiteboard, or a wall, or a big window. For example, if you are using Scrum, you might write up “Product Owner”, “Scrum Master”, “Scrum Team”. Don’t just write up the roles you have, write up the roles you should have.
Where possible, define wide roles like “Scrum Team” instead of narrow roles like “Test Automation Engineer” or “Exploratory Tester”.
Name the people
Get a bunch of sticky notes and write down the name of everyone who needs to have a role assigned. Stick the names up next to the right role.
Most of the names will be easy to place, but the individual should agree with where their name is placed. Some names might be harder to place – either because you’ve missed a role out or because they seem to span multiple roles. It is up to the team to work through these. You can write a second sticky and put people in both roles (this means whole-heartedly in both, not “a bit of both”) or you can add a new role that describes it, or you can agree that they should just be in one role.
Once you are done, write the number of people against each role.
Name the tasks and responsibilities
Generating a list of tasks and responsibilities will be quite a dynamic activity because there will be stuff that you think of half-way through or don’t think of until after the session. This is fine. Shorter sessions can always be run to refine the outcome of the group role visualisation.
The principle of naming the tasks and responsibilities is this; you generate a sticky note with either a task or a responsibility and then assign it to a role. To assign it to a role, it should be an obvious candidate for that role. If it could belong in more than one role, you assign it to the role that has the most people. This may sound arbitrary, but by allocating uncertain items to the most populated roles, you avoid bottle-necks and command-and-control environments.
So to make it absolutely clear, if the task or responsibility could belong to a role with five people in, or a role with 20 people in, it goes to the role with 20 people in.
If a particular task or responsibility is ambiguous, contentious or controversial, create an area for difficult-to-assign items and move on quickly. Don’t get caught up in a long debate about a specific task or a specific responsibility. You can give them another go at the end, although you should still limit the time spent on these. Be motivated by the number of items that can easily be assigned as each one represents better clarity.
Where possible, you should avoid assigning a task to multiple roles. If you assign a task to multiple roles, you must give it an order of precedence. You can do this by writing a number on the task where 1 is the most sensible role and 2 is the second-place role. This indicates who should do the task and who could do the task if required.
You absolutely cannot assign a responsibility to more than one role.
At the end of the session, the roles, people, tasks and responsibilities should be published. Ideally, they should be visible at all times either on a wall. Include the list of unallocated items – it is good to be transparent about the things that you can’t agree on. Until they are given a home, tasks should be allocated pragmatically and responsibilities should be shared amongst representatives of all interested roles. Despite this, try to avoid committees in the long-term. Ultimately, one role should have autonomy.
Inspect and Adapt
Until all tasks and roles are agreed, mini versions of the group role visualisation should be used to reduce the confusion. When everything is assigned you can set-up sessions to allocate any new tasks and responsibilities. You can also use existing retrospective mechanisms to trigger a group role visualisation if the team thinks it can be improved. You can also improve on the technique itself if the format isn’t working.
Each session should generate a new visible chart that is (metaphorically) signed by the whole team.