Week four! This series has now been running for a month! Is it weird to say I’m a little bit proud of myself at the moment? I know I don’t have a ton of readers yet, but even still, it feels good knowing that I can take something I learned and know it enough to the point where I can explain and demonstrate it to someone else. And after all, that is the purpose of keeping this blog: Showing to myself and to anyone watching that I know my stuff, through and through.
As always, you can return to the introductory post to get an overview of all of the protocols, and read forward from there. Or you can go to the Official Core online page and get an overview (and more) over there. If you’ve been following along (Thank you!), then read on. This week I’m going to cover three more protocols. They are, in my opinion, some of the most practical ones in the Core set of protocols, and are important to keep things moving fluidly in a given team. More decisions being made earlier helps turnover, and turnover means more gets done. These protocols relate to decision making.
The decider is how the group immediately moves onto results. In the context of Scrum, we used this protocol when we wanted to immediately move on a decision without any sort of meeting beforehand. It’s easy to do: The proposer of an idea states to the group: “I propose X” where X is a concise action to be proposed. “I propose that we check in again at 3:00pm”, for example. The rest of the group – the voters – then vote with their hands in a motion not unlike rock-paper-scissors (thumbs up for yes, thumbs down for no, and support is a flat hand). Voters who absolutely will not accept the proposal must say so and if this occurs, the proposal is withdrawn immediately. The proposer then counts the votes. The object of the Decider is to get everyone on board, so the proposer should use the resolution protocol on any who responded “No” in order to get their votes to change to Yes or Support. If this cannot be done (or if it’s not “worth it” to do so), then the proposal is also withdrawn. In other words, everyone must either support the proposal, or accept it, but nobody should be voting “No” when the proposal is accepted and carried on.
There’s a few commitments to keep in mind here – more so than any other, in my opinion – because the Decider is a way of immediately moving on decisions with as little discussion as possible. There should only be one item proposed at a time, and all should remain present. Full attention should be given to a proposal, and one should only speak when he/she either is the proposer or directed to speak by the proposer. As with so many other protocols, any reasons for voting as you do should be kept to yourself, and in the interest of responsibly disclosing what you know (yet another commitment), you should reveal immediately when you know you are an absolute no – AND be ready to propose a better solution. One should never hassle or argue with a No or an Absolute No vote – use the Resolution Protocol in the case of the former, and ask for a better idea in the case of the latter. Any decision reached should be actively supported by everyone, and like the Pass or Check Out you should only declare yourself an Absolute No with discretion and as infrequently as possible.
Of note – the Decider protocol works best in small groups. Back in class, we used groups of five. In this context, only those who genuinely care about the proposal at hand (either positively or negatively) should be a part of the decider process. To make larger decisions requiring more people, break into subgroups, and have those subgroups report to represent the whole.
When a Decider has a small minority of No’s, then the Resolution protocol is called for. Simply ask each outlier (“no” voter) “What will it take to get you in?” At which point the outlier offers a precise modification which it will take to get him or her to change their vote. The proposer can either adopt the change, or withdraw the proposal. This continues for each and every outlier. If the changes are simple, then a simple “eye” check is enough to make sure everyone else is still in. If the changes are complex, then the proposer must withdraw the proposal and submit a new one to the group. As before, the outlier should NOT explain his reason for voting or anything other than what it will take to get him in. In fact, the Core even recommends interrupting the outlier by repeating the question “What will it take to get you in?”
The perfection game is an idea aggregation. It is ideal for improving something you’ve created. To use this protocol, the “Perfectee” presents he or she has created for perfection. Then, the “Perfector” rates the value of the object or creation on a scale of 1-10 based NOT on how good it is, but on how much the value the perfector believes he or she can add. The perfector then follows with a short list of qualities which were exemplary and/or should be amplified. Then the perfector offers improvements to the performance or object so that he or should would rate it a ten. For example: “Your script for this scene is a 5. I really enjoyed the banter between the mother and father and the dynamic of their relationship. To make it a ten, I would add dialogue to the son for comedic relief.”
Remember, the idea is not that a 5 or even a 1 means that the perfector dislikes the thing up for perfection. It simply means that they feel it can be improved. In the instance above, adding the indicated dialogue would double the value of you the script, or in the case of a rating of 1, would increase it’s value ten-fold. As for commitments, the perfector should remain positive, and only rate based on how much improvement is possible. A rating of 10 means you cannot think of a single way to improve the thing being perfected.
We’re almost there! One more week to go! The protocols this week are some of the most useful ones for making decisions and improving the direction of the team. I especially like using the Perfection Game to help generate improvements to an existing idea and even pare them down to it’s core best features. It can be seen as almost the inverse of the “Yes, and!” innovation game (which you can read about in this short explanatory post by Lare Lekeman, a professional scrum trainer/coach) and is an incredibly useful tool for really understanding what makes a given idea work, and how to improve it. As for the Decider, I grouped it with the perfection game because it is a tool for really getting a team moving and really biasing your behaviors toward action – a core commitment to the protocols to begin with. All in the interest of keeping your team agile!
See you next week for the final chapter!
– Chris Prunotto