Priorities matter at every step of an agile design and development process, yet setting priorities is a daunting task and prioritization in group within a workshop even more.
Reaching general consensus on priorities is always hard
I remember many workshops I facilitated where the mood was open and friendly until I invited the participants to set priorities in the ‘big cloud’ of needs and wishes postit-ed on the wall. At this crucial moment, two distinct group behaviours would occur:
- All participants would turn their heads at the ‘boss int the room’, because after all that’s her/his responsibility,
- or every participant would get ready to defend his stake.
Funnily, 90% of the identified scope would in both cases be marked as ‘absolut priority’. As a process moderator, if you reach the consensus that “everything is absolutely needed”, well … you failed.
Yet the goal was simple: no two things should have equal priority. But the trick is that this is almost impossible to reach through group discussions. A more reasonable goal for prioritization in group is to define a pyramid of priorities.
I’ve come up with a little method to reach that pyramid of priorities – even with challenging groups of participants – and guess what? it borrows from algorithmic: roughly halving a set is a lot easier than ordering it absolutely. And halving again is easy …
Solution: build iteratively a pyramid of priorities
Split. Ask the group of participants to split the set of things in two subsets of equal size: the important things, and the more important things. Crucial here: never speak of less or not important things, you might hurt feelings.
Split again. Then focus on the higher priority set – the set of more important things – and ask participants to identify within it the very important things, again halving the set in two subsets of equal size. Iterate again and identify the most important things from the very important ones, the super-absolutely important ones, … slowly building the pyramid of priorities, bottom-up.
Yes, in every iteration there can still be quite some discussions and negotiations, but every iteration ends with an agreement, which is a firm step towards your goal: a common agreement on priorities.
It helps to present it to the group as a clear challenge with clear rules and to clearly timebox every iteration, it will get participants to switch to “game mode” and perform the task with open minds. Also don’t explain to them that the goal of the exercise is to build a pyramid, because everyone will merely focus on his top thing. Simply tell them that “now has come the time to work a bit on priorities” and launch the first halving iteration.
That little prioritization method has done marvels in uneasy group settings. I hope it will help you too.
Tags: design, method, priorities