Tobias Lotz, Author at Binaris Informatik

Verteilung der Fähigkeiten in Teams

Tobias Lotz — Tue, 16 May 2023 08:48:43 +0000

Einleitung

Nachdem wir uns in einem früheren Artikel mit den Fähigkeiten beschäftigt haben, die Scrum Teams idealerweise haben sollen, wird es nun darum gehen, das Vorhandensein dieser Fähigkeiten bzw. des Wissens zu überprüfen. Dabei geht es auch darum, herauszufinden, wie dieses Wissen im Team verteilt ist. So sollen Wissensinseln und Wissensdefizite entdeckt werden. Zusätzlich werden dann noch Methoden vorgestellt, um Wissen zu transferieren damit mögliche Wissensinseln zu beseitigen.

Wir sollten zwischen Wissen, Fähigkeiten bzw. Know-how unterscheiden, welches jedes Teammitglied haben muss und welches nicht jedes Teammitglied haben muss. Bei ersterem können wir beispielsweise das Qualitätsbewusstsein und die Konfliktfähigkeit nennen. Nur wenn alle Teammitglieder möglichst optimal an den Anforderungen des Kunden arbeiten, kann das Team zusammenarbeiten und das gewünschte Produkt herstellen.

Zu zweiterem zählt das Konfliktmanagement. Bei diesem geht es um das Erkennen und Lösen von Konflikten. Das Lösen dieser, und die daraus resultierende Zusammenarbeit, hilft dabei bessere Ergebnisse zu erzielen.

Wissensinseln

Wissensinseln sind Wissen oder Fähigkeiten, welche nur 1-2 Personen im Team haben. Solche Wissensinseln stellen für das Team ein Risiko dar, denn fällt nun genau diese Person/Personen aus, so ist das Team handlungsunfähig und kann nicht mehr normal weiterarbeiten.

Skill Matrix

Um jetzt die Wissensengpässe zu identifizieren, können wir die Skill-Matrix nutzen. In dieser werden die Fähigkeiten der Mitarbeiter dargestellt. Somit können Stärken und Schwächen sowie ausbaufähige Skills veranschaulicht werden. Es ist damit möglich, Stellen zu identifizieren, an denen das Ausfallrisiko eines Teams am höchsten ist. In den Zeilen der Matrix werden die Fähigkeiten und das Wissen aufgeführt, während die Spalten die Namen der Personen enthalten. Der Wissensstand der Teammitglieder wird festgehalten, um einen Überblick über das Team zu haben.

Wichtig hierbei, dass nicht jeder Mitarbeite jedes Wissen und jede Fähigkeit besitzen muss. Das Ziel ist es, das Wissen breiter zu streuen und somit das Ausfallrisiko zu minimieren. In der Tabelle kann festgelegt werden, wie häufig und in welchem Level Wissen vorhanden sein soll. Diese gibt dann an, ab welcher Stufe das geforderte Wissen, erfüllt ist. Ein Beispiel dafür sehen wir in der Tabelle bei der Fähigkeit Projektmanagement. Dort sehen wir das 2 Personen gefordert sind und diese erst ab dem Level Experte gezählt werden.

Idealerweise gibt es eine Einheitsdefinition, allerdings benötigen unterschiedliche Fähigkeiten unterschiedliche Ausprägungen. Auch muss die Lesbarkeit der Tabelle beachtet werden. Somit kann diese Ausprägung entweder in der Tabelle stehen oder separat dokumentiert werden.

Anhand der Beispielmatrix sind die Mitglieder eines Scrum Teams zu erkennen, sowie deren Wissensstand in den verschiedenen Bereichen. Unter der Spalte „Vorhanden“ ist zu sehen, wie viele Personen über das Wissen bereits verfügen und unter „Gefordert“, mit wie vielen Personen geplant wird. Bei der Personenanzahl für die „Gefordert“ Spalte sollten wir immer an ein Worst-Case-Szenario denken und schauen, dass das Team weiterarbeiten kann. Hier muss das Team entscheiden, ab welchem Wissensstand eine Person mitgezählt werden kann.

Gleichzeitig ist es wichtig, dass nicht jedes Teammitglied alles wissen muss. Ein weiterer Punkt ist sich als Team zu überlegen, ab welcher Stufe eine Person mitgezählt wird. Das sollte das Team entscheiden und so auf aktuelle und zukünftige Anforderungen reagieren. Hierbei sehen wir direkt, dass die Teamarbeit und die analytischen Fähigkeiten noch ausgebaut werden müssen.

Bei der Bewertung der Fähigkeiten gibt es verschiedene Möglichkeiten. Die Fähigkeiten können wie hier mit „Grundkenntnisse“, „Fortgeschritten“ und „Experte“ gekennzeichnet werden. Es ist aber auch möglich eine Skala von z.B. 1-10 zu nutzen. Dabei muss dann Transparent gemacht werden, welche Zahl für welche Stufe steht. Bleiben wir aber bei der Einteilung, welche in der Tabelle verwendet wurde. Eine Definition wie die Stufen definiert sind, könnte lauten:

