Maybe you already know the Delegation Poker game by Jurgen Appelo. We differentiate the following 7 levels of delegation:
- Tell: I will tell them
- Sell: I will try and sell it to them
- Consult: I will consult and then decide
- Agree: We will agree together
- Advise: I will advise but they decide
- Inquire: I will inquire after they decide
- Delegate: I will fully delegate
Download the new Delegation Poker cards here:
Common conversations in many companies about delegation:
Manager: I wanted my team to have more initiative.
Team: I wanted the manager to give us more autonomy.
If both have similar desires, why doesn’t it happen? In practice, there are more doubts than certainties.
Who hires is the Product Owner, Scrum Master or Development Team?
What training will the team do?
Can we change our tools?
Scrum, being a framework, does not prescribe these attributions.
They vary according to the organization and culture of each company.
Traditionally, these responsibilities reside in the figure of the manager who is not a role handled by Scrum.
However, when we look to have a high performance team, we want it to be truly self-organized and self-managed.
There lies the question: how much can a manager delegate his attributions to the team?
We tend to think of delegation of responsibility as something like this: all or nothing.
Explain the Practice
Let’s consider an example for 6 activities that we would like an answer on how it will be organized.
Examples of activities:
Definition of solutions
(1=Tell, 2=Sell, 3=Consult, 4=Agree, 5=Advise, 6=Inquire, 7=Delegate)
In the table below, as a team, we can define how the tasks will be organized/delegated by the team:
This makes communication fluid and everyone feels responsible for the decisions made for the company.
Why did you decide to use this practice
With the mentality of the dynamics inserted and embedded with the employees, we decided to take the next step and together with them define how the tasks will be delegated to the team.
With the dynamics of delegation poker, we are able to make our collaborators co-create and feel responsible for the whole.
Our main objective was to engage employees and make communication fluid.
The group becomes responsible for the whole.
We held the ceremony with the payment team to decide how the following tasks will be delegated:
Definition of solutions
How did you use this practice
We join the team on a board(miro) already used for other dynamics exposed here.
After defining the task groups with the support of OKRS:
Definition of solutions
We organize the tasks and, together with the team, we delegate.
In this case, the payment team was being used for the tasks.
It is essential that all parties involved are in the dynamic. Otherwise, there will be no engagement of the absent party.
There will be two rounds. The first will define how we are and the second, how we want to be.
As we are
Here, there is an important decision that must be made by all those involved in the dynamic: whether or not to maintain the traceability of the parties involved.
If they decide to keep it, the main advantage will be: clarity, everyone will know what each part thinks.
The downside: it can inhibit employees.
If you decide to keep the traceability, use different colors for the parts.
For each process, ask contributors to decide the level of delegation they believe they have over it.
If there are disagreements, ask the collaborators to explain the reason, especially those that are at the extremes.
Make a note of what they are talking about. Repeat the dynamic until there is a consensus.
Once you have the process delegation level, go to the next one and repeat the dynamic until the last item in the table.
How we want to be
Let’s repeat the entire procedure described in the previous section. What changes is the question: what level of delegation would we like to have?
Important point! The goal is not to reach level 7 in every process.
In some this is not feasible.
For example: hiring and firing it is reasonable for the manager, at the very least, to be informed that there have been changes in the team.
Therefore, the maximum level in this case would be 6.
Viewing current and desired state
In the end, you will have a picture more or less like this.
Delegation Board with combination of states
How We Are (Current State) color red and How we want to be (desired state) color green.
Hiring, Current Status = Level 3, Desired Status = Level 5.
Dismissal, Current Status = Level 3, Desired Status = Level 4.
Promotion, Current Status = Level 2, Desired Status = Level 5.
Choice of Tools, Current State = Level 6, Desired State = Level 7.
Trainings, Current State = Level 5, Desired State = Level 6.
Questions to Answer
Should we consider the current state of the task? how is this delegate currently?
Show the current status and the new delegation status to the team, should we really change this status?
Is changing the delegation state of this task a point for change action?
By changing the delegation status of this task will I impact the team? will generate impediments?
Your learnings as facilitator
It is helpful to think about high level activities before using Delegation Poker.
It is highly recommended for sharing perspectives and creating common understanding.
It is necessary to set aside some time and leave enough space for discussions.
Allowing the team to delegate their own work and tasks makes them accountable and co-creates resolutions.
The next step in the dynamic is to define the actions we will take to get out of the current state to where we want to go in each process.
It is not enough to define the actions, it is necessary to execute them.
It is better to have few actions that you can perform than to have dozens of actions planned and nothing accomplished.