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?
Das Lernen im Team und das Organisieren des Lernprozesses ist also eine wesentliche Aufgabe für Scrum- oder Feature Teams. Allerdings gibt es auch eine Rahmenbedingung, die den Teams das Lernen nicht gerade vereinfacht. In der agilen Projekt- oder Produktentwicklung ist die Vorhersagefähigkeit ein hohes Gut, denn dadurch wird Vertrauen der Kunden und Stakeholder hergestellt. Die wesentlichen Metriken für Vorhersagen sind zum einen die „remaining Product Backlog size“ (Größe des verbleibenden Produkt Backlogs) und die „Velocity“ (Liefergeschwindigkeit) des Teams. Damit mit diesen Werten (Burndown Chart) tatsächlich verlässliche Vorhersagen gemacht werden können, ist es wichtig, dass die Velocity des Teams keinen allzu großen Schwankungen unterliegt. Fatal ist es, wenn die Velocity des Teams in der kürzeren Vergangenheit ungeplant auf Null gefallen ist. In diesem Fall kann z.B. der Product Owner zukünftig keine zuverlässigen Vorhersagen mehr tätigen, denn die Velocity des Teams könnte dann ja jederzeit wieder auf Null fallen und damit nichts mehr liefern.
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“ ist das Schlagwort der Agilen Community und der heilige Gral der Agilität. Wie entwickelt man nun ein Team zu einem „High Performance Team“ und wie weist man nach, dass ein Team sich zu einem „High Performance Team“ entwickelt hat? Leider wird oft Performance mit der Team Liefergeschwindigkeit gleich gesetzt. Viele Manager neigen dazu die KPI „Velocity“ zu nutzen, um die Teamentwicklung nachzuweisen und um den Nutzen der Scrum Master Rolle zu messen oder zu bewerten. Das ist jedoch nicht zielführend. Weder weist eine steigende Velocity auf eine echte Teamentwicklung hin, noch weist sie den Nutzen eines Scrum Masters direkt nach. Zum einen, weil die Velocity eines Teams stets auch kleineren Schwankungen unterliegt (z.B. Urlaub, Krankheit oder andere ungeplante adhoc Tätigkeiten) und zum anderen, weil die Velocity auch durch Mehrarbeit einzelner Teammitglieder steigen kann. Außerdem kann die Velocity einfach durch höhere Schätzungen des Teams manipuliert werden.
In einem „High Performance Team“ geht es nicht darum, dass jeder schneller oder mehr arbeitet. Sondern darum, dass die Teammitglieder Routinen entwickeln, die es ihnen ermöglichen Synergien zu nutzen, um das Lernen und Liefern im Team effektiver und auch effizienter zu gestalten. Das Wunder der Kollaboration: Die Summe des Teams ist mehr als die Summe der Individuen. Es geht um echte Skalierung – darum die Kapazitäten und Kompetenzen der einzelnen Teammitglieder jederzeit optimal für den Teamerfolg (Know-how Aufbau und Produktivität gleichermaßen) einzusetzen.
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
Menschen lernen auf unterschiedlichste Weise. Lernen bedeutet auch immer, dass wir unsere Komfortzone verlassen und uns damit aus dem Flow nehmen. Am Rande des Flows gibt es zwei Wege des Lernens, die uns hoffentlich nur kurzzeitig aus dem Flow bringen. „Learning by doing“ und der initiale Wissensaufbau z.B. durch eine vorgelagerte Ausbildung ohne jedoch dieses Wissen unmittelbar zur praktischen Anwendung zu bringen.
Beim „Learning by doing“ werden zuerst die Herausforderungen erhöht. Eigentlich übersteigen dann die aktuellen Aufgaben die eigenen Fähigkeiten, aber man kniet sich rein und mit der Zeit versteht man wie es läuft und baut Wissen auf. So kommt man letztendlich wieder in den Flow. Viele Menschen bevorzugen diese Art des Lernens und daran ist auch nichts falsch.
Andere wiederum bevorzugen es, sich für neue Herausforderungen erstmal das nötige Wissen anzueignen. Durch eine entsprechende Ausbildungen z.B. Lehre oder auch einfach nur durch ein Training. Dies ist ebenfalls eine sehr gute und vernünftige Art des Aufbaus eigener Fähigkeiten. Stellen wir uns mal vor, ein Arzt würde seinen Ausbildungsweg über „learning by doing“ ohne langes Studium bestreiten. Auch dieser Weg des Lernens ist also durchaus hilfreich.
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.enn dann wäre uns der Weg zurück ins „Glück“ versagt. In solchen Fällen können wir zwei negative Effekte beobachten, die wir vielleicht schon mal selbst erlebt oder bei anderen gesehen haben.
Kommt man aus dem „Learning by doing“ nicht mehr zurück in den Flow, ist das vergleichbar mit dem „Peterchen-Prinzip“. Dieses besagt, dass jeder so lange befördert wird, bis er den Grad seiner Unfähigkeit erreicht hat. Man verfügt nicht über die notwendigen Kompetenzen für die aktuellen Aufgaben und ist dauergestresst.
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
Aus dem Kampfsport Aikido kommt die Einteilung der Lernenden in drei Status : Shu-Ha-Rhi. Wobei „Shu“ dem Anfänger, „Ha“ dem Fortgeschrittenem und „Rhi“ dem Meister entsprechen. 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.
Es ist hilfreich festzustellen, bin ich in dieser Wissensdomäne aktuell oberhalb des Flows, also in der „Überforderung“ oder läuft es super und bin im Flow, oder werden meine Kenntnisse garnicht genutzt und befinde mich in diesem Bereich unterhalb des Flows. Diese Einschätzung wird auf der Y-Achse (high, medium, low) eingetragen.
Auf der X-Achse hingegen schätzt man seine Kompetenzen in dem jeweiligen Bereich ein. Bin ich eher Anfänger, verfüge über Grundkenntnisse und benötige viel Zeit oder Hilfe um Probleme zu lösen? Hier wäre dann der Bereich „Shu“ zu wählen. Oder komme ich ganz gut zurecht, Hilfe benötige ich nur selten, dennoch stoße ich hin und wieder auf einige Wissenslücken, dann wäre „Ha“ angemessen. Sehe ich mich jedoch als Experten in diesem Bereich und kenne mich so gut aus, dass ich selbst keine Hilfe benötige aber andere in diesem Thema sogar unterrichten kann, ist „Rhi“ die richtige Einstufung.
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.
Hierbei is es sinnvoll, dass eine „neutrale“ Person, z.B. der Scrum Master, sich die Ergebnisse von jedem Teammitglied zeigen lässt und dann im Beisein Aller in das Team TKM überträgt. Dies ist ein wichtiger Aspekt, denn durch dieses Verfahren können mögliche Fehleinschätzungen transparent werden. Sind alle individuellen Kreuze zu einem Lernfeld übertragen, wird ein Kreis um alle Kreuze zu diesem Lernfeld gezogen. Danach wird der Vorgang mit dem nächsten Lernfeld wiederholt bis alle Lernfelder ins Teammodell übertragen sind. Dann beginnt die Interpretation und Analyse des Ergebnisses.
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.
Teamaufgabe ist es, die Teammitglieder schnellst möglich wieder in den Flow zu bringen. Ist ein Teammitglied in der „Überforderung“, dann sollte das Team durch Unterstützung beim Wissensaufbau helfen, z.B. indem ein Experte im Team (übernimmt die Coach Rolle) zusammen mit diesem Teammitglied (Coachee) an dessen Aufgaben mitarbeitet. So baut der Coachee schneller Wissen auf und kommt damit leichter wieder in den Flow zurück.
Ist hingegen ein Teammitglied „unterfordert“ ist der einfachste Weg dieses Teammitglied in die aktive Arbeit (Umsetzung von Backlog Items) in diesem Bereich einzubinden, um das Teammitglied wieder in den Flow zu bringen. Ebenfalls ist es möglich, dieses Teammitglied beispielsweise als Coach für Teammitglieder, die sich in diesem Lernfeld weiterentwickeln möchten, einzusetzen.
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. erweitert und arbeiten nun an entsprechenden Aufgaben. Einige merken nun, dass sie sogar Aufgaben übernehmen, die eigentlich über ihren Fähigkeiten liegen. Offensichtlich findet hier „Learning by doing“ statt. Eine Ausnahme gibt es allerdings, das Thema „CM Meta/Access“ hat sich nicht verbessert und sogar die Expertise eines Kollegen scheint schlechter geworden zu sein. Dies war für das Team in der Analyse erklärbar, denn das Team hat in diesem Bereich des Produktes seit dem ersten TKM keine Aufgaben mehr übernommen. Da gab es also für die Teammitglieder nichts zu arbeiten und damit auch nichts zu lernen. Der Experte erklärte, dass aber andere Teams diese fachliche Komponente weiterentwickelt hätten und er sich nun nicht mehr so gut dort auskennen würde.
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.
- Ein „Best Practice“ Ordner wurde erstellt
- 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.