Anfänger: Ein Anfänger ist eine Person, die neu in einem bestimmten Bereich ist und wenig oder keine Erfahrung oder Kenntnisse in diesem Bereich hat. Anfänger benötigen Anleitung und Hilfe, um grundlegende Fähigkeiten und Kenntnisse zu erlernen, und sie machen häufig Fehler, da sie sich noch nicht mit der Materie vertraut gemacht haben.
Fortgeschrittener: Ein Fortgeschrittener ist eine Person, die über grundlegende Kenntnisse und Fähigkeiten in einem bestimmten Bereich verfügt und in der Lage ist, selbstständig zu arbeiten. Sie hat bereits einige Erfahrungen gesammelt und kann schwierigere Aufgaben bewältigen. Fortgeschrittene benötigen jedoch manchmal noch Anleitung oder Unterstützung, um ihre Fähigkeiten weiter zu verbessern.
Experte: Ein Experte ist eine Person, die über umfassende Kenntnisse, Erfahrungen und Fähigkeiten in einem bestimmten Bereich verfügt. Experten können komplexe Probleme bewältigen und sind in der Lage, innovative Lösungen zu finden. Sie können auch anderen helfen, ihre Fähigkeiten zu verbessern und ihr Wissen zu erweitern. Experten haben in der Regel viele Jahre in einem bestimmten Bereich gearbeitet und verfügen über eine breite und tiefe Expertise.

Es gib eine Vielzahl von Möglichkeiten, die Fähigkeiten zu bewerten. Nutzt die Methode, welche am besten für euch passt. Das Gleiche gilt für die Fähigkeiten, die verglichen werden, dies sind hier nur Beispiele und sollen euch helfen das Konzept schneller und einfacher zu verstehen.

Truck-Faktor-Analyse

Die Truck-Faktor-Analyse ist ein leichtgewichtiger Ansatz, um den Einfluss von einzelnen Personen auf das Projekt zu verdeutlichen. Dabei wird die Frage gestellt: „Was sind die Auswirkungen für das Projekt, wenn ein Mitarbeiter von einem LKW erfasst wurde und deswegen überraschend und dauerhaft ausfällt?“ Diese bietet uns eine personenbezogene Analyse an, wodurch Fähigkeiten identifiziert werden, welche wichtig sind und eventuell noch nicht erfasst wurden.

Wissenstransfer

Nun haben wir unsere möglichen Wissensinseln identifiziert und wissen, welche Mitarbeiter über welche Fähigkeiten, Wissen oder Know-how verfügen. Im nächsten Schritt geht es darum, dass Wissen den anderen Teammitgliedern zugänglich zu machen.

Dokumentation

Eine Möglichkeit ist die Dokumentation. Bei dieser geht es darum, alle Aufgaben und Prozesse, die als Wissensinseln identifiziert wurden, zu dokumentieren und zu kommentieren. Somit können andere Personen ein Verständnis aufbauen den Prozess bzw. die Aufgabe zu verstehen und eigenständig durchführen zu können. In der Softwareentwicklung kann dies bedeuten, den Programmcode zu kommentieren und somit die einzelnen Funktionen einfach und schnell zu erklären. Größere Zusammenhänge wie die Architektur, können in UML-Diagrammen oder in einem Architekturdokument beschrieben werden.

Dabei gibt es verschiedene Nachteile. Zum einen verrottet so eine Dokumentation und kann somit nach einer gewissen Zeit unbrauchbar werden.. Das Format spielt hierbei eine wichtige Rolle. Wenn die Dokumentation den Programmcode nur erklärt und somit die Informationen des Programmcodes in anderer Form widerspiegeln, so ist die Information redundant. Erklärt die Dokumentation weitere Zusammenhänge, Abläufe und Entscheidungen, so ist die Dokumentation hilfreich.

Egal ob die Dokumentation redundant ist oder nicht, bei jeder Veränderung besteht das Risiko, dass diese Veränderung nicht in der Dokumentation angepasst wird. Es gibt also ein grundsätzliches Problem, dass eine Veränderung nicht nachgehalten wird und es somit eine Abweichung zwischen Programmcode und Dokumentation vorhanden ist. Geht es um Wissen, welches nur ein Mitarbeiter hat und dieses ist nicht in anderer Form festgehalten, so ist die Dokumentation eine gute Idee, um das Wissen zu verbreiten bzw. festzuhalten.

Pair Programming

Das Pair Programming ist ein Teil des Extreme Programming. Beim Pair-Programming sitzen zwei Entwickler zusammen und bearbeiten gemeinsam eine Aufgabe. Dabei gibt ein Entwickler den Code ein, während der andere beobachtet, Feedback gibt und Fragen stellt, also mit dem anderen interagiert. Nach ungefähr 5-10 Minuten werden die Rollen gewechselt. Durch diese Zusammenarbeit ist es möglich, potenzielle Fehler und Probleme frühzeitig zu erkennen.

