Category Archives: Other Stuff

Scrum and VSM v1

Using the viable systems model understand and diagnose issues in Scrum and IT

System 5. Arrgh.

This article will look at Scrum through the lens of a Systems Thinking approach called the Viable Systems Model. Applied to organisation, the Viable Systems Model often feels like well thought out common sense, so the things VSM says may not be a surprise. What may be a surprise is the diagnostic power the VSM has both within and outside the Scrum team . This power makes the learning curve of the VSM worthwhile.

I’ll start looking at a Scrum team as a viable system and follow up this post with a discussion of the members of the Scrum team as viable systems. Finally in a 3rd post I’ll analyse various IT situations I’ve seen using the same tool. This should show the power of the VSM, and the range of situation it can be used in.

All this analysis is released under a Creative Commons License. It would be great to get feedback from both a VSM and Scrum perspective, more examples, and build up a resource.

Context, context, context

It’s worth noting here that application of Systems Thinking is always contextual. If you have a different context to me we’ll not have the same analysis. I’ll be treating this as a learning opportunity, rather than a quest for an uber-analysis that can can applied in any context. (hint: the Uber-analysis doesn’t exist).

I’m assuming you know Scrum and this article is an introduction to the Viable Systems Model, but it should work the other way. I’ll also show how the VSM can be used to diagnose issues with teams and IT in general, It’s a useful aid for Scrum Masters or Agile Coaches when things aren’t quite working. In fact, an Agile Coach, armed with the VSM and a couple of other people systems tools would be pretty formidable.

This power comes from the ability to name things that may be missing and we’d like to improve.

Having a name for things is vital if we want to talk to other people about them. The VSM helps us do this.


Ashby Law of Requisite Variety

The Viable Systems Model is Ashby’s Law of Requisite Variety applied to organization design. So I’ll really be looking at Scrum at IT issues using Ashby Law of Requisite Variety.

Rather than introducing the VSM academically (there are lots of academic papers that do that) I’ll use it to talk about Scrum, showing why the parts of Scrum work – and giving some general diagnostic advice when things are not working as expected.

Quick introduction to Viable Systems, and the One Weird Trick

Before I start there are a few thing about the Viable Systems Model that I’ll point out. Firstly the model is recursive. Viable systems contain viable systems. So viable teams make up viable organisation units, that make up viable organizations. Viable organization need to exist in viable sectors of the economy or society. A system exists within its environment, and Scrum teams are no different.

The other cool thing about the VSM is that the things we look for are at each recursion are exactly the same as every other recursion. This One Weird Trick makes the VSM easily applicable to lots of different organizations at different levels. The requirements are numbered System 1 to System 5, and there are purposeful communication channels between various parts of the system. There is also the systems environment that may have more than one element.

These parts of a viable system are called System1 (S1) to System5 (S5) , shown in the diagram below. System S3 gets an extra S3*, just because.



The VSM just says that the S1to S5 things need to exist. They can be done by the same person or separate people.

Applied to a Scrum team

Scrum, as described in the Scrum Guide is good example of a general way to organize to produce working software in complex situations.
Analysis of a Scrum Team as a Viable System shows what each part of Scrum is doing, and shows where there are assumptions about the sort of problem you are solving that may cause issues, and areas where other skills and approaches may be required.

The Scrum team and its customer

A Scrum teams customers are the people whose needs are met by the software that team writes. This can either be a group outside of the organisation like a small mobile game dev company that releases code straight to paying customers, or a team whose output needs to be integrated with the output of other teams in the organisation to provide value. This is important, but the implications come later.

The communication between the customer and the team is managed by the Product Owner or PO . The PO reduces the variety of requests coming from the customer, to something the team can cope with. In the other direction, the value from the team is increased by the Scrum Master, the Dev Team and the Product Owner putting together Sprint Goals that will meet needs in the best way.



Of course the developers can talk directly to the customer, but this is in the context of delivering value that has already been discussed and agreed.

Providing value VSM System 1

The parts of a Viable System that provide value to the customer/environment, is called the System 1. In a Scrum team there are 5 +/- 2 parts of this. The System 1’s need their output co-ordinating by a System 2.

The output of the team may need integrating into the output of other teams. These may be financial, marketing, physical product production, legal, regulatory or other Scrum teams. (oooh, maybe even other waterfall teams…) I’ll look at this with the VSM in another post, but for now, assume the Scrum Team provides value to the customer/environment directly.

Co-ordination VSM System 2

Co-ordinating system 1’s into a cohesive output is mainly the job of the Scrum Master. The SM makes sure that the daily standups, retrospecitves, and sprint planning all occur. The Scrum Masters job is also to remove any impediments to the team, reducing the variety of problems they need to deal with.
The team is also expected to self organise to deliver the Sprint Goal. Scrum mandates daily standups where the SM creates a space where it is safe to make mistakes and learn. This skills required to do this are outside the scope of the Scrum guide, but are vital to a well functioning team. System 2 is S2 in the triangle in the following diagram.

