The dangers of self-organising teams
This blog post seeks to answer the following questions
How might driving improvements at the team level cause problems?
What is Systems Thinking, and how will it change the improvement approach?
What is a “self-organising” team?
What impact does Systems Thinking have on self-organisation?
An example problem
Let’s say we send in an improvements specialist to improve a Scrum team’s delivery predictability. The management team is concerned that the team often runs late, which impacts the client relationship team and overall customer satisfaction.
How might driving improvements at the team level cause problems?
Introducing the analysis technique
Before systems thinking arrived, people focused on understanding and improving things by breaking them into parts. This is known as the traditional analysis technique:
1) Taking apart each component part of a system (i.e. team/department)
2) Seek to understand it
3) Then reassembling the parts to understand the whole system
Another way of looking at this is to analyse and improve separate departments or functions such as marketing, client support, sales, etc. The reason these functions exist can be a reflection of the complexity of the roles and jobs required within these areas. The ideal of every person in an organisation doing all of these jobs well simply isn’t realistic. Therefore, we tend to have different people accountable for each area, who are tasked with monitoring success and making improvements. A hierarchical team is then created that performs a specific function.
How the analysis technique plays out
The improvement specialist visits the Scrum team. They discuss an integration team that is constantly asking for requirements clarity, which is slowing them down. Then, further to this, they complain that the integration team is taking too long to do end-to-end testing. The team wants to take complete control and cut out most of these activities. The specialist meets with the integration test team to find out where they keep their tests and what they look like.
The specialist recommendations are drafted as follows:
1) The integration test team are an inefficient team, causing hand-offs and delays and should be bypassed
2) The software team will take responsibility for all testing and release on their own
3) A session will be held to hand over all current end-to-end testing from the integration team
4) An evaluation of the tests will be undertaken to reduce the number of tests to fit the risk profile of the change going out
Does this sound good to you?
What is Systems Thinking, and how will it change the improvement approach?
The systemic way of looking at things, known as synthetic thinking, takes the opposite approach to analytical thinking, where we start by breaking things into parts to understand them; here, we are seeking to build a holistic view. It seeks to understand the relationship between the teams.
Containers and sub-systems
Let’s begin by introducing some new words:
1) The container - this is the wider organisational structure
2) The sub-system - this is a team within the organisational structure
3) Inputs - each team will have a set of inputs from other parts of the organisation
4) Outputs - each team will have outputs it produces that may be used by other parts of the organisation
Here’s a simple example below with the Software Delivery Team as a container and two Scrum teams as sub-systems:
Synthetic thinking and how it plays out
Synthetic thinking has the following steps (these come from Dr. Russell Ackoff):
1) **Identify the container system** - Start by identifying what system this is a part of. With this small part of the system, we look for its container (the wider organisational structure).
The specialist speaks with the software team and discovers they are part of a large delivery structure within the department:
2) **Understand the container system** - Seek to understand the behaviour of the container system. The specialist discovers:
The Software Delivery Team are responsible for the day-to-day progress management of the Scrum Teams and unblocking any issues they have
They also work with the other Software Delivery Team to co-ordinate software releases
The Department is responsible for the overall product strategy and delivery of a roadmap to clients
3) **Understand how the container and part relate** - Finally, seek to identify how the sub-system fits within the container system. The specialist then sees how the delivery team gets their work (inputs) and who they give their work to (outputs). This the the current company process:
i) A senior analyst in the Software Delivery Team breaks down high-level requirements and gives them to the Scrum teams
ii) The Scrum Teams work through the requirements and create the software
iii) As they are developed, the Integration test team go to the Scrum teams, trying to understand their requirements and write end-to-end tests. They are also looking for any impact between the work each Scrum Team is doing.
iv) When a Scrum team is finished, the integration team run their tests and reports back on process flow issues or bugs
v) The Integration test team ensure the software is working, taking into account the other Software Delivery Team’s changes
vi) When ready, the Integration test team work with the sales team and client relationship team to skill them up to be ready for public release
Why does this matter?
When we want to make changes, we can evaluate their impact on the whole system. We would break the last two steps if we take our previous recommendations. These may be of no value to the Scrum Team, or they may not understand them well.
Russell L. Ackoff, a pioneer in the field of systems thinking, put it like this:
"In general, [most folks] do not understand that improvement in the performance of parts of a system taken separately may not, and usually does not, improve performance of the system as a whole. In fact, it may make system performance worse or even destroy it.”
We can now recommend wholesale changes that improve our delivery setup. Perhaps the Scrum Team would take on more early end-to-end tests, or they could help identify dependencies with the other teams.
What is a “self-organising” team?
The Scrum Guide defines it like this:
"Self-organising teams choose how best to accomplish their work, rather than being directed by others outside the team."
“Development Teams are structured and empowered by the organization to organize and manage their own work."
“Self-managing, meaning they internally decide who does what, when, and how”.
What impact does Systems Thinking have on self-organisation?
Hopefully, you can now answer this. If you take an analytical approach to self-organisation, you will ignore the container system and potentially damage your organisation. If you have a change that does not impact your team's inputs or outputs, this may be fine. However, it is advisable to understand not only the impact of any change you wish to make but also why the structure is there in the first place.