Aufgrund dieser Zusammenarbeit entstehen einige Vorteile:

Es entsteht eine bessere Code-Qualität, da die beiden Entwickler zusammenarbeiten und Feedback geben können.
Beim Pair-Programming entsteht ein Wissensaustausch, dabei werden Erfahrungen, Wissen und Know-how weitergegeben, wodurch Wissensinseln aufgelöst werden.
Es werden schneller Probleme identifiziert und gelöst.

Leider gibt es auch ein paar Nachteile, die angesprochen werden müssen:

Beim Pair-Programming müssen zwei Entwickler an einer Aufgabe arbeiten, was, zumindest in einer kurzen Betrachtungsweise, mit höheren Kosten verbunden ist. Langfristig spart das Pair-Programming Zeit ein, da der Programmcode eine höhere Qualität besitzt und somit ein reduzierter Aufwand für das Bug-Fixing und die Weiterentwicklung entsteht.
Durch unterschiedliche Arbeitsweisen kann es zu Konflikten führen, welche die Produktivität kurzfristig beeinflussen Zuerst müssen beide Entwickler lernen, wann der beste Zeitpunkt ist, nachzufragen. Auch ist es wichtig zu erkennen, dass diese Nachfragen wertvoll sind und dadurch die Zusammenarbeit verbessert wird.

Langfristig sorgt das Pair Programming für eine bessere Zusammenarbeit im Team, da die Teammitglieder die unterschiedlichen Arbeitsweisen kennenlernen. Das Konzept des Pair-Programming kann auch auf andere Tätigkeiten übertragen werden, dazu zählen das generelle Lernen, die Problemlösung, Marketing oder Design. Bei allen diesen Tätigkeiten, sitzen zwei Personen zusammen, um die Aufgabe schneller zu lösen bzw. ein besseres Ergebnis zu erzielen.

Rotation der Aufgaben

Unter der Rotation der Aufgabe verstehen wir, dass die Mitarbeiter regelmäßig Ihre Tätigkeitsbereiche wechseln. Das meint bei Scrum, dass immer verschiedene Mitarbeiter beispielsweise das Front-End entwickeln und dadurch die Entstehung von Wissensinseln direkt vermieden wird. Es wird also darauf geachtet, dass die Mitarbeiter verschiedene Kompetenzen entwickeln.

Durch die Rotation können Mitarbeiter ein breiteres Wissen und Verständnis für verschiedene Bereiche entwickeln, es wird also das Risiko von Wissensinseln verringert. Es gibt auch Nachteile bei einer möglichen Rotation.

Zum einen brauchen Mitarbeiter eventuell länger für die Erledigung von Aufgaben da Ihnen die Routine bei der Durchführung fehlt. Es kann zu Kompetenzverlust führen, da Mitarbeiter über eine gewisse Zeit die Aufgabe nicht ausführen können und somit mehr Zeit in der Einarbeitung benötigen. Generell muss auch der Planungsaufwand berücksichtigt werden. Die Rotation von Aufgaben muss sorgfältig geplant werden, damit das Projekt nicht beeinträchtigt wird.

Die Rotation der Aufgaben lässt sich sehr gut mit dem Pair-Programming verbinden, da eine routinierte Person mit einer nicht erfahrenen Person zusammenarbeitet und viele Nachteile ausgleicht. Gleichzeitig gibt es durch diesen gemeinsamen Ansatz selbst Vor- und Nachteile, welche berücksichtigt werden müssen. Die Rotation der Aufgaben sollte insgesamt als Investition in die Zukunft gesehen werden.

In Scrum gibt es zwei Events, welche dazu beitragen, dass Wissen vermittelt und verteilt wird. Dazu zählen:

Daily Scrum

Bei dem Daily Scrum, kommt das gesamte Scrum-Team zusammen, um sich über den Fortschritt und Probleme auszutauschen. Hier wird kein ausführlicher Wissenstransfer stattfinden können, allein schon wegen der 15-minütigen Timebox. Daher wird hier ein eventuell notwendiger Wissenstransfer identifiziert und organisiert. Es können anschließend sogenannten Meet-Afters stattfinden, in denen sich die angesprochenen Personen treffen und das Vorgehen beim Wissenstransfer besprechen können.

Sprint Retrospektive

Bei der Sprint Retrospektive geht es darum, dass sich das Team über den vergangenen Sprint austauscht. Hier besteht die Möglichkeit Best Practices und Verbesserungsvorschläge auszutauschen oder auch neue Vorgehen zu besprechen. Durch die Ableitung von Problemen, kann herausgefunden werden, warum es ein Problem gab. Hierbei können auch Wissensinseln identifiziert und angegangen werden. Durch diese Überprüfung kann auch die Skill-Matrix immer wieder ergänzt und erweitert werden.

