For agile at scale, use actionable principles instead

by

It seems the battleground where agile consulting companies are trying to win something has moved to the “scaling” domain: what methods/frameworks/tools/… could we use to bring agility to larger organisations. The topic is fascinating and important, but the answers we’re getting from the market are, in most cases, pretty disappointing, as many “solutions” seem designed to sell services rather than create actual agility.

The scaling market is full of proposals that are often very comprehensive “bodies of knowledge”, with ideas often contradicting each other and all claiming to “work” when applied in practice.

From my perspective as an external observer, I recognise that many of what are usually called “frameworks” for scaling are based on some experiences and embed critical assumptions.

In a sense, they offer an example model of how an agile organisation at scale could work. Still, they also provide more detailed advice on implementing such an organisation, usually with little explanation of the thinking process that led to them.

We could shrug our shoulders and notice that these frameworks are models and, as it is commonly known, “all models are wrong; some are useful”. While this is true, it is also true that every model comes with assumptions and limitations, and often, in these bodies of knowledge, these are not clearly stated and, possibly, in some cases, deliberately ignored.

We (= Colin Bird, Simon Roberts, Matt Roadnight, Ian B. Olsen and I) soon understood that, instead of creating another framework, there is a lot of value in exploring these assumptions and limitations and understanding how they promote or limit an agile organisation. We started focusing on “Principles”.

Why Principles?

According to the Collins dictionary, “A principle is a general belief that you have about the way you should behave, which influences your behaviour” (https://www.collinsdictionary.com/dictionary/english/principle) and “Scientific principles are general scientific laws which explain how something happens or works”. The key word here is “general”, i.e. a principle is not trying to define in detail how things should work but rather express the main ideas and give guidance.

This is very different than rules. According to the same dictionary, they are “[…] instructions that tell you what you are allowed to do and what you are not allowed to do.”

In our initial discussions, we noticed that most scaling “frameworks” define “rules”, but most have less to say about the underlying principles.

And as we started to identify the fundamental principles of scaling, we realised there are different types of principles…

What Principles?

What is the difference between a Principle and a Rule? Is there an overlap between the two?

Let’s start with one of the most famous principles in the Agile world: “Individuals and Interactions over Processes and Tools”. While this is listed as one of the Values of the Agile Manifesto, it expresses a “general belief” and, as such, it is actually a Principle. And it describes a very universal “truth” that, if accepted, guides towards agility. Note: strictly speaking, in maths, this is called a postulate, i.e. an axiom, an assumption that is assumed to be true and that is used to build a theory upon.

While we love this Value/Principle, it has a major implementational problem: what do I do to promote more individuals and interactions “over” processes and tools”?

SA Principles Continuum 1

It can be said that “Individuals and Interactions over Processes and Tools” is a very abstract principle. Inspiring, fundamental for agility, yet not very actionable.

Let’s go in the opposite direction: a team might set a “rule” that says they will run their Daily Scrum every day at 9 in room 3.25 and that everybody must attend. It’s very actionable for them, but it might be a useless rule for the nearby team. Actionable in one case but not generic enough to apply to all cases.

We can define abstract and generic principles or more concrete and actionable ones. As the level of concreteness increases, we reach a point where they become patterns and practices.

SA Principles Continuum 2

The more concrete a principle is, the more constrained its scope of applicability. Hence, a body of knowledge that wants to be very concrete will require a long list of “rules” coded to cover all the necessary situations, and it will be more convoluted and difficult to learn and adapt.

Conversely, a more abstract body of knowledge will require a lot of informed thinking and adaptation to become actionable in a particular scenario.

Craig Larman, for example, claims, correctly, that Scrum found a great sweet spot between abstraction and concreteness, and this is its recipe for success: give enough guidance to allow a team to start and also leave enough space for evolution and adaptation to make the process fit the needs of a given problem.

Also, a scaling “concept” can be either more abstract or concrete and, therefore, positioned in this continuum between abstraction and concreteness.

However, we notice that the level of concreteness offered by Scrum is not appropriate if applied to a large organisation. It would make no sense to have a principle that asks leadership to meet every day for 15 minutes, mimicking a Daily Scrum – that would be unhelpfully prescriptive. Instead, we ask leadership to work together to create the conditions for the organisation to succeed, for example, asking them to create a learning organisation, and letting them decide the details of if, when, where and how they meet.

Furthermore, the more concrete our suggestions, the more likely they are to clash with the usually large amount of “principles”, “practices”, and “rules” defined by the organisation. Providing principles that are one step higher on the abstraction ladder results in a more general applicability of the concepts and provides the “why” of this work, which functions as implementational guidance.

What is the right “level” of abstraction?

This is why we have decided to create principles that often are one step or more towards abstraction, to make them more “generic” than what we see in the scaling frameworks but at the same time actionable enough to be useful in practice. This gives the following advantages:

Moving away from implementational details enables an organisation to look, understand, analyse and operate on the big picture. We believe that questions like “How many Product Owners do I need?” or “Why can’t my teams work together?” cannot be answered unless we understand the current organisational situation and the evolutionary direction we want to give to the organisation and the products.

Understanding the underlying principles creates a shared organisational understanding for a healthier discussion on what practices to implement. Very often, people get trained in Agile practices, and then they “deploy” a new process. This can work in a single-team implementation, but at scale, where hundreds of developers and dozens of managers have to work together to create a new organisation, the lack of a shared context and cultural basis for the change can and will cause problems.

Even if you want to use one of the frameworks available on the market, the Principles will provide the necessary contextualisation and understanding of agile at scale to “put meaning” into a scaling framework and adapt it to your environment by either applying the parts that make sense for your organisation or to understand whether the “rules” they propose apply or help find better alternatives.

There will be more coming in the next posts. In the meantime these videos give more details on the work we’re finalising:

Credits to Colin Bird, Simon Roberts, Matt Roadnight and Ian B. Olsen, who co-developed these ideas and a special thanks to Colin Bird for his patience in reviewing these pages… 🙂