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.