Wir sehen also, es gibt verschiedene Arten, um Wissensinseln aufzulösen. Diese müssen allerdings zielgerichtet eingesetzt werden, um auch einen Nutzen für das Projekt zu generieren. Jetzt bist du dran, identifiziert doch Wissensinseln in eurem Team und versucht diese aufzulösen. Denkt daran, das Auflösen von Wissensinseln kann länger dauern, hilft eurem Projekt allerdings langfristig.

The post Verteilung der Fähigkeiten in Teams appeared first on Binaris Informatik.

Welche Fähigkeiten braucht ein Scrum Team?

Tobias Lotz — Tue, 04 Apr 2023 07:37:00 +0000

Wenn wir Scrum nutzen, stehen wir vor besonderen Herausforderungen. Eine zentrale Herausforderung ist, dass am Ende eines Sprints ein benutzbares Produktinkrement vorhanden sein muss. Und um dieses Produktinkrement vorzeigen zu können, hat das Scrum-Team maximal 4 Wochen zur Verfügung. Zusätzlich ist es als komplettes Team für die Ergebnisse verantwortlich. Um diesen Herausforderungen begegnen zu können, benötigen wir verschiedene Fähigkeiten.

Bei der Recherche zu diesem Artikel kam bei mir öfters die Frage auf, ist der Punkt nun eine Fähigkeit oder doch Wissen und was unterscheidet beides voneinander? Deshalb wollen wir vorher klären, was Fähigkeiten von Wissen unterscheidet.

Um dem aktuellen Trend um künstliche Intelligenzen zu folgen, habe ich ChatGPT nach Definitionen von Wissen und Fähigkeiten gefragt. Das hier habe ich als Antwort bekommen: „Wissen und Fähigkeiten sind ähnliche Konzepte. Wissen bezieht sich dabei auf die Kenntnis von Informationen, Fakten und Grundsätzen. Fähigkeiten bezeichnet das können, um eine bestimmte Aufgabe oder Handlung durchzuführen.

Wissen ist also die Ansammlung von Informationen, die eine Person durch die eigene Erfahrung oder das Studium bekommt. Fähigkeiten beziehen sich auf Kompetenzen oder die Eignung einer Person, das Wissen zur Ausführung bestimmter Aufgaben anzuwenden.“
Für eine erste Spur, um auf die notwendigen Fähigkeiten zu kommen, die für alle Teammitglieder wichtig sind, können wir zuerst in den Scrum-Guide schauen. Dort finden wir 5 Werte, die jedes Teammitglied vertreten und verinnerlicht haben sollte.

Eine erste Spur, um Fähigkeiten zu identifizieren, welche für die Teammitglieder wichtig sind, führt zum Scrum-Guide. Dort finden wir 5 Werte, die jedes Teammitglied vertreten und verinnerlicht haben sollte. Die 5 Werte sind:

Commitment
Focus
Openness
Courage
Respect

Unter Commitment ist gemeint, dass jeder im Scrum-Team sich für die eigene Arbeit und das Produkt verantwortlich fühlt, Zusagen ernst nimmt und diese auch einhält.

Focus meint, dass sich die Teammitglieder auf die Aufgaben konzentrieren, die wichtig für den Sprint sind. Es ist zuallererst eine Ermahnung an die Teammitglieder, aus welcher sich dann aber auch Konsequenzen für die Organisation um das Team herum ableiten lassen.

Das Team muss damit umgehen können, wenn sich Pläne anders entwickeln oder diese nicht funktionieren und deswegen nach neuen Lösungen gesucht werden muss. Dies verstehen wir unter Openness.

Unter Courage verstehen wir den Mut, neue Wege auszuprobieren und damit Fehler zu riskieren und auch unangenehme Wege zu gehen.

Respect meint sowohl den respektvollen Umgang innerhalb des Teams als auch zwischen verschiedenen Teams und dem Umfeld.

Allerdings sind dies laut Scrum Guide erstmal Werte und noch keine Fähigkeiten, daher schauen wir uns jetzt mal, welche Fähigkeiten sich aus diesen Werten ergeben und welche anderen Fähigkeiten wir noch identifizieren können.

Commitment

Um den Wert Commitment leben zu können, sind folgende Fähigkeiten wichtig:

Qualitätsbewusstsein

Es ist wichtig, dass die Developer, der Product Owner und der Scrum Master das gleiche Verständnis für Qualität haben. Die Developer stehen dabei für die technische Qualität ein und müssen auch unter Zeitdruck sauber arbeiten. Durch das saubere Arbeiten werden keine technischen Schulden verursacht, wodurch Probleme in der Zukunft vermieden werden. Gerade am Anfang eines Projektes dauert es länger qualitativ hochwertige Arbeit zu leisten. Die Vorteile im späteren Projektverlauf sind, die Wartung und die Weiterentwicklung des Produkts. Somit wird durch höher qualitative Arbeit am Ende Zeit und Geld gespart. Der Product Owner muss dieses Qualitätsverständnis teilen und den Stakeholdern dieses erklären und verteidigen. Ein guter Leitsatz ist hierbei: „Qualität ist nicht verhandelbar“. Der Product Owner ist zusätzlich dafür verantwortlich, durch die Arbeit des Scrum Teams den Mehrwert für die Anwender und das Unternehmen zu steigern. Dies kann nur gelingen, wenn die Anforderungen an das Produkt klar ausgearbeitet sind und somit auch kommuniziert werden können. Somit ist der Product Owner für eine fachliche Qualität verantwortlich.

