So I heard a really good question at a meeting recently, which (with a touch of poetic licence) I’ll set out as follows:

“We seem to be talking about all sorts of different things at the moment, such as ‘Agile’ and ‘Systems Thinking’…this can be quite confusing (and/or frustrating)…can we be clear as to what we are doing?”

The question nicely highlights the problem with giving something a label, and of having multiple labels ‘out there’ all at the same time.

Most ‘things with a label’ in the world of organisational change relate to a specific philosophy, with defined methods, and a collection of associated tools and techniques. Perhaps they arose from a seminal business article (e.g. in the Harvard Business Review) or ‘meeting of minds’ (e.g. at a conference) …which got turned into a best-selling book…which became a movement…and then a healthy¹ consulting revenue stream.

People often say that “we are doing [name of current thing]”, with some becoming quite fanatical in its application.

Conversely, some will (properly) argue that the philosophy is the important bit…but they are often (usually?) still trying to ‘implement’ it…which doesn’t make much sense (see intervention bit near the end).

Consider, compare and contrast

So, the two labels in the quote above are ‘Agile’ and ‘Systems Thinking’. Let’s examine them a bit:

---

Agile:

In the beginning…: Computing is a relatively new phenomenon, well at least in terms of human years. (If you believe in evolution then) we’ve been roaming around this planet as Homo Sapiens for roughly 300,000 years…but the first computer that could store and run programs didn’t get built until around 70 years ago².

Early computer programming efforts borrowed the existing thinking derived from the mature discipline of engineering – such as up-front customer requirements, robust planning and estimates, detailed documented specifications and ‘sign offs’, and clear stages and processes within.

However, around the 1990’s the use of such a ‘heavyweight’ approach (often referred to as ‘waterfall’) was becoming a big problem: software development projects were taking many years from start to delivery and regularly didn’t achieve what was actually required…and were often un-useable and even scrapped!

The new science/art of software development was clearly different to a classical engineering project, in two particular ways:

– Dynamic: the customer/ worker/ user environment is constantly changing…what you needed today may be quite different tomorrow; and

– Emergent: ‘an answer’ isn’t (and usually can’t be) known ‘up front’…because what is desirable and possible is constantly evolving.

---

What is ‘Agile’ and where did it come from? Software engineers were getting frustrated with the situation and, rather than sitting on their hands, were experimenting with doing things differently, to make their work more timely and responsive to actual needs. A whole bunch of (so called) ‘lightweight’ software development ideas were being tried.

A group of software development ‘thought leaders’ began collaborating. A seminal moment occurred in 2001 when they met (at Snowbird, Utah) to discuss the lightweight software development methods that had been developed so far.

Together, they published a ‘Manifesto for Agile³ Software Development’. This short and concise document⁴ proposes four values and twelve principles

…and that’s it!

Some things to note: It was explicitly about software development. There were no methods, no tools, and no techniques mentioned…and if you read the values and principles, then there’s a lot to like within. In fact, (I think that) it would be hard to objectively argue with them.

---

And so where did ‘Agile’ go, and what has it become? I’ll start this bit by putting up a diagram to express how I see it:

The starting point (green box) is the software development values and principles (a.k.a ‘The Agile Manifesto’). This then feeds into a whole bunch of potential methods, which include:

– some that already existed and were then aligned and further developed; and

– new methods that have since been derived.

As such, in ‘Agile Manifesto’ terms, there aren’t right or wrong methods – what matters is whether they fit, and are carried out in accordance, with the values and principles.

If we go below methods, we can get to a whole set of techniques that people use. Many of these techniques may be used across multiple methods…and that’s fine. But, again, the important bit is how they are being used. For example: anyone can do a ‘stand-up’⁵ …but it’s not much good if I ‘commanded and controlled’ my way through it.

“A fool with a tool is still a fool” (Grady Booch)

(If you want to get a good understanding of the important difference between techniques, methods, and principles then please read my earlier post ‘Depths of Transformation’ that uses another (related) label of ‘Lean’ to explain.)

And so, at this point, you can imagine that we’ve got lots of different teams working towards constantly delivering useful software in a timely manner, and each such team will have arrived at a method (and set of techniques) that works for them. Nice.

The next thing that happened was the desire, usually within large ‘IT shops’ to co-ordinate all this (now labelled as) ‘Agile’ work together into a portfolio…and we get the birth of approaches⁶ aiming to scale the method – to align and co-ordinate all those agile teams. It sounds like a reasonable thing to do but there’s a big risk here: such attempts at scaling can obliterate the simplicity, add top-down hierarchy and cause inflexibility and confusion…all things that the Agile Manifesto was trying to cut through….and putting the well-intended ‘Agile’ label in jeopardy.

Further, the ‘Agile’ label, having been created for the specifics of software development, has been pushing its boundaries to become more generalised. Those that (might be said to) ‘love the label’ are applying it to wider areas, such as project management and product development.

And yet further, the word ‘Agile’ is being used to describe an even higher aspiration for business agility…which is taking us to a literal dictionary definition:

“Agile: Able to move quickly and easily. Synonyms: nimble, alert.” (Oxford Dictionary)

Now, whilst this might be a commendable (and valuable) aim, it’s a long way from (just) software development. As such, it definitely needs to come back to (i.e. be grounded in)  philosophy rather than methods and techniques.

Right, so that’s a short trip around ‘Agile’….moving on to:

---

System Thinking:

What is ‘Systems Thinking’? Unlike ‘Agile’ (or its relation ‘Lean’⁷), there wasn’t a seminal moment when people sat around in a meeting and invented/ derived something and labelled it as ‘Systems Thinking’. There isn’t some ‘central body’ that (might attempt to) define and regulate it….however there have been a number of (what I would term) ‘Systems Thinking’ giants over the years.

