But their relationship status is ‘Complicated’

Let's take a look at the first two paragraphs of the Scrum Guide

There it is, twice!

Scrum is a framework for developing, delivering, and sustaining complex products.
Scrum (n): A framework within which people can address complex adaptive problems

In other words, Scrum would be specifically suited to deal with complexity.

But what is it, what does this mean, Complex? And why is Scrum so suitable for dealing with complexity? Let’s dive in!

What is complexity?

In my work as a transformation coach, the first one I speak is usually someone from management. They ask me for advice and coaching to help them adapt the way of working in the organisation. If you ask managers why this old way of working nowadays produces less good results than it used to, one answer prevails, complexity.
Searches on Google for the term VUCA acronym for ‘Volatility, Uncertainty, Complexity and Ambiguity’ have risen exponentially since 2004.
You hear these words during almost every board meeting, presentation of the annual figures or leadership summit.

Complexity seems to have become the cause of all our problems.

• The 2008 crisis caused by junk mortgages? Complexity.
• The war in Syria? Complexity.
• The role of Facebook in the American elections? Complexity.

We know what complexity feels like. But most people don’t know what this actually means. We use words like ‘complicated’ and ‘complex’ interchangeably, as synonyms for everything we don’t understand.

Think about the engine of a car. Do you think it’s complicated or complex? Choose the word that fits best before you read any further.

When you ask this question to a (management) team, about half is ‘complicated’ and the other half is ‘complex’.
The next question I often ask is: Think about traffic, is it complicated or complex?

When I ask this question about one-third votes for complex, another third vote for complicated and the other people start to suspect it is a trick question and keep their hands down.

After this everyone realizes why I ask these questions: We don’t have a common (and good) picture of what these words mean.
Contrary to what many people think, complicated and complex in systems theory are two separate concepts with their own meaning.

The engine of a car is complicated. A complicated system is a causal system, so it is subject to cause and effect. Although an engine has many parts, their interaction with each other is highly predictable. Problems with complicated systems have solutions. This means that a complicated system can, in all fairness, be repaired. It can be solved.
This does not mean that a complicated system cannot be confusing or inaccessible to a layman. On the contrary. If you want to understand a complicated system, such as a car engine or a 3D printer, you need specialist knowledge and experience. Experts can discover patterns in such a system and offer solutions based on tried and tested methods. This is the domain of the mechanic, the watchmaker, the architect and the engineer.

Traffic, on the other hand, is complex. A complex system is not causal. We can formulate well-considered assumptions about what it is likely to do, but we are not sure that they are correct. We can predict the weather, but we can’t control it. Unlike complicated problems, complex problems cannot be “solved”. You can’t control them, but you can try to guide them in the right direction.

This is the domain of the butterfly effect, where a small change can lead to something big, and a big change can hardly do any good. Expertise can be a disadvantage here if it becomes a dogma or blinds us to the uncertainty that is inextricably linked to this situation.

(Talking about traffic, I wrote a separate article about the complexity, methods and best practices to guide this)

Complex systems usually consist of a large number of components that interact with each other.
Think of ants, brain cells or even startups, together they exhibit adaptive behaviour, without the need for a leader or central control.

The relationships and interactions between the components of complex systems are more important than the components themselves.

And these interactions are a source of unpredictable behaviour. If a system surprises you or can surprise you, it may be complex.

• An airplane is complicated. However, what happens between the people on board is complex.
• Building a skyscraper is complicated. Cities are complex.
• Building new user functionalities in a Software package is complicated. To do this in cooperation with marketing, sales and the users themselves is complex.

And look at organisations as one entity. When ten or ten thousand people work together on a mission, what is the nature of that collective? Is it a complicated system that an expert can correct or change based on his knowledge? Or is it a complex system, full of uncertainties and surprises, with which we interact if we want to understand and shape it? You already know the answer, of course. Although many of the activities and outputs of organizations are certainly complicated, the organization itself is complex.

In these kinds of complex environments, you need an organisational model that can deal with a low degree of predictability. A framework that focuses on facilitating interactions and communication between the different elements within that environment.

How does the Scrum-guide give content to its promise to be perfectly fit complex environments?

The Scrum Team
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. — Scrum Guide 2017

By its cross-functional composition, a cluster is created in which people from different roles have to achieve a common goal. By definition, this creates the need to communicate with each other to achieve alignment. To understand each other, to understand the priorities.

Because different talents, knowledge and experiences are brought together in this, it also offers a diversity to be able to quickly respond to changing and difficult to predict circumstances.

Sprint:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. — Scrum Guide 2017

The form of sprints as short time-boxed iterations give the ability to make frequent adjustments and deal with the low level of predictability.

Scrum Events:
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. — Scrum Guide 2017

Because of its design and purpose to make each event a joint inspection and adapt opportunity, and to keep the events lightweight, (the outcome is specifically described. Not the methods by which you reach that outcome) this provides a platform for communication and collaboration that supports interactions and relationships.

The artifacts:
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists. — Scrum Guide 2017
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. — Scrum Guide 2017
An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. — Scrum Guide 2017

Everything in the artifacts, which form the core of communication during the Scrum events, screams to be an opportunity to continuously adjust to changes that a complex environment brings.

Conclusion:

Now that we understand what Complexity really means and how it differs from the concept of Complicated, you probably also see what I see. The promise that Scrum is a framework that provides a basis for dealing with complexity is not hollow.

All the elements that make up the framework support the principles of complexity and with that, it lives up to its promise that was made in the first two paragraphs.

However; the Scrum Guide might live up to its promise to be lightweight and simple to understand, it also warns you that it is difficult to master so.. it’s relationship status is “complicated“ for a reason.

Acknowledgements to Aaron Dignan for the inspiration