Vertrauen

Generell ist es immer gut, Vertrauen im Team zu haben. Trotzdem wollen wir uns diesen Punkt genauer anschauen und herausfinden, warum genau Vertrauen wichtig ist. Intuitiv könnte man annehmen, dass man im klassischen Projektmanagement weniger Vertrauen haben muss als in Scrum, da im klassischen Projektmanagement alles im Voraus geplant ist. Wohingegen es bei Scrum so scheint, dass weniger geplant wird und daher den einzelnen Teammitgliedern und dem ganzen Team mehr vertraut werden muss. Ich behaupte aber, dass in Scrum weniger Vertrauen vorhanden sein muss als im klassischen Projektmanagement. Dafür gibt es einige Faktoren. Zuerst ist Scrum sehr transparent, dadurch ist es schwieriger Fehler zu verbergen. Dafür haben z.B. wir das Daily Scrum, bei dem alle Developer zusammenkommen und sich darüber abstimmen, was seit gestern erledigt wurde, woran heute gearbeitet wird und wo es eventuell Probleme gibt. Insgesamt basiert Scrum auf der Arbeit mit Feedbackschleifen wodurch diese hohe Transparenz entsteht.

Active Learning

Active Learning bezeichnet die Bereitschaft aller Teammitglieder sich ständig weiterzubilden. Rein theoretisch könnte es sein, dass entweder vereinzelt oder alle Teammitglieder schon alles Nötige für ein Projekt wissen oder können und dieser Punkt damit wegfällt. Das ist aber eher unwahrscheinlich.

Focus

Der Wert Focus spricht die folgenden Fähigkeiten an:

Verständnis der Wertschöpfung

Das Verständnis der Wertschöpfung können wir in die Planung und die Durchführung des Sprints unterteilen. Bei der Planung muss sich der Product Owner Gedanken darüber machen, welche Anforderungen den Mehrwert des Produkts am meisten steigern. Es müssen also die Anforderungen bewertet werden und es muss ein Unterschied zwischen Wichtigem und Unwichtigen Anforderungen erfolgen. Bei der Durchführung ist es wichtig, dass sich die Developer auf das Sprint Goal konzentrieren und sich dabei nicht ablenken lassen. Diese Ablenkungen können sowohl Störungen aus der Organisation sein oder eigene Begehrlichkeiten. Die Developer erkennen, was wichtig ist, um das Ziel zu erreichen.

Zeitmanagement

Das Zeitmanagement zielt darauf ab, dass die Developer ein Bewusstsein entwickeln, auch während des Sprints den Fortschritt zu überprüfen und damit möglichst früh zu verstehen, ob das Sprint-Goal erreicht wird. Dadurch soll verhindert werden, erst am Ende des Sprints herauszufinden, dass Funktionalitäten nicht umgesetzt werden. Die Developer behalten also einen Überblick über die schon umgesetzten bzw. über die noch zu bearbeitenden User-Storys und vergleichen den Fortschritt mit der verbleibenden Zeit.

Openness

Für Openness benötigen wir:

Kommunikation

Die Fähigkeit zu kommunizieren, meint dabei für den Product Owner, dass dieser mit den Stakeholdern im Austausch sein muss, um deren Ideen zu verstehen und diese auch an die Developer weiterzugeben. Wichtig ist diese Fähigkeit auch zwischen den Developern und dem Product Owner. Es ist dadurch möglich, auftretende Probleme früh gemeinsam zu identifizierten und neue Lösungswege zu erarbeiten. Die Developer erhalten so auch Feedback vom Product Owner und erfahren, ob die Umsetzungen den Erwartungen entsprechen.

Teamfähigkeit

Dies bedeutet, dass sich die verschiedenen Verantwortlichkeiten gegenseitig bei Problemen helfen und unterstützen. Die Developer sollten dies sowieso tun, um dem Wert Commitment zu leben. Aber auch der Scrum Master und Product Owner müssen beide im Team arbeiten können, denn nur durch die Zusammenarbeit der drei Rollen kann es am Ende eines jeden Sprints ein benutzbares Produktinkrement geben. Gleichzeitig ist damit eine Unterstützung gemeint, bei welcher die Einzelperson nicht die auf die eigenen Ziele hinarbeitet, sondern immer das komplette Projekt im Blick hat.

Das Verständnis der Wertschöpfung ist ebenfalls wichtig, wurde aber unter dem Punkt Focus schon besprochen und wird dementsprechend hier nicht wiederholt.

Courage

Die Courage wird durch folgende Fähigkeiten gelebt:

Konfliktfähigkeit