Getting resources and managing delivery -VSM Resource Bargain and Audit

VSM requires an organisation to have a resource bargain, where resources (Like a factory, employees and raw materials) are converted into something of value. The bargain (ie 1 factory, 20 people, raw materials) needs to be converted into something useful in a particular timeframe (ie 500 products in a week). This is a performance agreement that needs to be agreed and monitored. Scrums is designed to work in more complex environments that factory, so the resource bargain is more complex.



A Scrum team creates value with a team of developers, a Scrum Master, a product owner, IT resources and 2-4 weeks of time. This is a resource bargain with the organisation. The team is given resources in return for delivering value and meeting peoples needs. Because of the short sprint cycles, the resource bargain can be reassesed regularly to see if it is delivering what it promised. This is done at the sprint review, where the output of the sprint is delivered to customers.
The VSM says that the System 1’s need a in depth audit – that is carried out at irregular times. The regular Scrum Review is the closest to this audit, although it is not irregular, and it does not bypass the PO and SM. This means certain organisation anti-patterns may not be detected. In VSM this audit is called System 3*. Done without care this audit can break trust, so leaving it out of any model of the organisation can be disastrous.

Managing the Current Operations VSM System 3

This is where the whole of the the current operations are reviewed for effectiveness, so there is the output of all of the previous sprint goals, the current sprint goal, and future goals. There are decisions here made about the whole deliverable of value to the customer, including bug fixes, and any operational resources required.
In VSM this is the System 3. In Scrum the team develops new features. Scrum covers a some of this, but the output of the team may be passed to an operations / devops team. A lot of this is out of scope of Scrum. A Devops team would need to be a Viable System, so could be designed and diagnosed with VSM.

If the output of the Scrum team is integrated with the output of other teams to provide value, then the overall output will be assessed by it’s own System3. ie the performance of the whole product.

Thinking about the Future VSM System 4

The decision to continue developing the software, to stop developing software if progress is too slow, or it’s not providing value needs to be made. The team also needs to look ahead to see what the future may hold, and how the team will continue to be viable.

The Identity of the Team VSM System 5

The identity of the team is its purpose. A Scrum team would align to the values in the Agile Manifeto, and also to the Scrum Guide. Its purpose could be “meeting needs and delivering value using Scrum”. Agendashift  says  “We deliver <what> to >whom> so that <why it matters>”.

The activities it does (S1s) affects its identity more than what the system says its identity is. So if the team isn’t doing Scrum it isn’t a Scrum team. A team can’t just call itself Agile and use the right words. It need to behave in a way congruent with the agile manifesto , and this behaviour is supported by referring to the identity in System 5.

The identity of the team – the decision to use Scrum and be agile is owned both by the actions of the developers and people in the next System level up (if it exists), who have decided that Agile teams are required, and can integrate the work of the Scrum team into a product with value.

In following posts I’ll look at the next recursion up and down from the Scrum, looking at a developer, and the next level up. If you’re a SM or PO I’d be interested in modelling those roles too, but I’d need an expert in these domains to do this properly.

Links to further reading resources TBC

There are some in depth books by Stafford Beer and Patrick Hoverstadt covering the VSM.

I’ve personally found the VSM resources on the web to be generally quite poor.

Here are some good web resources.

Trevor Hilder into to VSM

Tom Graves Pervasives and the VSM algedonic link




Strengths and Clean Language Workshop #3

The Strengths and Clean Language workshop met weekly for a year, and then had 2 months off. Meeting again I was full of ideas that seemed to fit really easily. The workshop was Mike, Tomasz, Sarah, David and Richard.

I found a draft of this post from early 2107, and published it in December 2017.

We started off with the quote from Miles Davis. I’d been at a SCiO Systems Thinking Open Day, and I stole this image from Arthur Battram. Arthur’s presentation on the links between Miles Davis, Jazz and complexity and systems thinking was delightful. And he has a jazz hat. Arthur’s book is great too.

Organisational Metaphors

On the train home from SCiO I was reading Images of Organisations, by Gareth Morgan. This book discusses how Organisations, can be seen through the lens of eight different metaphors at the same time. Each metaphor will reveal and hide different behaviours and systems.

Gareth’s book is referenced in Open University Systems courses, O’Reilly’s Cloud Technology book Architecting Microservices, on Clean Language coaching websites, and is one of’s recommended books. Too say that it’s influence is wide and varied is an understatement. It’s also usually less than £3 on ebay.

