Team-Knowledge-Model
Recognize knowledge scatter, Motivate learning, Visualize team development
Indiv. Model Template
Download .pdf
Team Model Template
Download .pdf
Author
Motivation
Feature teams in scaled product development have to meet special requirements. Due to the end-to-end perspective and independent delivery responsibility of a customer value, feature teams are not only cross-functional but also work across the complete technology stack. In addition, it is common for feature teams to develop, change, and maintain all system components. This makes working in foreign or unknown code areas the norm. A feature team must be able to learn new technologies and system components (code) quickly. But understanding customer needs and business or technical requirements is also a learning process.
While the activities and the associated learning can be derived from the future Product Backlog of the team, the team itself is responsible for the individual learning progress of its team members. Do all team members learn everything, or do they divide up particular learning areas?
Therefore, learning as a team and organizing the learning process is an essential task for Scrum- or Feature Teams. However, there is also a constraint that does not simplify learning for the teams. Predictability is a high asset in an agile project or product development because it establishes customer and stakeholder trust. The essential metrics for predictions are, on the one hand, the "remaining product backlog size" and the "velocity" (delivery speed) of the team. To make reliable predictions with these values (Burndown chart), the team's velocity mustn't differ too much. It is fatal if the team's velocity has dropped to zero in the recent past. In this case, the product owner, for example, can no longer make reliable predictions in the future because the team's velocity could then fall back to zero at any time and thus no longer deliver anything.
Suppose this standard is set that a team must consistently deliver something for the organization to remain predictive. In that case, the challenge arises for Scrum and Feature teams to ensure continuous learning and stable productivity simultaneously.
This raises the following questions for Scrum and Feature teams:
- How can we align individual goals and team goals?
- How can we recognize who is an expert and who needs help?
- How do we control the direction in which the team is developing?
- How can we learn new things and be productive at the same time?
- Measuring the team velocity exclusively to track team development processes is inappropriate.
"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 prove that a team has grown into a "High-Performance Team"? Unfortunately, performance is often equated with team delivery velocity. Many managers tend to use the KPI "Velocity" to prove the team development process and measure or evaluate the benefit of the Scrum Master role. However, this is not the case. Neither does an increasing velocity indicate real team development, nor does it directly prove the benefit of a Scrum Master. On the one hand, the velocity of a team is always subject to more minor deviations (e.g., vacation, illness, or other unplanned ad-hoc activities), and on the other hand, the velocity can also increase due to the overtime of individual team members. In addition, the velocity can be easily manipulated by higher team estimates.
A "High Performance Team" is not about everyone working faster or more. It's about team members developing routines that enable them to leverage synergies to make team learning and delivery more effective and efficient. The miracle of collaboration: the sum of the team is greater than the sum of the individuals. It's about true scaling - about using the capacities and competencies of individual team members optimally for team success (know-how building and productivity alike) at all times.
A team can only achieve proper scaling if the team members themselves can scale, i.e., if they can take over different tasks within the team.
If we take the team's ability to scale as the basis for team development, we can identify four characteristics that are directly related to it:
- Scaling potential
The distribution of knowledge, who knows what in the team, and individual learning potentials. - Scaling status
The balance between challenges and skills. - Scaling obstacle
Knowledge gaps of the team, limitations in the work area, and know-how ramp-up of the team. - Scaling progress
If the Team-Knowledge-Model is conducted frequently, it visualizes the progress of knowledge ramp-up and thus the team development.
The team's scalability is one factor that focuses primarily on the team's performance. However, it is hard to imagine that people will sustainably perform at a high level if they do not feel well. Therefore, it is just as important to pay attention to their satisfaction and the team members' feeling of happiness. So how do you reconcile high performance and enjoyment?
Quite simply: work in the flow!
What does it mean to work in flow?
Team development has always been a team task for me and should also be experienced collectively by the team members. Fortunately, at the beginning of 2009, I attended a lecture on emotional team states by Joseph Pelrine. In it, he presented, among other things, the flow model of Mihály Csikszentmihalyi . According to Csikszentmihalyi, the concept of flow, which initially comes from sports, is a state in which people work in balance with their abilities and the challenges they face. In the flow, we are challenged but not overwhelmed, and this makes people happy.
In the upper picture, the state of apathy for the individual represents the lack of knowledge and lack of tasks. If the challenges exceed the abilities, the person is in overload; this state could lead to burnout in the long term. On the other hand, if a person cannot use their skills at all, the person is under-challenged and possibly bored, which could lead to bore out in the long term.
We all want to achieve something. We want to be good at something. We strive for true mastery, something we can be proud of. Taking on and mastering a demanding challenge indeed leads to feelings of happiness for the vast majority of us. In the model shown above, this would mean that we set ourselves very high challenges, but we can do them without blockages and interruptions.
- In the flow, one has achieved the balance between demanding challenges and one's abilities.
Learning at the edge of the flow
People learn in many different ways. Learning also invariably means that we leave our comfort zone and thus take ourselves out of the flow. There are two ways of learning at the edge of the flow that hopefully only take us out of the flow for a short time."Learning by doing", and the initial build-up of knowledge, e.g., through upstream training, but without immediately putting this knowledge to practical use.
With "learning by doing", the challenges are first increased. The current tasks then exceed one's skills, but you dig in, and with time you understand how it works and builds up knowledge. This is how you eventually get back into the flow. Many people prefer this way of learning, and there is nothing wrong with it.
Others prefer to acquire the necessary knowledge for new challenges upfront through appropriate training, e.g., apprenticeship, or simply through training. This is also an excellent and reasonable way of building up one's capabilities. Imagine that a doctor would run through his education with "learning by doing" without sophisticated studies. Not good. So acquiring knowledge might be pretty valuable as well.
So there is no right or wrong in this question, but both ways are reasonable and have their reasons.
However, it becomes problematic if you can no longer get back into the flow. In other words, we remain in the red-shaded areas because then the way back to "happiness" would be denied us.We can observe two adverse effects that we may have experienced ourselves or seen in others in such cases.
If you can't get back into the flow from "learning by doing", this is comparable to the "Peter principle". This states that everyone is promoted until they reach the level of their incapacity. One does not have the necessary skills for the current tasks and is permanently stressed.
If you can't come back from being under-challenged, i.e., you can't use your skills, it feels like mobbing - especially if this state was not chosen by yourself.
In the long term, both extremes contradict a healthy way of working. So, it depends on how quickly you get back into the flow. For me, a team is a learning community. Therefore, it is also the team's task to ensure that each team member receives the necessary support for individual learning and the applicability of their skills. The above model is a great way to visualize where a person is right now and, if necessary, take action to bring that person back into the flow.
However, my topic is team development, and therefore I have extended this individual approach to the whole team without losing the reference to individual team members. This is how the Team Knowledge Model came into being.
- The individual's responsibility is to help enable each team member to get into the flow.
The Team-Knowledge-Model (TKM)
based on the Flow Model of Mihaly Csikszentmihalyi
In the team knowledge model, all individual flow models of the team members are combined, and thus the knowledge and degree of experienced challenges are visualized at the team level.
To give team members a better orientation for determining their current state, I divided the Y-axis of challenges and the X-axis of their capabilities into three sections each.
Scale challenges (Y-axis)
In the team knowledge model, all individual flow models of the team members are combined, and thus the knowledge and degree of experienced challenges are visualized at the team level.
To give team members a better orientation for determining their current state, I divided the Y-axis of challenges and the X-axis of their capabilities into three sections each.
Scale challenges (Y-axis)
In the team knowledge model, all individual flow models of the team members are combined, and thus the knowledge and degree of experienced challenges are visualized at the team level.
To give team members a better orientation for determining their current state, I divided the Y-axis of challenges and the X-axis of their capabilities into three sections each.
Scale challenges (Y-axis)
- low: none or trivial tasks
- medium: medium-difficult tasks
- high: complex tasks
From the martial art of Aikido comes the scale of learners into three statuses: Shu-Ha-Rhi. Where "Shu" corresponds to the beginner, "Ha" to the advanced, and "Rhi" to the master. Dr. Alister Cockburn has introduced these learning levels into the agile community. Meanwhile, I use this classification in the team knowledge model as well.
Scale challenges (X-axis)
- Shu: I know nothing about it, or only basic things can do tasks according to specifications
- Ha: I manage my tasks quite well but need help now and then for complicated tasks
- Rhi: I have excellent knowledge, can handle complex tasks independently, and can even teach others this subject.
based on the Flow Model of Mihaly Csikszentmihalyi
The Team-Knowledge-Model visualizes:
- The distribution of knowledge in the team (scaling potential)
- The balance between challenges and capabilities (scaling status)
- Potential knowledge gaps in the team (scaling obstacle)
- Knowledge development over time (scaling progress)
TKM process
The process is quite simple and includes the following activities:
- Selection of learning fields for the team
- Individual filling of the models
- Transfer all individual results to the team model together with the whole team
- Analysis of the result
- Agree on measures for knowledge building and the corresponding distribution of tasks
- Perform follow-up models
1. Choice of learning fields
The team owns its know-how development process. Therefore, it makes sense to define the shared learning fields first. On the one hand, these can be derived from the specific tasks of the team, and on the other hand, the selection is based on the interests of the team members.
The learning fields should be in the team's professional (domain know-how) and/or technical context. If many learning fields are derived from the work context or even "directed" to the team, it is essential that the team can freely select at least one learning field. This increases motivation and identification with the learning process itself.
Learning fields are no learning goals, nor does it make sense to assign goals when selecting them because that would disregard the starting point of the individuals in the team and the team as a whole.
Some examples of learning fields:
Business
- Work processes, trading- or purchase processes
- Insurance processes, algorithms, policies
- Telecommunication: standards, protocols Standards, Protokolle
- Tax, accounting, bookkeeping
- Diverse areas of law
- Finance processes
Whatever is 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, KI, Big Data…
- Continuous Integration (CI/CD)
- Development practices, ATTD, TDD, BDD…
- Refinement & Test-practices
The examples shown here are primarily taken from software product development. However, the TKM can be applied to all team contexts. A soccer team identifies weaknesses in tactics, defensive behavior, or fitness levels. Project managers and account managers want to learn more about marketing or customer acquisition. A team of managers may wish to learn orthogonal self-leadership, classical management methods, or leadership practices.
2. Individual model: Assessing own competencies
The first step is self-assessment. What know-how do I have? How significant are my challenges?
First, each team member fills out their Knowledge Model alone. The team members must fill it in alone and without reference to their team colleagues. This way, possible misconceptions (self-image vs. external image) can be pointed out and discussed later when transferring the individual data to the team model.
Whether one classifies oneself first in know-how, i.e. on the horizontal level Shu-Ha-Rhi and then evaluates the size of the challenges or vice versa is up to everyone. The point here is not to distinguish oneself but to give an honest self-assessment.
It is helpful to determine whether I am currently above flow in this knowledge domain, i.e., "overwhelmed " mode, whether things are going well and I am in the flow, or whether my knowledge is not being used at all and I am below flow in this domain. This assessment is entered on the Y-axis (high, medium, low).
On the X-axis, on the other hand, you assess your competencies in the respective area. Am I more of a beginner? Do I have basic knowledge and need much time or help to solve problems? Here, the area "Shu" would be selected. Or do I manage quite well, requiring help only rarely, but still encountering some knowledge gaps from time to time, then "Ha" would be appropriate? However, if I consider myself an expert in this area and know so much that I don't need any help but can even teach others in this subject, "Rhi" is the proper classification.
3. The Team Start Model: Recognizing knowledge distribution
The completed Team Knowledge Model (TKM) shows which know-how is available to the team and whether team members are currently struggling with their tasks.
In the dedicated team workshop on TKM, the first step is to merge the individual models into a common TKM. One after the other, the crosses of each team member are transferred to the team model for each learning field.
Here it's recommended that a "neutral" person, e.g., the Scrum Master, is shown the results by each team member and then transfers them to the team TKM in the presence of all. This is essential because possible misjudgments can become transparent through this procedure. Once all individual crosses to a learning field have been transferred, a circle is drawn around all crosses to this learning field. Then the process is repeated with the following learning field until all learning fields have been transferred to the team model. Then the team begins with the interpretation and analysis of the results.
4. Analysis of the model: Motivate knowledge building
We start with visual analysis. Do we have large or small circles? Is their center instead of left down or somewhat right up?
In the example model on the left, the circles in the learning fields "Coding" and the "Domain" know-how show great diversity (big circles). There are team members who are experts in these domains but also beginners. One team member feels a bit overwhelmed with the domain knowledge, and another can't apply his coding know-how.
The team can independently plan and tackle learning progress through clever measures in these two learning fields. Everything necessary for this seems to be available in the team.
The situation is different in the learning field of testing. Here, on the one hand, the circle is small, and thus know-how in the team on the topic is quite similar (homogeneous), but above all, the center of the blue circle is at the bottom left. This means that the team does not have sufficient expertise in the learning field of testing. Therefore, there is a need for action to bring external know-how into the team.
The task in the workshop is to interpret the TKM here in the team and discuss what has been presented. If team members are outside the flow, that's okay for now. It can be the preferred learning model. What is essential is that the team discusses how the team member in question can get back into the flow as quickly as possible.
Once the team has reached a common understanding of the current state of the team and the individual team members, it is time to work out the following steps, i.e., the actions to be taken by the team to get the team members back into the flow quickly, if necessary.
5. Measures: Plan knowledge development
Once the team has understood who is on the team, what skills they bring to the table, and who may be in over their head, the actions to be taken are not that difficult to identify. Many teams often find this part of the workshop the easiest.
The team's task is to bring the team members back into the flow as quickly as possible. If a team member is in "overload", then the team should help by providing support in building up knowledge, e.g., by having an expert in the team (assumes the role of coach) work together with this team member (coachee) on their tasks. In this way, the coachee builds up knowledge more quickly and thus gets back into the flow more easily.
If, on the other hand, a team member is "under-challenged," the easiest way is to involve this team member in active work (implementation of backlog items) in this area to bring the team member back into the team the flow. Of course, it is also possible to use this team member, e.g., as a coach for team members who want to develop further in this learning area.
However, suppose expert knowledge is lacking in the team. In that case, the team should try to organize help, e.g., through workshops with external experts, through visits of individual team members to appropriate training courses with subsequent knowledge transfer within the team. In a scaled environment, intensive collaboration (in refinements/business analysis and design work) in the targeted learning field with the support of a team that has expertise there can also help build knowledge quickly.
Some helpful methods and practices to build knowledge and build team skills:
- Pair-and Mob-Programming
- Coding-Dojos
- Set up community of practices (for cross-team learning)
- Pair-Learning, Pair-Reading
- Reserve dedicated time units for individual learning
- Set up forums:
e.g., Agile Design Forum for the introduction of the S.O.L.I.D. Design Principles and GRASP Principles - Introduction of ATDD and TDD (improves domain, test, and code understanding)
The ideas listed here refer primarily to teams in software development. However, many of these methods and practices can be transferred to non-software areas and adapted accordingly.
6. Follow-up models: Show learning progress
Regular workshops to update or create follow-up TKMs help the team see if the measures are working and allow the team to make adjustments.
After three, six, or nine months, it is recommended to repeat the TKM process. Of course, you can skip the first step, "selection of learning fields". Repeat steps two, three, and four.
Then compare the current TKM with the previous TKM. Has there been progress, and have individual team members fallen behind? Why is that okay, or is there something wrong here? Real progress in the team should be celebrated. Becoming aware that the team has proven progress by the model has a very positive effect on the team’s mood and the motivation of the team to tackle new things.
In the follow-up workshops, the focus is on the most recently created TKM. In the discussion, the team may determine that it has already built up sufficient expertise in a learning field and that no further team activities are required here. In this case, the team can add a new learning field. A new TKM is then created for this field with the results of the learning fields that are still being used. This model is then used as a comparison model in the next update of the TKM.
Of course, after analyzing the new TKM, the team will agree on actions and plan knowledge building for the next learning period.
Learning vision instead of goals
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. This would disregard the individuality and independence of a team member, and learning would be perceived as a constraint. The picture on the left is just a vision. Everyone can develop in this direction and would be supported. If it is indeed the case that all team members are experts in one or more learning fields, then the team can open up new learning fields in the next TKM.
Real-life example
The TKM of a real team shown above shows the initial model on the left, created two months after the group was formed and updated after eight months (right side).
At the beginning of the team collaboration (left), many team members had only beginner knowledge or no knowledge of various learning fields. However, it is also noticeable from the large circles that team members in each learning field had expert knowledge and could support or train their colleagues in these learning fields accordingly.
In the TKM on the right, you can see that progress has been made in all learning areas. Many have significantly expanded their knowledge and are now working on corresponding tasks. Some now realize that they are even taking on tasks beyond their capabilities. Obviously, "learning by doing" is taking place here. However, there is one exception, the topic "CM Meta/Access" has not improved and even the expertise of a colleague seems to have become worse. This was explainable for the team in the analysis because the team has not taken on any tasks in this product area since the first TKM. So there was nothing for the team members to work on there and thus nothing to learn. However, the expert explained that other teams had further developed this technical component and that he was now no longer as familiar with it.
In the first team knowledge model workshop, the team had decided on the know-how-building measures listed below.
Decided measures
- Pair-Programming
- Ask questions! There should be no shyness about it.
- Set up your private coding projects and reserve time for them.
- Continuing education day: each team member could use one day in the sprint to learn.
- Results of individual learning had to be shared with the team and documented.
- A wish list of topics to be learned was created.
- Weekly (1/2 hour) tasks and solutions that were worked out were presented to the team.
- A "Best Practice" folder was created.
- Two teammates decided to take the SCJP certification together. They read books chapter by chapter and explained or quizzed each other on things to do.
- Nothing motivates like success. The Team Knowledge Model can show the learning success of a team.
Coaching Tips & Pitfalls
Of course, as with all methods, a few things outside of the methodology need to be considered with the Team Knowledge Model. In addition, I would like 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 remain together in the long term. Learning together needs trust and routines, which takes time to build.
It is also helpful if there is a common understanding in the team that it is every team member's job to help their colleagues develop their skills further. This can be supported by management. For example, by including an evaluation criterion for employees that records what they have contributed to the development of their colleagues.
The Team-Knowledge Model can be applied excellently in team-building workshops, e.g., after a team reorganization or a self-designing team workshop (see LeSS Case Study). The TKM can also be used very well in team retrospectives.
A self-assessment process is not an exact science. Still, the team knowledge model visualizes the existing or missing know-how in the team, gives conclusions about the team members' stress, and is, therefore, a good indicator of the team's self-confidence and mood.
No more than six learning fields should be considered and worked on simultaneously to avoid losing focus in the learning process.
Hanging the TKM in the team room reminds everyone on the team that actions have been agreed upon and must now be addressed.
Regular updates of the TKM show learning and development progress in the team. Nothing is as motivating as success. This visualization motivates team members for new challenges, strengthens the team's self-confidence and acceptance of responsibility, and increases the willingness to leave the comfort zone. I recommend repetitions at intervals of three, four, or six months, depending on the needs and complexity of the team's learning areas.
Do not write the team members' names on the crosses in the model. The TKM is internal to the team! However, the result can be made public and increases transparency. But individual team members should not be recognizable. This also prevents managers from misusing the model for team rankings.