Konfliktfähigkeit ist die Bereitschaft, sich einem Konflikt zu stellen und diesem konstruktiv zu lösen. Diese Fähigkeit ist für alle Mitglieder des Scrum Teams wichtig, da diese mit unterschiedlichen Personen kommunizieren und zusammenarbeiten.

Konfliktmanagement

Beim Konfliktmanagement geht es, um die Kompetenz, Konflikte mit Techniken aus dem Bereich der Kommunikation und des Coachings produktiv und klar zu lösen. Dabei sollte mindestens eine Person aus dem Scrum-Team diese Fähigkeit besitzen. Dies muss nicht unbedingt der Scrum Master sein. Vielmehr sollte dieser das Scrum-Team unterstützen, diese Fähigkeit zu entwickeln und somit zu einem selbst managenden Team zu werden.

Überzeugungskraft

Der Product Owner muss eine Vision des Produkts entwickeln und diese an die Stakeholder und Developer kommunizieren. Gerade bei der Kommunikation mit den Stakeholdern muss der Product Owner begründen können, warum welche Features umgesetzt werden und welche nicht. Dazu gehört auch die Erklärung, warum Features eventuell anders umgesetzt wurden als es sich die Stakeholder vorgestellt haben.

Im Verlauf eines Projekts entstehen bei Personen Widerstände, bei diesen Personen muss es der Scrum Master schaffen eine Bereitschaft herzustellen sich neuen Ideen oder Möglichkeiten überhaupt anzuhören. Dabei wird der Widerstand gegen die Idee abgebaut und eine Offenheit für neue Ideen erzeugt. Es geht dabei jedoch nicht darum, die Person von der Idee zu überzeugen oder sogar zu überreden, sondern, dass diese sich die Idee anhört und über diese nachdenkt.

Respect

Respekt innerhalb des Teams ist essenziell, da es durch die Transparenz und ergebnisorientierte Arbeit schnell zu Konflikten kommen kann. Diese müssen angesprochen und es muss eine konstruktive Lösung gefunden werden. Dabei ist es wichtig, dass die Teammitglieder nach dem Konflikt weiterhin zusammenarbeiten können.

Die beiden folgenden Punkte sind ebenfalls wichtig für den Respect, wurden aber in vorherigen Absätzen schon besprochen.

Die Zusammenarbeit als Team
Konfliktmanagement

Scrum

Es gibt eine weitere Fähigkeit, auf die ich in diesem Zusammenhang eingehen möchte. Diese ist das Wissen über Scrum.
Je mehr alle Beteiligten vorab über Scrum wissen, desto leichter fällt der Start mit dem agilen Arbeiten, wodurch der Scrum Master weniger Aufwand hat, Scrum im Team zu etablieren. Kollegen, die schon über Wissen in Scrum verfügen haben, kennen schon die Werte, Abläufe und Events, die stattfinden. Sie müssen also nicht alles neu lernen und finden sich schneller im Scrum Framework zurecht. Es ist möglich, dass Sie durch Ihre Erfahrung anderen Teammitgliedern helfen, schneller mit Scrum vertraut zu werden, sodass diese dann sicherer im Umgang mit Scrum werden.

Durch dieses Wissen unterstützen Sie den Scrum Master bei der Einführung und Akzeptanz von Scrum im Team.

Obwohl Kenntnisse oder sogar Erfahrungen mit Scrum oder agilem Arbeiten bei den Developern und dem Product Owner sehr wünschenswert sind, sind sie jedoch keine zwingende Voraussetzung für den Start mit Scrum. In diesem Fall unterstützt der Scrum Master die anderen dabei, Scrum beim aktiven Einsatz Schritt für Schritt immer besser zu erlernen und zu verstehen

Scrum Master

Für den Scrum Master gibt es noch einige weitere spezielle Fähigkeiten, die dieser besitzen muss, vor allem da er auch in der Organisation Scrum einführen und etablieren soll. Dies kann je nach Größe der Organisation unterschiedlich lange dauern. Daher ist eine sehr grundlegende Eigenschaft für den Scrum Master Geduld und Nervenstärke, um auch über lange Zeit eine Veränderung in der Organisation bewirken zu können.

Diese Veränderung zu bewirken, dauert meistens lange und ist nur durch kleine Schritte und Erfolge möglich. Es müssen die verschiedensten Personen von den Vorteilen der Agilität und Scrum überzeugt werden. Teilweise wollen diese Personen auch erst abwarten, wie das Scrum-Team arbeitet und ob es eine höhere Kundenzufriedenheit schafft. Hierbei muss sich der Scrum Master im Klaren sein, dass dieser mit dem komplexesten System arbeitet, das man sich vorstellen kann: dem Menschen.

Fazit

Wir können die Scrum Werte als Grundbausteine verstehen, auf denen wir dann als Team aufbauen. Diese helfen uns für eine gemeinsame Sicht- und Verhaltensweise. Gleichzeitig sehen wir, dass wir durch die Kombination der verschiedenen Werte unterschiedliche Fähigkeiten identifizieren können, die benötigt werden, um als Team zu arbeiten und Scrum
umzusetzen. Wir sehen, dass die Ausprägungen, wie die Fähigkeiten im Einzelnen umgesetzt werden, je nach Verantwortlichkeit unterschiedlich sind.

