Team Knowledge Model

In brief

Feature teams have to learn continuously and deliver reliably at the same time. Velocity is no use as a measure of team development.

The model brings the individual flow models of all team members together into one team picture, organized by learning fields.

Four things become visible: how knowledge is distributed, the balance of challenge and skill, knowledge gaps, and progress over time.

The process has six steps and one team workshop. Repeating it after three to six months shows whether the measures are working.

Motivation

Feature teams in large-scale product development face particular demands. Because of the end-to-end perspective and their own responsibility for delivering customer value, feature teams are not only cross-functional, they also work across the entire technology stack. Beyond that it is normal for feature teams to develop and change all components of the system and to keep those components maintainable. Working in unfamiliar or unknown code therefore becomes the normal case. A feature team has to be able to get into new technologies and system components (code) quickly. But understanding customer wishes and the business or technical requirements is a learning process too.

While the activities and the learning that goes with them can be derived from where the team is deployed, the team itself is responsible for the individual learning of its members. Does everyone learn everything, or do they divide the learning fields between them?

Learning in the team and organizing that learning process is therefore an essential task for Scrum and feature teams. There is, however, a constraint that does not make learning any easier for them. In agile project or product development, predictability is highly valued, because it builds the trust of customers and stakeholders. The key metrics for forecasting are the remaining product backlog size and the velocity of the team. For these values to allow genuinely reliable forecasts, it matters that the team velocity does not fluctuate too heavily. It is fatal if the velocity of the team has recently dropped to zero unplanned. In that case the product owner can no longer make reliable forecasts, because the velocity could drop to zero again at any time and deliver nothing.

Once that standard is set, that a team must always deliver something so the organization stays predictable, Scrum and feature teams face the challenge of guaranteeing continuous learning and stable productivity at the same time.

This raises four questions:

• How can we bring individual goals and team goals into line?
• How can we see who is an expert and who needs help?
• How do we keep track of the direction the team is developing in?
• How can we learn new things and be productive at the same time?

For measuring team development, the velocity of the team on its own is about as unsuitable as it gets.

“High performance team” is the buzzword of the agile community and the holy grail of agility. So how do you develop a team into a high performance team, and how do you show that a team has become one? Unfortunately performance is often equated with the delivery speed of the team. Many managers tend to use the velocity KPI to demonstrate team development and to measure or assess the value of the Scrum Master role. That does not work. A rising velocity neither indicates real team development nor directly demonstrates the value of a Scrum Master. On the one hand because a team velocity is always subject to smaller fluctuations (holidays, illness, other unplanned ad hoc work), and on the other because velocity can also rise through individual team members simply working more. Velocity can also be manipulated easily through higher estimates by the team.

A high performance team is not about everyone working faster or working more. It is about team members developing routines that let them use synergies, so that learning and delivering in the team become both more effective and more efficient. The miracle of collaboration: the sum of the team is more than the sum of the individuals. It is about real scaling, about putting the capacity and competence of each team member to best use for the success of the team at any time, for building know-how and for productivity alike.

A team only achieves the ability to scale for real if its members are able to scale themselves, that is, if they can take on several different tasks in the team.

If you take the ability of the team to scale as the basis for team development, four properties can be identified that relate directly to it:

• Scaling potential: how knowledge is distributed, who knows what in the team, and individual potential for learning.
• Scaling status: the balance between challenges and skills.
• Scaling obstacle: knowledge gaps in the team, limits on the team’s scope of work and on building know-how.
• Scaling progress: applied repeatedly, the Team Knowledge Model visualizes the progress of knowledge building and therefore the development of the team.

The scalability of a team is a factor aimed mainly at its performance. But it is hard to imagine people performing at a high level over time if they do not feel good doing it. So it matters just as much to pay attention to the satisfaction, to the happiness of the team members. How do you reconcile high performance and happiness?

Quite simply: work in flow!

What does working in flow mean?

Team development has always been a team task for me, and it should be something the team members experience together. Fortunately, in early 2009 I attended a talk on emotional team states by Joseph Pelrine. Among other things he presented the flow model by Mihály Csíkszentmihályi. Flow, a term that originally comes from sport, is according to Csíkszentmihályi a state in which people work in balance between their own skills and the challenges put to them. In flow we are challenged but not overwhelmed, and that makes people happy.

Flow model after Mihály Csíkszentmihályi Flow model (Mihály Csíkszentmihályi)

In the picture, the state of apathy represents a lack of knowledge and a lack of tasks for the individual. If the challenges exceed the skills, the person is overwhelmed, and over the long term that state can lead to burnout. If, on the other hand, a person cannot use their skills at all, they are under-challenged and may well be bored. Over the long term that can lead to boreout.

We all want to achieve something, to be good at something, so we strive for real mastery, for something we can be proud of. Taking on a demanding challenge and mastering it makes most of us happy. In the model shown, that would mean facing very high challenges and being able to meet them without blockers and interruptions.