Rather, ‘Systems Thinking’ is a discipline (heavily based in the fields of science and logic) that has been developing over hundreds (if not thousands) of years, sometimes splitting into new fields, sometimes coming back together again.

“Systems Thinking is a discipline for seeing wholes rather than parts, for seeing patterns of change rather than static snapshots, and for understanding the subtle interconnectedness that gives living systems their unique character.” (Peter Senge)

It’s about a shift of mind from seeing problems as caused by someone or something ‘out there’ – to seeing the role that our actions (and inactions) have in creating the problems that we experience.

(If you want a bit of a Systems Thinking history lesson then please read my earlier post ‘Hard, Soft or Laminated?’)

---

“Er, okay Steve…that’s about as clear as mud…so what does it actually involve?

 Well, put simply, it is about:

• understanding what is meant by a system⁸, and the implications that flow from this;
• observing how a system behaves, over time, to better understand:
  • how it actually works;
  • whether it is stable or changing; and therefore
  • what interventions may be beneficial, when considered against the system’s purpose
• understanding how human beings think (rationally…and irrationally);
• designing intervention experiments, towards the system’s purpose; and
• measuring whether, and how these interventions alter the system (for better or worse) and therefore whether to attempt to amplify or dampen them.

 Here’s another nice ‘Systems Thinking’ definition:

“a disciplined approach for examining problems more completely and accurately before acting. It allows us to ask better questions before jumping to conclusions.” (thesystemsthinker.com)

---

What habits need to be learned and practised to enable ‘Systems Thinking’?

I’ve deliberately used the word ‘habits’ rather than ‘skills’ as they mean different things. I’ve also held back from talking about methods and techniques.

It wouldn’t be right (in my view) to say that person X is a systems thinker and person Y is not.

Systems’ thinking is something for each and every one of us to work on….which is a nice link to the Waters Foundation’s one-page poster⁹ setting out (with useful pictures) the ‘Habits of a Systems Thinker’…go on, have a quick look – it’s very good.

These habits:

• can (and should) be used in any and every setting, whether at work or home, and with regards to society or our environment…and everywhere in-between; and
• are lifelong practises, to be constantly explored, matured and extended.

In this sense, it doesn’t make sense to say “we are ‘doing’ Systems Thinking here”…rather, it’s a journey.

Commonality

I’d argue that ‘Agile’ and ‘Systems Thinking’ are two very different things, and it’s a bit like comparing apples and oranges.

If I absolutely had to link them together then I quite like this diagram because:

• ‘Agile’ began as being about improving software development;
• ‘Lean’ began as being about improving value streams (from customer need to its satisfaction)…where software might be a useful enabling component within this; and
• ‘Systems Thinking’ is about navigating through, and improving our whole world…where (true) ‘Lean’ and ‘Agile’ thinking fit very well within this endeavour.

In fact, the extension of the meaning and usage of the ‘Agile’ label from its software development roots outwards kind of shows that it was all about the foundational system thinking.

Intervention

I shouldn’t end this post without making a comment about intervention.

You can want the philosophy behind ‘Agile’, ‘Lean’….[and the next label] but you’ll only truly move towards it when you understand about how to intervene successfully.

I’ve written a fair bit about this¹⁰ so I won’t repeat it here…but I will say that it’s not about (attempting to) do things to people, it is about helping people discover, experiment and learn for themselves….just give them a clear purpose and conducive environment to do so.

“People don’t resist change, they resist being changed” (Scholtes)

You don’t ‘implement’ Systems Thinking…you constantly learn about, and question, your thinking, whilst experimenting towards a system’s (customer) purpose.

To close

I started this post using the word ‘label’…because a label can become really problematic¹¹. Here’s a great quote that (hopefully) puts labels into perspective:

“Don’t call it anything: If it has a name, then people, including you, will waste time arguing about what ‘it’ is and isn’t… but

Call it something: otherwise nobody can ever talk about.” (Thinkpurpose.com)

i.e. when thinking about labelling something, you are ‘damned if you do and damned if you don’t’.

Footnotes:

1. Healthy – I mean large 🙂

2. Computers: If you want a history of the term ‘computer’ and the dates of various advances in computing then see this informative webpage

3. The informal use of the word ‘lightweight’ got given the label ‘Agile’.

4. The Agile manifesto can be found here

5. Stand-up: A regular (e.g. daily) meeting where team members have a collaborative conversation about what they’ve done towards the current goal, what they are doing next and any impediments preventing them from making progress. It’s called a stand up because it is intended as a short meeting (hence people usually stand).

6. Scaling methods: Two well-known methods are called SAFe (Scaled Agile Framework) and LeSS (Large Scale Scrum). There are others.

7. Lean: I mention Lean because it may be seen as a parallel (and related) development to ‘Agile’. The ‘Lean’ label came about from the study of how Toyota were making high quality cars in a highly efficient manner.

8. Definition of a system: “a network of inter-dependant components that work together to try to accomplish the aim [purpose] of the system” (Deming)

9. Habits poster: It’s worth printing out and putting on your wall…and getting into the habit 🙂 of looking at.

 10. Intervention: Here’s an earlier post that should assist ‘What do germs have to do with modern management?’

 11. Misuse of Labels: If someone attempts to justify prescribing a specific tool or technique by saying ‘this is Agile’ or ‘this is ‘Systems Thinking’ then I hope that you can politely point out that this is unlikely to be the case. A tool/ technique could be useful…but not if you are unclear as to why it is being used or if it is being forced upon you.