Jetzt bist du an der Reihe.

Welche Fähigkeiten sind schon bei dir oder deinem Team vorhanden?

Gibt es Fähigkeiten, die noch entwickelt werden müssen?

Welche nächsten Schritte unternimmst du, um die Fähigkeiten zu entwickeln?

The post Welche Fähigkeiten braucht ein Scrum Team? appeared first on Binaris Informatik.

Die Feedbackschleife in Scrum

Tobias Lotz — Thu, 12 Jan 2023 09:21:20 +0000

Die Feedbackschleife in Scrum

Das Ziel von Feedback ist es, eine Veränderung zu bewirken. In der Agilität werden Fehler als Chancen begriffen. Diese Chancen treten in einem Projekt früher oder später auf und sollten daher genutzt werden, um bestehenden Prozesse infrage zu stellen.
Durch das frühe Auftreten der Chancen können alle Projektbeteiligten aus diesen lernen und diese in Zukunft verhindern.

Der PDCA-Zyklus

Der Deming-Kreis bzw. PDCA-Zyklus verdeutlicht, wie eine Feedbackschleife funktioniert. Dieser veranschaulicht, wie mit kontinuierlichen Veränderungen umgegangen werden kann und wie diese in einem Unternehmen eingeführt werden können.

Der PDCA-Zyklus arbeitet in Schleifen. Die einzelnen Schritte ergeben einen Kreis, wodurch am Ende ein erreichter Zustand beibehalten wird. Von diesem erreichten Zustand können weitere Optimierungen geplant und durchgeführt werden. Hierbei sind kurze Zeiträume wichtig, damit schnell Feedback berücksichtigt werden kann.

In Feedbackschleifen zu arbeiten bedeutet, dass sich die verschiedenen Mitglieder eines Projektteams regelmäßig austauschen, um Probleme zu lösen und bestehende Prozesse zu verbessern, welche die Arbeitsleistung bzw. die Geschwindigkeit einschränken oder die Erstellung funktionierender Produktinkremente behindern.

Im ersten Schritt, dem Plan, geht es um die Planung und Erkennung von konkreten Verbesserungspotenzialen.

Im Do werden die vorher besprochenen Aufgaben durchgeführt, der Plan wird also in die Tat umgesetzt.
Beim Check geht es um die Überprüfung des Ergebnisses und ob es den Erwartungen entspricht. Um die Ergebnisse überprüfen zu können, ist es wichtig, dass diese messbar sind.

Beim letzten Schritt, dem Act, wird entschieden, ob das erreichte Ergebnis den Erwartungen entspricht oder ob der Arbeitsprozess weiter verbessert werden muss. Damit die weitere Verbesserung funktioniert, wird das vorher erreichte Ergebnis als Standard implementiert. Von diesem Standard beginnt der PDCA-Zyklus wieder von vorne.

3-Säulen von Scrum
Scrum selbst basiert auf den drei Säulen, welche eine eigene Funktionsweise der Feedbackschleife darstellen. Diese sind:
•   Transparenz
•   Überprüfung
•   Anpassung

Die 3 Säulen von Scrum

Scrum selbst basiert auf den drei Säulen, welche eine eigene Funktionsweise der Feedbackschleife darstellen. Diese sind:

•   Transparenz
•   Überprüfung
•   Anpassung

Bei der Transparenz geht es sowohl um offene Kommunikation als auch, dass alle Personen Zugriff auf alle Artefakte und Ergebnisse haben sowie das gleiche unter den verwendeten Begriffen verstehen.

Mit der Überprüfung ist die Kontrolle von Ergebnissen gemeint. Scrum hat das Ziel, am Ende eines jeden Sprints ein benutzbares Produktinkrement bereitzustellen. Nur durch das vorherige Setzen eines konkreten Ziels, ist die Überprüfung und Nachverfolgbarkeit von Ergebnissen überhaupt möglich.

Durch diese Überprüfung schaffen wir die Möglichkeit sowohl die Produkte als auch die Prozesse zu verbessern. Dadurch können wir die entsprechenden Bedingungen für das Projekt so gestalten und bei Bedarf verändern, dass ein Projekt erfolgreich wird.

Durch die allgegenwärtige Transparenz im Zusammenspiel mit der Überprüfung und der Anpassung während des Sprints bildet dies eine kontinuierliche Feedbackschleife.

Einsatz des PDCA-Zyklus im Scrum-Prozess

Scrum hat seinen eigenen Aufbau des PDCA-Zyklus. Dabei wird Feedback in verschiedenen Zyklen generiert. Genau darum geht es hier.