I’ll borrow Venkatesh’s overview of the metaphors that Gareth Morgan uses from

Organization as Machine: This is the most simplistic metaphor, and is the foundation of Taylorism. Any geometrically structuralist approach also falls into this category, which is why I have little patience for people who use words/phrases like top down, bottom-up, centralized, decentralized and so forth, without realizing how narrow their view of organizations is. The entire mainstream Michael-Porter view of business is within this metaphor.
Organization as Organism: This is a slightly richer metaphor and suggests such ideas as “organizational DNA,” birth, maturity and death, and so forth. I really like this one a LOT, and have so much to say about it that I haven’t said anything yet. I even bought a domain name ( to develop my ideas on this topic separately. Maybe one day I’ll do at least a summary here.

I introduced Gareth’s metaphors and the Miles Davis quote.

We’re heroes in our own story

Sarah commented ‘We’re all heroes in our own story. The way we look at things makes sense of thing so that we’re central in the story, and our actions make sense. Our (Clifton) Strengths may influence the story we tell. It story may also influence the metaphors we use to  understand and talk about the organisations we’re part of.’ Hero’s of our own story is something we’ll come back to. And as Miles says, if you understood my story, you’d be me….

Sarah also noted how she is interested in the perspectives of some metaphors, like the political system metaphor, but doesn’t like to get involved in politics, it wears you out.

We (well I) jumped to clean language here. I’m particularly interested in Clean Scoping Questions. The scoping questions are used to see if a Clean Language approach, usually revealing uncomfortable behaviour patterns, is wanted by the coaching client. Rather than face their own patterns, the client may just want a “diversity certificate”, or similar.

A quick overview is

What do you want to happen?

What needs to happen so that <answer to what you want to happen> is automatic?

What is happening right now?

The answer to what is happening right now usually contains unhelpful patterns of behaviour. Before looking at the patterns, we talked about how asking the question “What needs to happen so that what you want is automatic”, could be (uncleanly) asked in the context of Gareth Morgans metaphors.

So, “thinking about the situation using the brain metaphor, what do you want to happen?”

Or “thinking about the situation using the organism metaphor, what would you see and hear when <what you want to happen> is happening”.

I think we may try these questions in the group to see what occurs.

As a group we’re all familiar with the unhelpful reflex patterns of behaviour described by Barry Oshry, and the alternative ‘balcony’ behaviours that we can use if we see the reflexive patterns in time.

In her book “From Contempt to Curiosity” Caitlin Walker describes using the Karpman Drama triangle to describe a set on unhelpful behaviours “Persecutor, Victim and Rescuer” that are seen in Clean Scoping. These patterns map really well onto Barry’s TOP / MIDDLE / BOTTOM behaviours we describe in Balcony and Basement terms.

Sarah suggested that people’s Clifton Strengths may influence the organisational metaphor they prefer to use – they’ll see the world in a way that sees their strengths positively.

There were some similarities between the Karpman Drama triangle behaviours, and the basement behaviours of TOP/MIDDLE/BOTTOM, Richard noted an overlay of balcony behaviours onto the Drama Triangle, making it a hexagon. The drama triangle seems to describe behaviour more easily the TOP/MIDDLE/BOTTOM, but Barry’s Model is a lot richer.

Each of the patterns on the Karpman Drama Triangle maps to Basement behaviour of TOP’s MIDDLEs and BOTTOMs. We noted how you can see Victim, Persecutor and Rescuer behaviour in TOP, MIDDLES and BOTTOMs.

A TOP who take responsibility because they feel they are removing their help from someone is engaging in victim behaviour. MIDDLES who side with one person over the other may be PERSECUTING one side of the other, before moving to victim and rescuing.

We had a good workshop, getting new approaches that increase our variety, allowing us to describe more situations and behaviours.

If you understood everything we said, you’d be us.





Systems thinking in one cartoon

Systems thinking is daunting. There is a lot to learn, and there is always someone to cheerfully point out when you’ve missed a bit.

Bill Watterson

I first saw this cartoon in 1992, and I cut it out and stuck it to a picture frame that followed me about for the next 15 years. It reminded me to make sure that I understood why I was choosing to do things and to look for other perspectives.

It’s all about your purpose and seeing the big picture. Bill Watterson is a genius for making it simple and funny.


Breaking the problem down into manageable chunks is a boundary decision. Hobbs sees it as classic reductionism and sets up the punchline, with Calvin is asking “Is this problem within the boundary of what I care about or not”. So he’s not solving the problem, but dissolving the problem by thinking about the bigger picture, from the perspective of a 6-year-old.

Taking a problem that looks impossible and reimagining it from different perspectives, ideally so the impossible part goes away is a common systems thinking approach.

Unlike Calvin, I spend most of my spare time reading entire chapters of books.