In flow you have reached the balance between demanding challenges and your own skills.

Learning at the edge of flow

People learn in very different ways. Learning always means leaving our comfort zone and therefore taking ourselves out of flow. At the edge of flow there are two ways of learning that will hopefully take us out of flow only briefly: learning by doing, and building knowledge up front, through training beforehand, without applying that knowledge in practice straight away.

With learning by doing, the challenges are raised first. The current tasks do exceed your skills, but you dig in, and over time you understand how it works and build knowledge. That eventually brings you back into flow. Many people prefer this way of learning, and there is nothing wrong with it.

Others prefer to acquire the necessary knowledge first before taking on new challenges, through an apprenticeship or simply through a training course. That is also a very good and sensible way of building your own skills. Imagine a doctor taking the learning-by-doing route without a long course of study. So this way of learning is thoroughly useful too.

So there is no right or wrong here. Both ways make sense and both are justified.

Two ways of learning at the edge of flow

It becomes a problem when you no longer get back into flow, when you stay in the red hatched areas, because then the way back to happiness is closed off. In such cases we can observe two negative effects that we may have experienced ourselves or seen in others.

If you do not get back into flow from learning by doing, that is comparable to the Peter principle, which says that everyone is promoted until they reach their level of incompetence. You do not have the necessary skills for the tasks at hand and you are permanently stressed.

If you do not come back from being under-challenged, that is, if you cannot bring your skills to bear at all, it feels like bullying, especially when that state was not your own choice.

Over the long term both extremes are at odds with a healthy way of working. What matters is how quickly you get back into flow. For me a team is a learning community, so it is also a team task to make sure that every member gets the support they need for individual learning and for putting their skills to use. The model above visualizes very nicely where a person currently stands, so measures can be taken to bring that person back into flow.

My subject, though, is team development, so I extended this individual approach to the whole team without losing the reference to individual members. That is how the Team Knowledge Model came about.

It is the responsibility of each individual to help make it possible for every team member to get into flow.

The Team Knowledge Model (TKM)

based on the flow model by Mihály Csíkszentmihályi

In the Team Knowledge Model all individual flow models of the team members are brought together, visualizing the knowledge and the level of challenge experienced at team level.

To give team members better orientation when determining their own current state, I divided the Y axis of challenges and the X axis of skills into three sections each.

Challenges, Y axis

• low: no tasks or simple tasks
• medium: moderately difficult tasks
• high: complex tasks

The division of learners into three states, Shu-Ha-Ri, comes from the martial art of Aikido, where Shu corresponds to the beginner, Ha to the advanced practitioner and Ri to the master. Alistair Cockburn transferred these terms into the agile world as levels of learning. I now use that division in the Team Knowledge Model.

Skills, X axis

• Shu: I know nothing about it, or only the basics, and can complete tasks by following instructions.
• Ha: I manage quite well, but now and then I need help with complicated tasks.
• Ri: I know the subject excellently, I can handle complex tasks on my own and can even teach others in this area.

Once all results are transferred into the shared model, you have the Team Knowledge Model.

Initially completed Team Knowledge Model Example: an initially completed Team Knowledge Model, based on the flow model by Mihály Csíkszentmihályi

The model visualizes:

• how knowledge is distributed in the team (scaling potential)
• the balance between challenges and skills (scaling status)
• possible knowledge gaps in the team (scaling obstacle)
• the development of knowledge over time (scaling progress)

Six steps and one workshop

The sequence is quite simple and involves the following activities:

1. Selecting the learning fields for the team
2. Completing the individual models
3. Transferring all individual results into the team model with the whole team
4. Analyzing the result
5. Deciding the measures for building knowledge and distributing tasks accordingly
6. Running follow-up models

Activities 3 to 5 are carried out together in a dedicated team workshop. The sections below describe the activities in detail.

1. Selecting the learning fields

So the team can plan and steer how it builds know-how, it makes sense to define the shared learning fields first. These can be derived from the concrete tasks of the team on the one hand, and on the other the choice follows the interests of the team members.

The learning fields should sit in the business (domain know-how in the example) and/or technical context of the team. If many learning fields follow from the work context, or are even prescribed to the team from outside, it matters that at least one learning field can be chosen freely by the team. That raises motivation and identification with the learning process itself.

Learning fields are not learning goals, and it does not make sense to attach goals to them when they are chosen, because that would ignore the starting point of each individual and of the team as a whole.

Examples of learning fields

Business

• Work processes, sales or purchasing processes
• Insurance processes, algorithms, policies
• Telecommunications: standards, protocols
• Tax, bookkeeping, accounting
• All kinds of areas of law
• Financial processes

Whatever lies in the economic interest of the company.

Technical

