[Krishan Mathis]

The other day we had a discussion about the best way to introduce the Viable System Module to a manager. The idea came up that you can avoid resistance by not mentioning VSM at all, but just pointing out the advantages and then simply introducing the elements. I don’t think that can work. It may look promising at first, but an idea without a name has no chance of sticking in someone’s mind or being accepted into the discourse of a group.

I have some experience of having tried this approach unsuccessfully with the introduction of agile to teams and organizations. I had less resistance to overcome, that’s true, but the team usually stopped using Agile before I had closed the door behind me.

• So what can you do?
• Start with the benefits
• Clearly define the field in which you are operating. This includes naming the essential elements of VSM
• Not sinking into the mire of in-group argumentation. I think it’s far too easy, and I’ve noticed this in myself too, even though I haven’t been part of the VSM community that long
• Stay connected. That means not setting up opposites, but pointing out the parallels and similarities with other methods and definitely avoiding coming along with a golden hammer that can solve all problems.
  and no, not to fall into the trap of telling a pleasing story “from the field”. I’m tired of finding the same example companies in a lot of management literature (airport books that you can read while waiting for a flight) that have to provide material for all kinds of arguments using the same mechanisms.

I started with a simple introduction: A One-Minute Introduction on what the VSM is about. This is by no means the last version – just calling for feedback and improvement proposals.

 

[judith-hennemann]

Krishan, the one-minute-introduction is so helpful, as it points out the manifold benefits of the VSM!

I occurs to me… some of the text could probably be put in a rather common language. We could minimize general systems theory language and focus on just little, but well considered VSM specific vocabulary instead, such as operations, environment, the 5 levels of steering, complexity as variety.(For instance: organizational units/functions instead of systems components)

Guiding principle: Be true to the chosen thinking model while preventing intellectual distance to the business.

[Krishan Mathis]

Interesting idea – and valuable objectives.

The reason I hesitate to follow this route is my experience with convincing people of the advantages of Scrum and Agile.

I started the same way: doing agile without talking about it. And failed 100 percent: Scrum did not become part of the discourse, not to speak about culture. My colleagues accepted the advantage, but I (nominal team lead, not Scrum Master) was the only driver (because I was the only person with a mental model aka plan).

I failed also with the opposite approach: you have to do this, because Scrum says … (with the implication: or else you will burn in hell). I was alone with my belief.

What I am trying to achieve in the current version is this:

1. start with the advantages
2. use common vocabulary as an introduction,
3. immediately followed by the VSM vocabulary
4. followed by an optional explanation of the principles behind the rule

The gap between step 2 and step 3 must be as small as possible.

Maybe there is room for another type of publication: I have some note on a illustrated guide, a little bit like the “Flight Level” book. In that context, I can go even further and show a user journey with personas, e.g. the early history of a startup , how it runs into turbulences and how ut discovers the world beyond agile and SAFe …

[Author]

Posts