The basic structure of an Agile Team
Every Scrum Master, Agile Coach or how ever you call the role of an “Agilist” knows the situation: There is a new team or even a team of teams which wants to learn the new way of working. Usually, there is some sort of a kickoff – the initial meeting to start a new adventure. Since there is never a second chance for the first impression, a kickoff meeting is essential to build the trust in yours skills. Most importantly, it’s about supporting people in understanding their roles and how these roles and the “new” rules of self-organisation are connected. This is also the hardest part of the job of an Agilist.
I want to share a real world example that I used to explain the basics within three minutes. I hope this example would make someones life easier. The context of this exemplary team is an internal service unit which delivers value to “direct neighbors” as well as to every employee in the company.
An Agile Team, simplified with the Viable System Model
How can one create an invitation for a short thinking journey, which explains the WHY, HOW and WHAT of an Agile Team? Additionally I wanted to clarify what are the limits of my role? But more about the second question at the end.
I wanted to use the [[Viable System Model]] as a foundation. Therefore the diagram begins with the (internal) environment. When one starts to understand the surroundings in which a team (or system) is embedded, you are automatically customer centered. Another feature of the Viable System Model are the three basic structures:
Operation (Dev Team)
Management (Product Owner)
Regulation (Agile Coach)
It all ended up in this visualization. An Agile Team as a Viable System:
It shows the essential actors and relationships (loops) of an Agile Team. Each loop contains an incoming and outgoing aspect which helps to describe what is needed to be a “whole”.
It shows an ideal situation in terms of mutual responsibilities and ownership. It shall demonstrate that power is distributed. Agile is a team sport.
Nerd remark: The Agile Coach is not connected to the environment. On this high flight level I really think that‘s how it should be. The Agile Coach in THIS team has the task to enablepeople to interact with the environment. It is not the job of the Agile Coach to manage relations with the environment. This leads directly to the final aspect.
Limits of an Agilist
Lastly, I want to come back to the above mentioned aspect of the limits of an Agilist. As you can see in the diagram, the PO and the Dev Team have the duty to ask for CIP (= Continuous Improvement (Processes)). Only if they “pull”, I can deliver coaching and change for the individual roles and the team as a whole. For sure, I do try to convince them of the Agile advantages by a first hand experience. Usually I do this by solving exactly THOSE problems which always annoyed them. The idea is to give the team the confidence that things TRULY change. The „way for the better“ (Kaizen) is not a fairy tale. Unfortunately, that does not work every time. Sometimes one has to deal with the fact that people don’t engage.
If people really do not want to change and are neglecting the invitation to explore new grounds, then I see only four steps that an Agilist could do:
1. Accept it – the first step as a Reflective Practitioner
2. Reveal the system to itself – the job of mirroring the behavior
3. Escalate it – the „not so nice“ part when you incorporate higher „command“ levels
4. Leave the team – the hardest part. The trick: Do it with a smile and not with anger. See 1.
Therefore: I never carry the dogs to the hunt. That’s my favorite statement when I introduce myself to teams. I want to make clear: It’s up to each and every team member.
PS: As you see CIP is the foundation in my Agile world view. This is anything but new. It is an universal principle, which can be also found in Lean practices or Monozukuri. If you want to learn more about it, read this insightful interview with the honorable Mari Caspari-Furukawa (for the time being available only in German).
PPS: Like always, this diagram is released as CC0 license, formerly known as Public Domain.
3 responses to “An Agile Team as Viable System”
Mapping a team to the VMS is a great idea!
But likening the PO to management… I think – and I sorry to be so blunt – that is a grave mistake and misunderstanding.
To me it’s one of the major fallacies of PO’s to think of themselves as being elevated above the devs in any way whatsoever. It’s the first nail in the coffin of team work.
The PO is just one role in a process producing value. The PO is on eye level with devs. The PO has certain competencies, the devs have certain different competencies. Both roles together are necessary to produce value.
Management on the other hand by definition does not produce value. Management is not part of the operation. Management, well, is management 😉 Which means it’s trying to produce compliance.
Operation on the other hand is focused on value creation. Within the operation the PO might be more of a coordinator than producer. But the PO is not a manager. The simple litmus test: Does the PO have disciplinary power over devs? I haven’t seen that.
All three roles (PO, AC, Dev) are operational roles. At least viewed from the outside. Viewed from the inside – in case the team truly is self-organized – the roles don’t map to the VSM, I’d say. Instead systems above 1 need to be created from the team members. Maybe a dev and a PO are voted to form a sub-team to delineate a value system for the team. But that’s matter of the whole team.
Thanks for your comment. I am copying your points into my reply in order to keep the context.
***
Mapping a team to the VMS is a great idea!
But likening the PO to management… I think – and I sorry to be so blunt – that is a grave mistake and misunderstanding.
***
Well, as I wrote it is a simplification and does not contain the full model. Also it was not the intention to explain the VSM in all details. I had three minutes to catch their attention. Of course I elaborated further aspects – but I do not wanted to tell the full story, but only the intro into a kick off.
***
To me it’s one of the major fallacies of PO’s to think of themselves as being elevated above the devs in any way whatsoever. It’s the first nail in the coffin of team work.
***
Yes. And the _simplified_ diagram should transport this message.
***
The PO is just one role in a process producing value. The PO is on eye level with devs. The PO has certain competencies, the devs have certain different competencies. Both roles together are necessary to produce value.
***
Yes. Everyone in her/his role.
***
Management on the other hand by definition does not produce value. Management is not part of the operation. Management, well, is management 😉 Which means it’s trying to produce compliance.
***
This is to me an ontological discussion which wants to define terms. Therefore this is a separate topic. I think it’s much more. Just to state it: Management is a function and not a role.
***
Operation on the other hand is focused on value creation. Within the operation the PO might be more of a coordinator than producer. But the PO is not a manager. The simple litmus test: Does the PO have disciplinary power over devs? I haven’t seen that.
***
Yes. As I have shown it in the diagram.
***
All three roles (PO, AC, Dev) are operational roles. At least viewed from the outside. Viewed from the inside – in case the team truly is self-organized – the roles don’t map to the VSM, I’d say. Instead systems above 1 need to be created from the team members. Maybe a dev and a PO are voted to form a sub-team to delineate a value system for the team. But that’s matter of the whole team.
***
Again, it is a simplification and not the full story of the VSM. The system levels of strategy & innovation and norms & identity are missing. I did it consciously since the core is to understand the interplay of the roles. There is no top or down. It’s a network.
I hope it made clear which compromises I choose to enable a thinking journey.
[…] In the next video, I will revisit my Viable System Model Canvas and show how you can use this tool for your own purposes. Maybe you are curious to read how an Agile Team could be seen with this example of the Viable System Model. […]