How Does Your Team Make Decisions?

I recently attended a talk by James Priest on the topic of Sociocracy 3.0, a collection of sociocratic patterns and practices for helping to steer and evolve organisations. At the heart of Sociocracy 3.0 is the concept of Consent Decision Making. It was discussion of this concept that got me thinking about how we work towards decisions in agile teams, the difficulties we experience and whether it’s time for a shift in how we think and work – a shift away from traditional consensus based decision making and towards a sociocratic consent based model.

I’ve seen many agile teams experience something which James Priest expressed as decision making by endurance. Teams locked in discussion, seemingly forever, in a quest to reach agreement on how to proceed or how to approach a particular problem.  At best this can be tiring and frustrating, at worst it can be completely ineffective as teams look to minimise conflict in order to derive a consensus decision, giving rise to groupthink. Difficult and potentially valuable discussions are often dodged for the sake of coming to faster and easier group agreement.

Many agile teams describe themselves as consensus driven, they’ll even adopt tools such as fist of five voting.  Indeed, Jean Tabaka (2006) lists consensus driven decision making as one of the characteristics that makes up a high performing team. It’s almost a given, even in the face of the issues above, that a consensus based model is the ideal way for teams to make decisions.

There’s another key issue that comes from consensus based thinking and one which is perhaps particularly worrying for agile teams. A decision making model based on consensus works towards agreement by the majority of the group. Innovation, on the other hand, often comes from the minority, with those willing to question the status quo and think about things in new ways. Striving for consensus arguably marginalises innovative thinking in favour of minimising disruption and going with the flow.

Consent decision making moves a team from a space of making decisions based on what is generally agreed to be acceptable to a model of only doing things if there is deemed to be no good reason not to do them. In other words it hands supremacy back to reason where a team works to decide not to do something only if it’s harmful to the flow of value.

Such an approach draws on the collective intelligence of the group, with the action of deliberately seeking objections helping to harvest information and identify misunderstandings early. It’s act that brings the team together, helps them to develop a shared understanding and to build an increased sense of accountability and engagement around their decisions. Consent decision making also keeps things moving forwards, avoiding the dreaded decision making by endurance, and aims to treat decisions as experiments. Those experiments should be good enough for now and safe enough to try, a tenet that supports the team’s ability to fail fast, to continuously learn and to pivot and adapt in response to that learning – their ability to be agile.

Key to enabling such a mechanism is the concept of equivalence. Equivalence is the state of being equivalent, having equal value and standing. In consent based decision making this means that everyone affected by a decision has the power to withdraw consent based on reasoned objection. Any team member has the power to raise an objection if they believe that what is proposed stands in the way of a more effective satisfaction of the driver. So how would this work in practice? Sociocracy 3.0 gives us a five step consent decision making process:

1. Present proposal (Driver)
2. Quick response and clarifying questions  (is the proposal understood?)
3. Harvest objections (reasons not to follow proposal)
4. Integrate wisdom (amend proposal as necessary)
5. Test proposal, succeed, fail, celebrate!

Of course, this process needs to be carefully facilitated, ensuring a practical balance between equivalence and effectiveness and keeping the focus on the values of the team rather than those of individuals.

This five step process moves us towards the sociocratic principle of conscious collaboration. Rather than being unconsciously pulled along into suboptimal and under-considered decisions we’re now working together, from a position of equivalence, consciously searching for objections and seeking out decisions that are good enough for now and safe enough to try.

Is this something that could benefit your team? I’ll let you decide that for yourselves.

Hosting an Agile Meetup with Liz Keogh

So, I've been a bit quiet on the blogging front recently. I do however intend to 'reactivate' myself, and that starts now with this post describing an agile event we recently hosted at our works campus.

Last night we were pleased to welcome the Kanban Coaching Exchange for their monthly meetup. The speaker for the evening was Liz Keogh. Liz is always pushing the boundaries of Agile thinking and so we knew we were in for an interesting and thought-provoking presentation. As with all of Liz’s presentations there was a rich mix of information and ideas, so I’ve summarised some of the key points below.

The focus of the presentation was on the Cynefin framework, a practical application of complexity theory, and how we might utilise that to better think about complexity in our own projects. As part of that we would also look at key Agile tools such as Feature Injection, Deliberate Discovery and Real Options to help us understand how we might work to embrace and handle that complexity.

Liz framed the introduction of the Cynefin framework with the notion that all projects have risk. “If a project has no risks, don’t do it”, on the premise that there should always be something new to discover and deliver. That risk can exist in various states, as illustrated by the domains of Cynefin:

Simple (Where things are obvious)
Complicated (Where things are predictable but still require expertise)
Complex (Where out comes emerge and we learn by doing)
Chaotic (A state of accident and emergency)
Disorder (Not knowing what domain dominates)

The characteristics of each domain were discussed along with an illustration of the dynamic relationship between them, for example, the catasrophic boundary between Simple and Chaotic, where complacency can lead to failure.

Different levels of graded complexity were then presented from 5 (nobody has ever done it) through to 1 (Everybody knows how to do it). These were then illustrated in the context of Cynefin, using the framework to understand the domains in which the different risk levels sit, with the most common forms usually sitting across the Complicated and Complex domains. With that in mind Liz then ran us through some key Agile tools which can be used to work with complexity and risk; Feature Injection, Deliberate Discovery and Real Options. These are tools which have been emerging from the world of Behaviour Driven Development in recent years so it was really interesting to see Liz’s latest views on them.

Feature Injection

Feature Injection, in line with emerging practices such as Impact Mapping, is a practice designed to enable us to derive scope from goals, all linked back to an overall vision. This is a practice which I've been trying to use in some of my projects so I thought it was particularly valuable to get a clear summary of the Feature Injection hierarchy:

Vision – The value of the project
Goal – What’s needed to go live
Capabilities – What’s needed to achieve a business outcome
Feature – User interface component which enables a capability
Story – A slice through a feature to enable faster feedback
Scenarios – An example of how the system will be used

Essentially then we can use Feature Injection to break down a project, embrace uncertainty and risk whilst ensuring that we continue to map back to value.

Deliberate Discovery

We then moved onto the importance of discovery within handling risk. The three tenets of Deliberate Discovery were illustrated:

 -Assume ignorance – there are things we don’t know
 -Assume second order ignorance – there are things we don’t know that we don’t know
 -Optimise for discovery

Essentially, when thinking about priorities in a project we can optimise for discovery by taking a risk-driven approach. This can be reflected in backlogs by making them high-level and risk-first.

Real Options

We then briefly looked at Real Options and it’s three tenets:

 -Options have value
 -Options expire
 -Never commit early unless you know why

Understanding the options we have available, the value attached to them and understanding the impact of early commitment is something else we can use to help understand and deal with complexity and risk.

Short Shorts. The Key to Product Owner Success.

An effective and capable Product Owner is key for any successful Scrum project.

So what do we look for in a great Product Owner?
- Product expertise
- Vision
- Decisiveness
- Experience
- Flexibility
- Works well with developers
- Focused
- Responsive
- Practical
- Great collaborator
- Great communicator

I see all of these things as important in making up a Product Owner that can drive a project towards the realisation of  value. There is however one thing that's arguably more important than any of the above and that's a pair of shorts as modelled below by @brightsweb.

Maybe it has something to do with the re-routing of the blood supply to the brain. I'm not sure, I'll leave that to the scientists out there. All I know is: Short shorts. The're the key to success.

Note: The picture was taken in 2012.