Posted on

DECISION RIGHTS AND CULTURE

Culture change is almost automatic when decision rights change

From DANIEL MEZICK

Scrum, Kanban, DevOps. Etc. All are best viewed as a pre-fabricated systems of decision rights.

Scrum is a good example. The roles, artifacts and events defined in Scrum are typically implemented fully. But, the rules about decision rights are usually not implemented or honored. This leads to the appearance of “full-on Scrum” to casual observers. But the decision rights by role are modified, or missing.

Implementing Scrum without those decision rights will not get great results, or change your culture for the better.

Example #2: Kanban

Kanban. Same thing. There are specific decision rights defined in Kanban. The Kanban method says that the Team or a representative member of the Team, and the person requesting work, are to discuss the work, at the boundary of the Kanban board. And they are to characterize it by Work Item Type, before adding the work to the queue. Work Item Type also implies “cycle time” which is how long the requester of the work can be expected to wait for it to complete.

Typically, a representative Team member is the one that has the discussion at the boundary, and decides about the assignment of a specific Work Item Type.

Also typically, the dev-Team member has LESS authority overall than the requester of the work does. This can lead to problems: the dev-team member managing the boundary may end up “caving in” and assigning a Work Item Type with a faster cycle time, because that is what the requester pushes for, and wants. This amounts to an override of Kanban decision rights with respect to who owns the decision about what Work Item Type will be assigned.

Kanban implemented like this will not get you great results, or change your culture.

Summing up

Improving value delivery, quality and so on usually involves changes to how decisions are made, and who make them. Aligning changes to decision rights in service to more value delivery usually involves at least some discomfort at first. This is the price of genuine improvement … and genuine culture change… for the better.

Posted on

A DECISION PROTOCOL FOR LARGER GROUPS

How to make collaborative decisions on a proposal in large groups effectively, online and semi-asynchronously

Author: HEIDI ARAYA

I recently was doing a workshop with a large-ish group of people (20+). The group all belonged to the same organization and wanted to improve their (shared) process. To facilitate better and more open conversations, we used breakout rooms with five people. 

We came back to the main room to debrief, but the process changes proposed were complex and needed some thought. We were out of time, so we adjourned, and I collated the information on the board into themes and started digesting what I had heard in the breakout rooms, in the main room, and from the sticky notes. 

I decided to write up the proposal in long-form based on the feedback so it was easily readable by all (not just sticky notes). 

After I wrote the proposal out, I was trying to gauge a way where the teams could provide input and feedback asynchronously on the proposal and be able to give their opinion on the proposal’s quality. And fist to five is one of my favorite group alignment techniques, so here’s what I came up with as an adaptation. Maybe it can help you.

(CLICK IMAGE TO EXPAND)

Each team room gets to add their sticky notes on what works, what doesn’t work on the proposal. They can gather on their own to review it and when they are done, they can move the slider to where their comfort level is on the proposal. Each time the proposal is iterated on, they can update the slider. The proposal iteration can be done asynchronously from the voting, and each team can provide feedback at a different time (benefits for highly distributed workforces).

Benefits: there is an immediate way we can look at the feedback on what doesn’t work, see where it aligns, and update the proposal accordingly. 

The initial proposal can be done collaboratively as in my workshop, but it doesn’t have to be. Anyone can put a proposal forward, and the group can iterate on it in this way.

Five Option Collaborative Vote (FOV) 

Here is the verbiage I used – you can edit it to your needs. 

Please leave your team’s (or breakout room’s) rating

  1. “We vote NO – we don’t want to work this way and won’t go along with it. We are willing to talk through and give inputs to make the proposal better.”
  2. “We don’t much like this but we’ll go along if others want it. We think there is still work to be done on this proposal, and we left comments.”
  3. “We’re in the middle somewhere. Like some of it, but not all. We left comments on how it could be improved, but they are not deal breakers for us.”
  4. “This is fine. We see the value in it. There are minor things that can be resolved along the way.”
  5. “We like this a lot, we think it’s the best possible decision.”

Early Analysis on this Technique 

Thanks to my friend Daniel Mezick for this feedback and analysis: 

“What’s striking is the fact that this is a decision-rights technique that applies the 5-part FoF gradient to a group level decision. Which means this is a very fine tool for improvement at scale. The fact that the team arrives at a selection of 1 of five choices on their own (how this is achieved being left to them) is especially noteworthy and interesting since it is in fact encouraging self-management of meta-decisions (decisions about decisions) at the team level.” 

Adaptations & Extensions

To get to agreement in a breakout room, I have also used this method: I told people to think of the rating in their head and post it in the chat all at once on the count of three. This seems to work very well to get conversation started and one can come to an agreement through conversation (much like planning poker). 

Conclusion

I think this method can help distributed teams create new ways of working and collaborate around group decisions whilst not having to be in the same meeting all at the same time. 

Feel free to modify and adapt, would love to know about it. Please do attribute the source.

Published under the CC-BY-SA-40 license: