Overview

Maybe you already know the Delegation Poker game by Jurgen Appelo. We

Taken from Jurgen Appelo’s Delegation board description

differentiate the following 7 levels of delegation:


1 – Tell – you tell how it has to be done, you decide
2 – Sell – you sell a decision, but you decide
3 – Consult – you consult the other before making the decision
4 – Agree – all agree on the decision (best via consensus)   
5 – Advise – you advise the others, but the others decide (even without your agreement)
6 – Inquire – others decide and inform you about the decision
7 – Delegate – others decide and it can be that you even don’t get informed about it
Using delegation poker you can generate a common understanding about how a decision for an activity can be made.

Jurgen Appelo described in his Management workout Delegation Boards how to use a delegation board for visualizing the delegation levels. 

With this post I describe my experience of creating and using the delegation board – with a slight modification of including more roles and visualizing the full delegation path.

A delegation board example

Lets consider an example for 4 activities we would like to have a picture about the delegation level to use.

Roles involved (with some implicit hierarchy by CIO) – CIO, Manager Software Development (MSD), ScrumMaster, Development Scrum Team.

Example activities are:

  • Hiring decision – if the team can hire one more team member. How should all roles be involved in deciding about a candidate
  • Agile process changes – e.g. if the team would like to switch to ScrumBan instead of Scrum
  • Holiday approval – how is the decision path for standard holidays (e.g. up to 2 weeks)
  • Team event – based on a given team budget, how can the team decide on a team event to do


With the help of delegation poker for all constellations (CIO with MSD, MSD with ScrumMaster, ScrumMaster with Team) and for all activities the delegation board can look like the following example:

(1=Tell, 2=Sell, 3=Consult, 4=Agree, 5=Advise, 6=Inquire, 7=Delegate) 

Task CIO with MSD MSD with ScrumMaster ScrumMaster with Team
Hiring decision 5 4 4
Agile process change 6 5 4
Holiday approval 7 5 4 (future 5)
Team event 6 5 5


Some explanation:
Read the table headline from left to right for the delegation flow (delegation flows from the CIO to the Team). This means – the CIO needs to be involved in a decision made by the MSD, the MSD needs to be involved in a decision made by the ScrumMaster, the ScrumMaster needs to be involved in a decision made by the team in what way.

E.g. for a holiday approval the CIO delegates it completely to the MSD, the MSD would like to be involved with an advise – as the MSD has an more global overview for all teams. The ScrumMaster currently comes to an agreement with the team about the holiday – considering the advise by the MSD. 

The future 5 means – the team should get the full power to decide using advises from roles having a broader overview.

What’s the value of it?

Implicit gets explicit – all involved get a common understanding on how to come to a decision for an activity. Using delegation poker fosters communication and converts implicit assumptions about how decisions should be made to explicit agreements.

Faster decisions – all agreed on how to decide for an activity. This removes waste by avoiding to many recipients via e-Mail distribution lists and large meetings with an attendee list showing, that roles and responsibilities are not clear. You know whom to involve when and how to come to a decision. 

Knowledge transfer – about roles and responsibilities. I often faced the problem that it’s not really clear what a role implies and all assume something about it. The delegation board shows for a role how it’s involvement looks like. It’s not a replacement for a role description, but clarifies already a lot. 

Questions to answer

Should you consider the current state of delegation or how it should be in your optimal environment?
I used the current version and as you can see mentioned in braces what the optimal solution would be. 

This is an action point for changing the environment, that can immediately go to the impediment list. I would suggest the role blocking the delegation works on it with the role that would like to have it delegated and with this under it’s circle of control.

How to further use it?
Printing it on a large poster and putting in in every team room is one good option to visualize it. But this should not block it from getting changed. As soon as a decision paths stills feels to complicated get together and discuss via delegation poker about it.

I suggest its distribution to all teams and all roles involved. Sharing it on a central place (like a Wiki) is a good way to keep track on its changes and development and simplifies usage in meetings and decision making sessions 😉

My learnings

  • It’s helpful to think about high level activities before you play the delegation poker and create the delegation board.
  • Delegation poker is highly recommended to share perspectives and creates a common understanding
  • Reserve some time and leave enough space for discussions. You will safe the time afterwards.

Further investigations

Did you use the delegation poker and/or delegation board? What’s your experience?