Ein Auszug typischer Maßnahmen zur Wissensverteilung
Wichtigkeit ansprechen
Viele Scrum Master spiegeln mir zurück, dass sie versuchen die Wichtigkeit der Wissensverbreiterung offen anzusprechen. Leider verpuffen absprachen aus solchen Terminen oft im Alltagsstress oder weil es uns schwer fällt aus gewohnten Mustern auszubrechen.
Austausch Sessions
In vielen Umgebungen werden Sessions zum Wissensaustausch im Team und über die Teams hinaus angesetzt. Oft wird hier aber auch über neue spannende Themen gesprochen und über Themen, die Experten spannend finden und weniger über das was akut für eine breite Aufstellung gebraucht wird.
Pair Programming
In rotierenden Pärchen zu arbeiten, führt nicht nur zu besseren Ergebnissen sondern es hilft auch ganz automatisch Wissen zu verteilen und das System für Dritte zugänglicher zu machen.
Das Problem ist oft, dass sich im Alltagsdruck und aus der Gewohnheit alleine zu arbeiten, viele Schwer tun, Pairing umfassender in ihrer Arbeit zu nutzen.
Testgetriebene Entwicklung
Testgetriebene Entwicklung führt nicht nur zu einer hohen Testabdeckung, welche es für Dritte in fremden Bereichen leichter macht zu agieren.
Allerdings verlangt auch Test-Driver-Development (TDD) hier sich in der Entwicklung umzustellen und viele tun sich hier schwer.
Oft greifen diese Ansätze ins Leere, warum?
Alle obigen Ansätze gut gelebt können einen wichtigen Beitrag dazu leisten, dass wir uns als Scrum Team breiter aufstellen können und Wissensinseln auflösen dürfen. Leider laufen diese Ansätze für sich aber oft ins Leere und es stellt sich oft die Frage, warum wir uns hier so schwer tun?
So logisch es auch ist, sich zumindest in kritischen Bereichen breiter aufzustellen, ist es auch schwer aus altern Mustern auszubrechen.
Wir sollten nicht vergessen, dass viele Experten sich ihren Expertenstatus hart erarbeitet haben. Sie identifizieren sich mit ihrer exklusiven Expertise und ihren Handlungsbereichen. Es schmeichelt einem natürlich, wenn man gefragt ist, und dies dann aber auch einfach selbstlos in den Dienst des Teams zu stellen fällt dann oft schwer.
Zusätzlich dazu sind von einer Person exklusiv bearbeitete Handlungsfelder sehr schwer zugänglich. Sie wurden von der einen Person ohne Feedback und Austausch mit Anderen entwickelt. Das jetzt dritte Personen in diese Bereiche schauen, mitentwickelnd und diese auch kritisieren, macht vielen Experten Angst. Gestern waren sie noch der exklusive Experte und heute stehen sie im Fokus, weil sie einen schlecht zugänglichen Bereich in unserem System geschaffen haben. Hinter dieser Konstellation verbergen sich viele potentielle Konflikte und Hindernisse.
Das Problem reduziert sich also nicht nur auf die ungünstige Verteilung von Fähigkeiten in einem Scrum Team, sondern es ist auch das Problem, dass Dokumentation und Verständlichkeit für Dritte fehlen.
Durch einen angestauten Lieferdruck wird dies in vielen Umgebungen nicht leichter. Um aus der Dringlichkeit gemachte Versprechungen einzuhalten werden die Potentiale durch den fokussierten Wissensaustausch an kritischen Stellen gänzlich ausgeblendet. Dabei fehlt oft ein Gefühl dafür, was übergreifend gerade wichtig ist und was der daraus resultierende Flaschenhals der notwendigen Expertisen ist.
Über viele Jahre wurde ja in vielen Umgebungen, ausgehend von den zur Verfügung stehenden Kapazitäten, die Arbeit vorausgeplant. So bleibt oft verborgen, was wirklich kritisch ist und was nur eine nette ABM-Maßnahme für nicht so ausgelastete Kollegen ist. Würden wir hier eine Übersicht haben, was gebraucht wird, könnten wir eine Transparenz schaffen, wo wir große Engpässe haben und wo nicht.
Die Gründe warum wir uns dabei schwer tun uns als Scrum Team breiter aufzustellen sind vielschichtig. Oft wurde von engagierten Teammitgliedern schon viel probiert und das lief dann aufgrund der bisher geschilderten Herausforderungen ins Leere und so resignieren schrittweise viele Teammitglieder über die Zeit.
Statt lebloser Retrospektiven gemeinsam Verbesserungen vorantreiben
Lasst uns gemeinsam in diesem kostenlosen Scrum Master Dojo austauschen und strukturiert neue Ansatzpunkte finden, um als Scrum Master einen Unterschied zu machen.
Montag
14.08.
18:15-20:00
Den Bedarf der Optimierung konkretisieren
Im vorhergehenden Abschnitt habe ich versucht aufzuzeigen, warum das reine Benennen von Lösungsansätzen oft nicht ausreicht. Dabei ist es aus meiner Erfahrung egal, ob die Lösungsansätze von Euch als Scrum Master oder von den beteiligten Personen benannt werden. Zumeist verpuffen sie leider viel zu schnell.
Für mich hat sich in solchen Fällen, den Handlungsbedarf bewußt und konkret zu machen sehr bewährt. Ich konzentriere mich erstmal darauf, den Bedarf zu optimieren und klar aufzustellen, sodass viele Problemlöser sich angesprochen fühlen hier etwas machen zu wollen.
Bedarf konkretisieren
Bewährte Interventionen
Folgende Interventionen haben sich für mich in diesem Szenario bewährt, um die Basis für eine breitere Aufstellung im Team aufzuzeigen:
Anstelle in Scrum die Periodisierung nach verfügbaren Kapazitäten und Fähigkeiten fortzuführen, könnte man das Backlog unabhängig davon aus dem Bedürfnis des Businesses priorisieren.
Ausgehen von einem solchen Product Backlog sind wir in der Lage einen Austausch anzuregen, wie wir zu diesen Prioritäten als Scrum Team aufgestellt sind.
Natürlich sollten wir genügend Items für das Sprint Planning vorbereiten. Es sollte aber für das Team und jeden Entwickler transparent sein, dass ein präferiertes Items an Position 20 oder 30 liegt.
So kann bewußt abgewogen werden, ob es nicht doch Möglichkeiten gibt dies bei höher priorisierten Items einzubringen oder ob der zusätzliche Aufwand im Verhältnis steht.
Ausgehend aus dem Eindruck unseres Product Backlogs, was aktuell wichtig ist und was nicht, lässt sich durch ein Skill-Mapping konkret über die Breite der Aufstellung und Engpässe reden.
Dazu skizziere ich zu wichtigen repräsentativen Product Backlog Items die benötigten Fähigkeiten hierfür.
Für diese Fähigkeiten skizzieren wir jetzt im Team, welche Fähigkeiten im Team vertreten sind. Engpässe werden so sehr schnell deutlich und wir können aufbauend darüber reden, wie wir diese Skills im Team verteilen können.
Genauso können wir in einer Systemübersicht ausmalen, wo wie viele Teammitglieder in der Lage sind sich einzubringen.
Ich differenziere hier gerne zwischen
- Kann eigenständig in diesem Bereich arbeiten
- Kann Dritte einarbeiten
- Kann hier unter Anleitung arbeiten
Auch aus dieser Übersicht lassen sich sehr konkrete und dringliche Handlungsfelder zur Verbreiterung der Kompetenzen ableiten.
Neben der Aufarbeitung der Skill Verteilung, kann es auch sinnvoll sein, herauszuarbeiten, wie zugänglich das System ist.
Hier hatte ich gute Erfahrungen mit der Bewertung von Kriterien, wie
- Absicherung durch automatisierte Tests
- Dokumentation
- Zugänglichkeit (Design, Einfachheit, Verständlichkeit und schwer nachzuvollziehende Seiteneffekte)
Aus einer solchen Bewertung lassen sich sehr konkrete Verbesserungsbereiche ableiten, um es Dritten leichter zu machen sich in fremden Bereichen im System einzubringen.
Die Einbindung von Stakeholdern hilft dabei der breiteren Aufstellung im Team eine größere Wichtigkeit zu geben.
Dies kann man beispielsweise durch die Bewertung der Aufstellung zu den strategischen Zielen des Produktes erreichen.
- Wie gut können wir fokussiert und schnell nach den bekannten Ambitionen abliefern?
- Wo haben wir auf Basis unserer Aufstellung Grenzen?
- Wie schnell können wir auf sich ändernde Prioritäten und Ideen reagieren, da wir unseren Fokus hier aus unserer breiten Aufstellung leicht umschiffen können?
So verleihen wir der Wichtigkeit, uns an den wichtigen Stellen breiter aufzustellen Nachdruck und eine pragmatische Ausrichtung an den Zielen der Organisation.
Mich beeindruckt hier immer wieder auch das Maß an Kreativität, Pragmatismus und Eigeninitiative, wenn die beteiligten Personen die Notwendigkeit sehen hier etwas zu ändern.
In einer Umgebung, in der wir diesen konkreten Bedarf geschaffen haben, werden auch Wissensaustausch Sessions deutlich fokussierter genutzt. Ego-Sessions mit technisch anspruchsvollen Themen, mit denen man sich als Experte profilieren kann, werden weniger und der Anteil an Sessions in der ganz konkrete Hilfestellungen in kritischen Bereichen gegeben werden, nehmen zu. Im Fokus steht hier, weitere Leute im Team zu befähigen und dies zahlt sich dann oft in einem überschaubaren Zeitraum aus.
Zu viele Wissensaustausch Sessions konzentrieren sich auf spannende technische Fälle, die für Experten spannend sind aber nicht wirklich helfen.
Unterstützung Lösungsansätze umzusetzen
Auch wenn alle Beteiligten eine konkrete Notwendigkeit sehen, etwas zu ändern und dafür gute Maßnahmen gefunden haben, reicht das in manchen Fällen nicht aus.
Zu tief sitzen alte bequeme Muster, der Lieferdruck und der Umfang, in dem wir hier Dinge aufräumen müssen kann schon schnell nerven.
Hier sind wir als Scrum Master (der Facilitator) in der Umsetzung dieser Ideen gefragt!
Facilitation der Umsetzung
Bewährte Hilfestellungen
Folgende Hilfestellungen haben sich für mich bewährt, um die Verbesserungen auch wirklich in der Praxis umzusetzen:
In jedem Sprint wählen wir bewußt ein Item aus, wo wir uns probieren, neue Herangehensweisen zu finden oder uns zum Wissensaustausch Zeit nehmen.
Anstelle das wir hier Personen fragen, was sie gerne vorstellen und teilen wollen, fragen wir nach Themen und Fragestellungen zu denen Leute gerne mehr lernen wollen. Dazu können wir dann passende Leute im Team oder darüber hinaus finden. Der Wissensfokus wird hier gut deutlich.
Gerade in Bereichen, wo wir vor einem langen Weg stehen, um unser System zugänglicher zu machen, hat es sich für mich bewährt die Optimierung von Dokumentation und Testing an den aktuellen Sprint Fokus zu koppeln.
So muss weniger zwischen Themen gesprungen werden und es wird sehr viel klarer, was hier fehlt, um hier auch in fremden Bereichen des Systems tätig zu werden.
Wenn wir kritische Experten identifiziert haben, dann können wir im Sprint Planning gemeinsam die Einarbeitung von Notizen planen.
Wir können abstimmen, wie diese Neulinge die Arbeit der Experten übernehmen können. Wenn wir dies als neues Ritual aufbauen, dann ist es oft sehr schnell möglich, auch an kritischen Bereichen mehr Manpower zu konzentrieren.
Die bessere und breitere Aufstellung in einem Scrum Team ist in der Regel kein Sprint, sondern ein Marathon! Um hier ein Gefühl davon zu bekommen, dass wir vorankommen oder unsere Maßnahmen zu optimieren, können Metriken einen wichtigen Eindruck geben.
Durch die passenden Ansätze lässt sich auch in diesem nicht ganz trivialen Thema etwas bewegen und ich hoffe diese Ansätze helfen Euch weiter hier neue Anstöße zu geben.
Hintergrund dieser Folge
Diese Folge ist aus den Vorgesprächen in unserem „Online Programm“ entstanden. In diesem Programm steht das persönliche Wachstum auf Basis der Aufarbeitung herausfordernder Praxisbeispiele im Fokus. Bei Interesse findest du hier mehr zu unterem Programm.
Zusätzlich hatten wir in unserem letzten öffentlichen „Scrum Master Dojo“ dieses Fallbeispiel systematisch auf Basis des agilen Match plans aufgearbeitet. Wir organisieren monatlich ein freies „Scrum Master Dojo Webinar“ und arbeiten in jedem Termin ein anderes Fallbeispiel auf. Bei Interesse kannst du dich hier für unser nächstes „Scrum Master Dojo“ anmelden.
