Cynefin Framework: Should ‘Scrum Everywhere’ be a thing?

We love Scrum here at ProQuest.

Well… ‘love’ could be overstating things. We embrace Scrum because it is an incredibly simple framework based on some very deep thinking, which allows us to successfully engage with our customers through an Agile paradigm. It also provides a container for our customers to understand Agility and the mindset supporting it. But why should they? Is this about us, or them?

It’s about both. We feel that an Agile approach to delivering Salesforce solutions is optimal, and that the roles and events (or ‘ceremonies’) prescribed by Scrum serve their purpose very well.

For our customers, Scrum provides enough ‘Agile structure’ for them to hold onto, particularly if this is their first encounter with an Agile delivery organisation.

So, what is the Cynefin Framework? And is Agile Scrum? And is Scrum Agile? In a world where even your grandma is running a Personal Kanban wall at home, let’s clear up a couple of things:

1. Agile is not Scrum is not Agile is not Scrum is not… do you see where I’m going, here? Agile is set of values and principles captured in a manifesto to help guide us toward better software development, better organisational structures and better customer outcomes.
2. Scrum is a product development framework that existed long before the Agile Manifesto was written, but played a significant part in the manifesto’s definition. It is, arguably, the simplest framework to make the Agile Values and Principles tangible.

So we should just use Scrum everywhere, all of the time. Right? Not necessarily. This is where the Cynefin Framework can help us to understand where Scrum is really fit for purpose, and explains why ProQuesters are such big fans.

Cynefin

The Cynefin Framework was developed in 1999 by Welsh management consultant and knowledge management expert, Dave Snowden. Cynefin (Ki-NEV-in) is a Welsh word that can be broadly understood as ‘habitat’ or a place of being, and within the framework, we find five domains: obvious, complicated, complex, chaotic, and disorder. Disorder is in fact the unlabeled, central zone in between each of the other four domains. Each domain is designed to help us identify the environment we are operating in and the ‘right’ way to respond to a challenge.

In recent years, the Scrum community has taken to Cynefin as means of understanding and explaining why Scrum seems to work so well for many product creation / software development initiatives - and it all comes down to complexity.

As my colleague Giovanna Rojas has blogged,

“A high level of unknowns and volatility is the sweet spot for Scrum, as we can use an empirical process to figure things out as we go and keep improving on what we learn…”

Complex problems can only really be dealt with using empiricism, which leads us to the Complex domain in Cynefin. In this domain is we must accept ‘unknown unknowns’, which are inherently unplannable and must be explored via experimentation. Here we must probe (try something - a Sprint), sense (understand the outcome - Sprint Review) and respond (plan what to do next - Retro and Sprint Planning).

Joseph Pelrine, Europe’s first Certified ScrumMaster and Trainer has stated that ‘it becomes clear that the apply-inspect-adapt loop [of Scrum] is nothing else than the probe-sense-response cycle used in the Cynefin method for dealing with issues in complex domains.’

So, if Scrum belongs in Complexity, what about the other five Cynefin domains? What do we do if we find ourselves there? Can we use Scrum?

Let’s walk through the domains in a counterclockwise direction, starting with Obvious.

Obvious

In the Obvious domain, we would employ ‘Best Practice’. I.e., the product we create or problem we face is so clear and constrained that almost anyone could respond with simple instruction. It only needs a checklist to be followed. There would be no value in structuring a response based on Scrum roles and ceremonies. In fact, it would only add overhead and confusion. Traditional, predictive project management or sequential product development (‘Waterfall’) is best placed here, as there will be no novelty - we’ll just do what we already know works.

Complicated

Complicated implies that the ‘right’ solution requires expertise, perhaps via specialist assistance or advice. The ‘known unknowns’ can be surfaced through sensing and analysing. This may require teamwork or cooperation, but does not need nor warrant Scrum. We don’t need collaboration and are not exploring in this domain. There is no emergence.

Complex

Complex is the domain of ‘unknown unknowns’, in which most software development initiatives occur.  Within Cynefin, the implication is that we must test the waters, analyse the outcomes and adapt our next move based on the knowledge created and feedback received. Scrum predominantly resides here and reaps the benefits of small development cycles (Sprints) to contain the generation of this knowledge. The customer (Product Owner) is then very well positioned to reconsider what the most valuable thing to do next may be.

Chaotic

If we find ourselves in a Chaotic domain, we have no choice but to act as quickly as possible to make our way back (clockwise) toward the Complex domain. We need to ‘do something’ that can help us achieve this, then analyse the next most important step and keep moving. We cannot indulge in experimentation to generate knowledge - so Scrum is largely inappropriate - we need to survive!

Disorder

In a state of Disorder, we are lost. Cynefin is effectively a ‘sense making’ framework, and if we cannot make sense of the environment we are in we will remain in disorder. We need immediate data to make this determination, and can then move to the most appropriate domain aligned to the activity required. It could be any of them. Scrum is not likely to help us as disorder is unbounded - there are not even ‘loose constraints’ to guide us.

So, we now understand how the Cynefin Framework can allow us to make sense of our environment, and perhaps better understand Scrum’s applicability to what we do.

For ProQuest, the Salesforce solutions we develop with our customers are invariably surfaced in complex circumstances. Having moved through a project Discovery phase, even after an MVP has been delivered and validated, our solutions must continue to emerge to meet our customers’ ongoing, changing needs. Scrum provides a structure for an iterative and incremental approach, which is understandable to customers and hugely beneficial to our projects.

In an ideal project, Scrum would actually allow us to ‘push clockwise’ and straddle the Complex and Complicated domains of Cynefin, as we establish patterns, grow understanding and new information becomes shared knowledge.

References

• http://www.scrumguides.org/scrum-guide.html
• http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
• http://agilemanifesto.org/
• http://www.personalkanban.com/pk/
• http://cognitive-edge.com/
• Pelrine, Joseph: On Understanding Software Agility—A Social Complexity Point Of View E:CO Issue Vol. 13 Nos. 1-2 2011 pp. 26-37 http://www.metaprog.com/downloads/ECO.pdf