Gall's Law

Gall's law as the cause of why things work, and especially why they don't work in enterprise transformations

I used to consider myself a Kanban/ Agile practitioner and got a lot of value from the principles and values from these disciplines. Yet with 12 principles1 and 4 values2 in Agile and 4 in Kanban3, had a nagging feeling that there must be something simpler; that single north star which I could use to make decisions easily yet completely aligned with both Agile and Lean. Now I found it.

Gall's law is named after its creator, paediatrician and author John Gall and states that "a complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

Gall is most known for his critique of systems theory in his book «Systematization: how systems work and especially how they fail»

More a rule of thumb, that a physical law, in nutshell it states that attempts to build extremely complicated systems are likely to fail

Does it mean I now call myself a Gall’s law coach? Well, not many job openings for that description — Yet!

From Gall’s law you can per example easily deduce that the best way to create a complex system is therefore not to design it all up front, but let it emerge over time through the creativity, initiative, and ingenuity of the people involved — and what are the enterprises we transform but complex systems, actually complex adaptive systems.

In starting to apply Gall’s law to my agility work, I found several benefits, very close to the foundations of true enterprise agility:

1. It helps organizations to avoid the common pitfall of over-engineering their agile transformation. Organizations often make the mistake of over-engineering their agile transformation. They try to perfect their process before they start, or they try to design their agile transformation from scratch. Gall's Law helps organizations to avoid these mistakes by reminding them that a complex system that works is invariably found to have evolved from a simple system that worked.

2. It helps organizations to focus on delivering value early and often, rather than trying to perfect their agile process. You can clearly see Gall’s law in agility approaches like lean startup. By focusing on building a small thing and proving it works with real costumers you’re ensuring you get to the simplest system that works, which than you can grow using customer feedback into a complex system that works better.

3. It helps organisations to create an environment where creativity and innovation can flourish. One of the corollaries of Galls law is that you can build a complex system that works by composing simpler systems that work. This is what we do in most agility approaches by creating small autonomous teams, each of which can innovate and together can achive greater innovation.

4. It helps organizations to avoid the common mistakes that lead to agile transformations failing. The most common mistake I on the road to agility is to atempt to copy a complex system that worked somewhere else and assume we can teleport an organisation into it. How many companies have tried to copy the Spotify Model and failed? Or attempted a large scale implementation of SAFe to see productivity grind to a halt?

Gall’s law is why the most successful transformations are where we plant the seed of agility in one or more groups and when you see them start to work replicate the model organically throughout the enterprise, always trying to grow agility rather then implement agility.

Golden Question: That is all and nice, but what do yo do on your first day, week, month as a leader guided by Gall’s Law when trying to grow agility in your enterprise?

On the first day, week, or month as a leader guided by Gall's Law, the best thing to do is to start with a working simple system. This could mean starting with a small agile team and letting it grow organically from there. Look around and try to find a pocket of agility mired by complex processes or handovers and simplify their way of work, getting back to basics and building iteration and feedback loops.

The key is to focus on delivering value early and often, rather focus on adopting a process from elsewhere. This will help to create an environment where creativity and innovation can flourish.

1

The 12 principles of agile

  1. Customer satisfaction by early and continuous delivery of valuable software

  2. Welcome changing requirements, even in late development

  3. Working software is delivered frequently (weeks rather than months)

  4. Close, daily collaboration between business people and developers

  5. Projects are built around motivated individuals, who should be trusted

  6. Face-to-face conversation is the best form of communication (co-location)

  7. Working software is the primary measure of progress

  8. Sustainable development, able to maintain a constant pace

  9. Continuous attention to technical excellence and good design

  10. Simplicity—the art of maximizing the amount of work not done—is essential

  11. Best architectures, requirements, and designs emerge from self-organizing teams

  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

2

The 4 values of agile

  1. Individuals and interactions over processes and tools

  2. Working software over comprehensive documentation

  3. Customer collaboration over contract negotiation

  4. Responding to change over following a plan

3

The 4 values of kanban

Visualize the workflow

Limit work in progress

Focus on flow

Make process policies explicit

0 Comments
Authors
Ricardo Liberato
Ian Banner