Team Topologies as an organizational pattern language — Part 2
Team First, Stream aligned Teams and Cognitive Load
This is the second part of the transcription of my talk at the Agile Tour Vienna 2023. The first part introducing the ideas of a pattern language and discussing the requirements towards an effective software delivery organization can be found here.
Now is about time to introduce a pattern language that we can apply to design an organization as I have outlined and it is the one proposed in the book “Team Topologies” by Manuel Pais and Matthew Skelton.
Team Topologies is a fancy title - it sounds a bit like mathematics and I have to admit that was what caught my interest immediately.
So here is a definition of topology:
“A topology is the way in which constituent parts (of a system) are interrelated or arranged.”
This is from the Oxford dictionary - so we are looking at the parts of a system and - very important to note - the way how they interact.
And if you look at the subtitle of the book - it seems to exactly help us to achieve our goals.
“Organizing business and technology teams for fast flow”
Sounds promising, doesn’t it?
In this part of the series of articles I will introduce the patterns proposed by the authors and also give a bit of a background on the ideas behind these patterns. I will also note how some of the patterns have been applied in the company I work for, RBI.
So let’s start with our organization. First, we obviously need somebody doing some work 😀.
In the context of Team Topologies, the smallest unit of delivery is a team. The whole pattern language is built up around this basic building block. We call this the “Team first” approach.
Team First
Why is that?
Innovation generally needs some interaction, exchange of ideas in conversation. We benefit from diversity in our thinking and problem solving. And as human beings we benefit from social interactions - not always, I admit, but in general we are happier and more motivated if we have the possibility to share our professional concerns and successes with others.
I am not saying that that a single person can’t achieve great things but in the context of a bigger organization we need to also make sure that there is continuity and common ownership of products.
So the team it is our basic unit of delivery. But to make a team work we need to consider communication within the team. We know that there is a limit for team size that is determined by our capabilities to have meaningful and trustful conversation. Research tells us that this typically is around 7 plus minus two people. Beyond that it will be difficult to maintain this kind of trust that is crucial for close cooperation.
To establish trust needs some time, teams need to work together continuously until they achieve this kind of glueing that is a characteristic of well-performing teams.
The goal is that teams are stable - they don’t need to be static in the sense of never changing but changes should not happen too often. Frequent team changes will prohibit that teams are achieving the level of trust that is needed for high performance.
Just as a side note: if you take the team first approach seriously, it will also have impact on a companies reward policies. It means that it is always the team that is rewarded for any achievements, not the individual. But also this is not something new, it was proposed already by many including W.E. Deming in the early 80ies.
When we have established our team as the core delivery unit we need to think really hard how work is distributed to these teams.
The Team Topologies authors come up with four fundamental team types and I will start with the first and most important one, the Stream Aligned Teams.
Stream Aligned Teams
Again, we need to define a bit of terminology here. A stream is a continuous flow of work aligned to a business domain. “Stream aligned” means that the team is aligned to a single valuable stream of work.
This might be a product or a service, a single set of features or something similar. It is important that the team can deliver customer value as quickly and independently from others as possible.
The “independent” part is crucial because you remember, the team should deliver fast and often and dependencies are one of the main factors that hold teams back and slow them down. The cost and effort of alignment is potentially huge, so we want to avoid this.
If you are part of a bigger organization then it is probably impossible to be completely independent as a team but trying to achieve a state of “as independent as possible” makes a lot of sense.
If you want to have independent teams and you have already an existing solution there probably is no way around slicing and dicing your existing system so you can distribute the work to these teams. Doing this is not a trivial task and Team Topologies generally does not help your here. It provides some ideas, though. Concepts of Domain Driven Design can help a lot in finding fracture planes, boundaries where you can split up your system into more independent parts that are not so strongly coupled.
We need to have strong coherence between our system’s architecture and the organizational setup. This is a consequence of Conway’s Law and we always need to keep this in mind.
I mentioned several times already that team independence is important and helps us in achieving flow but is has also some negative consequences. It means that the team needs to do a lot of things on it’s own.
If we are strict and try to avoid dependencies, we have a long list of things a team needs to do: Teams need to understand the business domain, take care of the tool chain, assure quality, provide support and operate and maintain their part of the system. This is a lot of work of all different kinds.
And remember, our teams are small.
It is clear that we may run into problems here.
Team capacity is naturally limited. This is true if we just consider the amount of hours available to the team but as all of you probably will agree the value of our work is hardly measurable in hours spent. Software development teams do cognitive work, things are a bit more complicated.
To get some kind of grasp on the load of the team, the authors of Team Topologies introduced the idea of Team Cognitive Load and it is quite fundamental.
Cognitive Load
The concept of Cognitive Load was introduced in 1988 by the psychologist John Sweller and was developed as part of a theory of learning and it refers to the total amount of mental effort being used in the working memory.
“Cognitive Load is the total amount of mental effort being used in te working memory”
It is a theoretical concept used to understand the cognitive demands placed on a person during various tasks.
So the concepts of cognitive load come from research around how we learn. Why would this be relevant for the delivery of software?
Because we understand software development as a process of experimentation and learning.
As Dave Farley put it:
Software Engineering is a discipline of learning and discovery. We build our learnings and solutions incrementally.
Software delivery and this is also true for maintenance and operations is complex mental work. We as software engineers are not part of a big manufacturing machinery that delivers as many pieces of the same thing as quickly as possible.
We need to experiment, iterate and continuously learn during this process. So I would say it is appropriate to apply learning concepts to the software delivery process as a whole.
Sweller identified three types of cognitive load that can be mapped very well to software engineering.
The first type is called Intrinsic Cognitive Load: This part relates to aspects fundamental to the problem space. Examples would be the knowledge of the programming language, it’s syntax and semantics.
The second type of cognitive load is called Extraneous Cognitive Load. It relates to the environment in which the task is being done. Examples for that would be things like how to configure your system environment or how to deploy your software.
The third type of cognitive load is called Germane Cognitive Load and it is related to aspects of the task that need special attention for learning or high performance. This would include everything that is related to the business specific problems we need to solve.
We can approximately add up all the cognitive loads of all of the team members and thus achieve a overall cognitive load, the Team cognitive load.
It is quite obvious that from a business perspective these types of cognitive load have different value.
We want to reduce the intrinsic and the extraneous cognitive load so the germane cognitive load can take a bigger share of our mental capacity. Remember, this is where the value is. Customers typically don’t care about the complexity of our tool chain, they want to get value from our stream aligned teams.
Stream Aligned Teams need help to shift the distribution of cognitive load, they need a supporting system.
The Team Topologies pattern language provides some guidance how we can achieve this by proposing three types of supporting teams that help stream aligned teams to shift their distribution of cognitive load.
You can build a complete organization based on these teams patterns.
Part three describes the supporting system introduced by the “Team Topologies” pattern language.