Public Group
Active 3 months, 2 weeks ago
Group Leadership
- Group Administrators
-
Resources and discussions around the Viable System Model
Introducing VSM without mentioning VSM?
- This topic has 2 replies, 2 voices, and was last updated 10 months, 2 weeks ago by
.
- Posts
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.
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.
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:
- start with the advantages
- use common vocabulary as an introduction,
- immediately followed by the VSM vocabulary
- 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 …
- You must be logged in to reply to this topic.