Wenn wir mit Scrum arbeiten, dann nutzen wir nicht nur eine Feedbackschleife, sondern viele kleine. Genauer gesagt ist jeder Sprint eine Feedbackschleife. In dieser gibt es dann in verschiedenen Abständen Events, in denen Feedback eingeholt wird. Diese werden im weiter unten genauer besprochen. Alle diese Schleifen haben die Erreichung des Product Goals zum Ziel.

Dieses wird für jeden Sprint in ein Sprint Goal heruntergebrochen. Als Ausnahme ist hierbei die Retrospektive zu nennen, bei diesem Event geht es vorrangig um die Verbesserung des Entwicklungsprozesses. In den jeweiligen Sprints gibt es verschiedene Scrum-Events, welche das Ziel haben Feedback einzuholen und im Anschluss für die Erstellung des Produktes zu nutzen.

Dabei können sich der Product Owner und die Developer folgende generelle Fragen stellen:

•   Welche Prozesse laufen gut und können verbessert werden?
•   Was läuft schlecht und muss verbessert werden?
•   Bauen wir als Scrum Team das richtige Produkt?

Gerade die letzte Frage stellt sich der Product Owner bei der Abnahme immer. Diese Abnahme geschieht im Optimalfall schon während des Sprints. Dadurch kann schon Feedback, welches im Sprint gewonnen wurde, berücksichtigt werden.

Die Scrum Events

Es gibt verschiedene Scrum Events, welche in einem regelmäßigen Rhythmus abgehalten werden. Das Ziel dieser Events ist, Feedback zu generieren und es im Anschluss zu nutzen. Diese sind:

1.   Daily Scrum
2.   Sprint Review
3.   Sprint Retrospektive
4.   Product Backlog Refinement

Beim Daily Scrum Meeting tauschen sich die Developer darüber aus, was seit dem letzten Daily Scrum geschafft wurde, was diese planen, heute zu erledigen und ob es Probleme bei der Arbeit gibt. Durch diesen täglichen Abgleich wissen alle Developer, an was gearbeitet wird. Sollten technische Probleme aufgedeckt werden, so helfen sich die Developer nach dem Daily.
Geht es um organisatorische Probleme, so wird der Product Owner bzw. Scrum Master informiert und diese versuchen die Probleme zu beseitigen.

Dieser Austausch hilft dabei am Ende das Product Goal und das Sprint Goal zu erreichen. Ein Nebeneffekt dieser Ehrlichkeit dem Team gegenüber ist, dass das Team zusammenwächst und dadurch immer besser zusammenarbeitet. Durch das Vertrauen und die Ehrlichkeit, die jedem Teammitglied entgegengebracht werden, wächst das Team immer besser zusammen und verbessert auch die Zusammenarbeit.

Im Review präsentiert das Scrum Team das Sprintergebnis den Stakeholdern. Dabei können die Stakeholder das Produktinkrement idealerweise selbst testen. Basierend auf der Präsentation und dem selbstständigen Ausprobieren, erhält das Scrum Team Produktfeedback.
Das generierte Feedback fließt dann in die weitere Produktentwicklung mit ein. Durch diesen Prozess weiß das Scrum Team, was sich die Stakeholder wünschen, und kann diese Wünsche für die weitere Entwicklung berücksichtigen. Das Scrum Team erhält hier eine Antwort auf die Frage, ob das richtige Produkt erstellt wird.

In der Sprint Retrospektive tauscht sich das Scrum Team über den letzten Sprint aus. Hierbei können sowohl negative als auch positive Punkte angesprochen werden.
Durch das Ansprechen von Problemen bzw. weitere zu optimieren Prozessen, schafft es das Team immer besser zusammenzuarbeiten. Durch eine immer bessere Zusammenarbeit kann das Team versuchen seine Velocity zu verbessern bzw. zu halten. Ab einem bestimmten Punkt wird es immer schwieriger die Geschwindigkeit eines Scrum Teams zu verbessern, dass bedeutet aber nicht, dass es nicht Probleme oder Verbesserungspotenziale gibt, die trotzdem angesprochen werden müssen.

Beim Product Backlog Refinement geht es um das Feedback, welches die Developer dem Product Owner geben. Dieser kann dahingehend die Priorisierung anpassen bzw. von einer (neu) Schätzung der Back Log-Items profitieren.
Durch die Nutzung dieses Wissens kann der Product Owner besser einschätzen, welche Anforderungen von den Developern fertiggestellt werden können und welche nicht.
Somit gelingt eine immer bessere vorhersage, welche Funktionalitäten realistisch entwickelt werden können.

Fazit

Es wird deutlich, dass ein Projekt immer von Feedback profitiert. Scrum hilft dabei, Feedback im laufenden Projekt einzuholen. Dafür gibt es viele Scrum-Events, die dies ermöglichen.
Damit Feedback dabei hilft, das Projekt erfolgreich abzuschließen, muss dieses auch umgesetzt werden. Dabei kann dir der PDCA-Zyklus unterstützen.

Versuchen Sie also Feedback zu bekommen und dieses auch umzusetzen!

The post Die Feedbackschleife in Scrum appeared first on Binaris Informatik.