• Programming skills: Java, Angular, C++
• Design principles: OOD, S.O.L.I.D., GRASP
• Technologies: Azure, AWS, AI, big data
• Continuous integration (CI/CD)
• Development practices: ATDD, TDD, BDD
• Refinement and test practices

Whatever the team needs to do its work.

The examples shown are taken mainly from software product development. The TKM can be applied to any team context, though. A football team identifies weaknesses in tactics, in defending or in fitness levels. Project managers and account managers want to learn more about marketing or customer acquisition. A team of managers might want to learn orthogonal self-management, classic management methods or leadership practices.

2. The individual model: assessing your own skills

Individual flow models

It starts with self-assessment. What know-how do I have? How big are my challenges?

First each team member completes their personal knowledge model on their own. It matters that they really do this alone and without reference to their colleagues. That way, when the individual data is transferred into the team model later, possible misjudgments (self-perception versus how others see it) can be surfaced and discussed.

Whether you first place yourself on the know-how axis, Shu-Ha-Ri, and then assess the size of the challenges, or the other way round, is up to each person. This is not about showing off, it is about giving an honest self-assessment.

It helps to establish: am I currently above flow in this knowledge domain, that is overwhelmed? Or are things going well and I am in flow? Or is my knowledge not being used at all and I am below flow in this area? That assessment goes on the Y axis (high, medium, low).

On the X axis you assess your skills in the respective area. Am I more of a beginner, with basic knowledge, needing a lot of time or help to solve problems? Then Shu is the right band. Or do I manage quite well, rarely need help, but still run into knowledge gaps now and then? Then Ha is appropriate. If I see myself as an expert in this area and know it well enough that I need no help myself and can even teach others, Ri is the right rating.

3. The team start model: seeing how knowledge is distributed

Bringing the individual models together

The completed Team Knowledge Model shows what know-how is available to the team and whether team members are currently struggling with their tasks.

In the dedicated team workshop on the TKM, the individual models are first brought together into the shared TKM. One learning field at a time, the crosses from every team member are transferred into the team model.

It helps if a neutral person, the Scrum Master for example, is shown the results by each team member and then transfers them into the team TKM in front of everyone. This is an important aspect, because the procedure makes possible misjudgments transparent. Once all individual crosses for a learning field have been transferred, a circle is drawn around all crosses for that field. The process is then repeated with the next learning field until all fields are in the team model. Then the interpretation and analysis of the result begins.

4. Analyzing the model: motivating people to build knowledge

Team Knowledge Model in analysis

We begin with a visual analysis. Do we have large or rather small circles, and is their center towards the bottom left or the top right?

In the example model on the left, the circles in the learning fields coding and domain know-how show high diversity (large circles). There are team members who are experts in these domains, but there are beginners too. One member feels somewhat overwhelmed by the domain knowledge and another cannot really apply their coding know-how at all.

In these two learning fields the team can plan and pursue its learning progress on its own with well-chosen measures. Everything necessary seems to be present in the team.

The learning field testing looks different. Here the circle is small, so the know-how in the team on this subject is fairly homogeneous, but above all the center of the blue circle sits at the bottom left. That means the team does not have enough expertise in testing. So there is a need to bring external know-how into the team.

The task in the workshop is to interpret the TKM as a team and to discuss what it shows. If team members are outside flow, that is fine to begin with. It may well be their preferred way of learning. What matters is that the team talks about how that member gets back into flow as quickly as possible.

Once the team has reached a shared understanding of the current state of the team and of its individual members, it works out the next steps, that is, the measures the team will take to bring members back into flow quickly where needed.

5. Measures: planning how knowledge is built

Once the team understands who brings which skills and who may be overwhelmed, the measures to take are not that hard to identify. Many teams find this part of the workshop the easiest.

It is a team task to bring members back into flow as quickly as possible. If a member is overwhelmed, the team should help by supporting them in building knowledge, for instance by having an expert in the team take the coach role and work with that member (the coachee) on their tasks. The coachee then builds knowledge faster and finds it easier to get back into flow.

If, on the other hand, a member is under-challenged, the simplest way is to involve them in the active work in that area, implementing backlog items, to bring them back into flow. It is equally possible to use that member as a coach for colleagues who want to develop in that learning field.

If expert knowledge is missing in the team, though, the team should try to organize help, for example through workshops with external experts, or by sending individual members to relevant training and having them pass the knowledge on afterwards. In a scaled setting, working intensively together with a team that has the expertise, during refinements, business analysis and design work, can also help to build knowledge in the desired learning field quickly.

Some helpful methods and practices for building knowledge and extending the skills of the team:

• Pair and mob programming
• Coding dojos
• Setting up communities of practice, for learning across teams
• Pair learning, pair reading
• Reserving dedicated time slots for individual learning
• Setting up forums, for example an agile design forum to introduce the S.O.L.I.D. design principles and the GRASP principles
• Introducing ATDD and TDD, which improves understanding of the domain, the tests and the code

The ideas listed here relate primarily to teams in software development. However, a great many of these methods and practices can be transferred to other areas and adapted accordingly.

6. Follow-up models: showing learning progress

Follow-up TKM showing learning progress

Regular workshops to create follow-up TKMs help the team see whether the measures are really working.

After three, six or nine months it is worth repeating the TKM process. The first step, selecting the learning fields, can of course be skipped at first. You repeat steps two, three and four.

Then you compare the current TKM with the previous one. Has there been progress, have individual members fallen behind? If so, why, is that fine, or is something wrong here? Real progress in the team should be celebrated. In my observation, comparing the models with demonstrated progress has a very positive effect on the mood of the team and on its motivation to take on new things.

The follow-up workshops focus on the most recently created TKM. In discussion the team may find that it has built enough know-how in a learning field and that no further team activity is needed there. In that case the team can add a new learning field. A new TKM is then created for it, together with the results of the learning fields that remain in use. That model then serves as the comparison model at the next update of the TKM.

After analyzing the new TKM the team will of course agree on measures and plan how it builds knowledge for the next learning period.

A learning vision instead of goals

TKM as a learning vision

Does everyone in the team have to be able to do everything? No.

It cannot be the goal that everyone has to become an expert in every learning field. That would disregard the individuality and independence of a team member, and learning would feel like coercion. The picture is merely a vision: anyone can develop in that direction and would be supported in doing so. If it really is the case that all team members are experts in one or more learning fields, the team can open up new learning fields in the next TKM.

One team, eight months apart

TKM of a team, eight months apart TKM of a team, carried out eight months apart

The TKM of a real team shown here has the initial model on the left, created two months after the team was formed and updated eight months later (right).

At the start of the collaboration (left), many team members had only beginner knowledge or none at all in the various learning fields. What the large circles also show, though, is that in every field there were members with expert knowledge who were able to support or train their colleagues accordingly.

The TKM on the right shows clearly that there has been progress in all learning fields. Many have broadened their knowledge considerably and now work on the corresponding tasks. Some now notice that they even take on tasks that are actually beyond their skills. Learning by doing is evidently happening here. There is one exception, though: the topic CM Meta/Access has not improved, and the expertise of one colleague even appears to have got worse. In the analysis the team could explain this, because it had taken on no tasks in that area of the product since the first TKM. So there was nothing for the members to work on and therefore nothing to learn. The expert explained that other teams had developed that component further and that he no longer knew it as well.

In the first Team Knowledge Model workshop, the team had decided on the measures listed below for building know-how:

• Pair programming
• Ask questions! Meaning there should be no hesitation about it
• Set up your own coding projects and reserve time for them
• A learning day: every team member could use one day in the sprint for learning
• Results of individual learning had to be shared with the team and documented
• A wish list of topics to learn was drawn up
• Every week, in half an hour, tasks and solutions that had been worked out were presented to the team
• A best practice folder was created
• Two colleagues decided to take the SCJP certification together. They read books chapter by chapter and explained things to each other or tested each other

Measures of the team

Nothing motivates like success, and the Team Knowledge Model can show the learning success of a team.

Coaching tips and pitfalls

Quicksand Careful: quicksand!

As with all methods, there are of course a few things outside the method itself to bear in mind with the Team Knowledge Model. Beyond that, I want to point out a few pitfalls in applying the model.

Before working with the Team Knowledge Model, it makes sense to check whether the team will stay together over the longer term. Learning together needs trust and routines, and building those takes time.

It also helps when there is a shared understanding in the team that it is every member’s job to help colleagues develop. Management can support this, for instance by adding an assessment criterion for employees that records what they contributed to the development of their colleagues.

The Team Knowledge Model works excellently in team-building workshops, for example after a team has been newly formed in a self-designing team workshop (see the LeSS Case Study). The TKM can also be used very well in team retrospectives.

A self-assessment process is not an exact science, but the Team Knowledge Model visualizes the know-how present or missing in the team, allows conclusions about the load on team members, and is therefore a good indicator of confidence and mood.

To avoid losing focus in the learning process, no more than six learning fields should be looked at and worked on at the same time.

Putting the TKM up in the team room reminds everyone that measures were agreed and now have to be tackled.

Updating the TKM regularly shows learning and development progress in the team. Nothing is as motivating as success. Visualizing it motivates people to take on new tasks, strengthens confidence and the willingness to take responsibility in the team, and increases the readiness to leave the comfort zone. I recommend repeating it every three, four or six months, depending on need and on the complexity of the learning fields.

Do not write the names of team members next to the crosses in the model. The TKM is internal to the team. The result can be made public and increases transparency, but individual members should not be identifiable. That also prevents managers from misusing the model for team rankings.