Warum sich Gedränge so sehr lohnt

Donnerstag, 26. März 2015 von  
unter Fachartikel Scrum

Im ersten Moment klingt Gedränge für die meisten von uns eher unangenehm, nach etwas, dass man nicht unbedingt haben möchte. Doch als Ken Schwaber und Jeff Sutherland 1995 nach einem Namen für ihr Projektmanagementframework suchten, da verbanden sie eine andere Vorstellung mit Gedränge. Sie suchten nach einem passenden Begriff, der ausdrückt wie ein Team gemeinsam und kurzentschlossen auf sich ändernde Umstände reagiert, um dennoch das gewählte Ziel zu erreichen. Das Scrum, wie das Gedränge im Rugbysport genannt wird, drückt dieses fast perfekt aus.

In verschiedenen Varianten des Rugbysports ist das Scrum die Standardsituation, durch die nach einer Spielunterbrechung der Ball wieder ins Spiel gebracht wird. Dabei stehen sich beide Mannschaften in einer kompakten Formation gegenüber und versuchen, nachdem der Ball in das Gedränge eingeworfen wird, diesen in Besitz zu nehmen.

Die Herausforderung in dieser Analogie zum Projektteam gestaltet sich wie folgt: Jede der beiden Mannschaften hat im Vorfeld eine Strategie vereinbart, wie sie das gemeinsame Ziel, den Ballbesitz, erreichen möchte.
Da allerdings schon klar ist, dass nicht alle Einflussfaktoren bekannt sind (z.B. die Strategie der gegnerischen Mannschaft) oder bestimmt werden können (das Verhalten der gegnerischen Spieler), wird die Strategie auch nur entsprechend grob geplant.

Nach dem Einwurf des Balls versuchen beide Mannschaften jetzt ihre Strategie umzusetzen. Dabei werden sich jedoch schon innerhalb von Sekunden mindestens eine und evtl. sogar beide Mannschaften mit sich völlig anderen Umständen konfrontiert sehen. Und hier, mitten im Gedränge gibt es jetzt keine Möglichkeit sich erst mal in Ruhe zurückzuziehen und eine neue Strategie zu besprechen oder sich von einem Trainer die nächsten Schritte vorgeben zu lassen. Nein, das Team muss nun autonom in der Hitze des Gefechts sein Verhalten anpassen um doch noch das Ziel zu erreichen.

Und genauso wünschen sich Ken und Jeff, wie moderne Projektteams mit den sich immer wieder verändernden Umständen in gängigen Softwareprojekten umgehen sollen.
Auch in Scrum (wir reden nun über das Projektmanagementframework) planen wir. Da wir uns aber darüber bewusst sind, dass wir vorab nicht alle Einflussfaktoren kennen und berücksichtigen können, planen wir bewusst anders. Wir planen weniger im Voraus und weniger im Detail. Angelehnt an die Just-in-time Idee aus dem Lean Management erfolgt Planung immer nur in dem zu aktuellen Moment richtigen Ausmaß bzw. erst zu dem Moment, wo sie wirklich notwendig ist. Das ist einer der großen Paradigmenwechsel, die Scrum mitgebracht hat.

Und um wieder auf das Gedränge zurückzukommen, setzen wir in Scrum nicht auf die konzeptionelle und planerische Kompetenz einer Einzelperson, wie z.B. den Projektleiter, sondern auf die Fähigkeiten und Erfahrungen unseres ganzen Projektteams. Wie beim Forschungsgebiet der Schwarmintelligenz glauben wir daran, dass eine zentrale Führung eines Projektteams nicht notwendig und oft sogar weniger leistungsfähig ist. Oder mal anders formuliert, wir formieren eine ganze Gruppe von gut ausgebildeten Fachleuten, die meistens auch nicht ganz kostengünstig sind. Und wollen dann nur einen Teil ihrer Hirnkapazität nutzen, weil wir ihnen nicht zutrauen, sich organisieren zu können? Wer an dieser Idee festhält, der hat immer noch zu viel Projektbudget übrig.

Doch eines dürfen wir natürlich zugeben, diese Form der Selbstorganisation von Teams muss oft erst noch erlernt werden. Auch Rugbyspieler und Rugbymannschaften sind nicht mit dem Wissen geboren worden, wie sie sich im Gedränge verhalten sollen. Sie haben das trainiert. Und damit auch Projektteams das lernen können, bietet Scrum einen einfachen aber effektiven Feedbackmechanismus, der durch inspect-and-adapt in kurzen Zyklen aus Projektteams hocheffiziente Mannschaften formt.

Da hört sich der Begriff Gedränge doch auf einmal ganz anders an.

Was sind selbstorganisierende Teams?

Donnerstag, 28. Oktober 2010 von  
unter Fachartikel Scrum

Zusammen mit den Begriffen der agilen Softwareentwicklung beziehungsweise dem agilen Projektmanagement wird auch immer öfters von selbstorganisierenden Teams gesprochen und oft betont, dass diese selbstorganisierenden Teams ein wichtiger Bestandteil der agilen Welt ist. Aber was genau bedeutet das denn, wenn ein Team selbstorganisierend ist?

„Das ist doch ganz einfach“, wird uns oft entgegnet, „das sind Teams, die ihre Arbeit selber organisieren“. Das ist doch schon mal ein Ansatz: Die Arbeit wird anders, „selber“ organisiert. Und was genau damit gemeint sein kann, ob es wirklich nur bei der Selbstorganisation der Arbeit bleibt und welche Konsequenzen das hat, genau damit wollen wir uns in diesem Artikel beschäftigen.

Fangen wir im ersten Schritt mal mit der Definition eines Teils der Fragestellung an, was verstehen wir denn unter einem Team?
Als Team verstehen wir im Folgenden eine Gruppe von Personen, die innerhalb eines Unternehmens gemeinsam eine bestimmte Aufgabe zu erfüllen haben. Dabei kann es sich grundsätzlich sowohl um interdisziplinäre Projektteams handeln, die bestimmte Projektziele erreichen sollen wie auch um Funktionsgruppen, wie beispielsweise die Systembetreuung eines Unternehmens, die bestimmte Maintenanceaufgaben wahrnehmen. All diesen Teams ist gemeinsam, dass das Team als solches eine bestimmte Aufgabe hat und die Teammitglieder zur Erreichung dieser Aufgabe miteinander interagieren.
Da derzeit meistens noch im Zusammenhang mit agiler Softwareentwicklung von selbstorganisierenden Teams gesprochen wird, werden wir uns in diesem Artikel manchmal auf softwareentwickelnde Projektteams beziehen. Die meisten der besprochenen Aspekte gelten jedoch auch für alle anderen Arten von Teams.

Wenn wir von selbstorganisierende Teams sprechen, was ist denn dann eigentlich ein nichtselbstorganisierendes Team, von dem wir uns ja jetzt scheinbar abgrenzen möchten?
Für diese Definition bietet sich die klassische Art der Teamorganisation an, die wir heute noch in den meisten Organisationen beobachten können. Eine Gruppe von Personen, die von einem Teamleiter geführt wird und in der jedes Teammitglied die Aufgaben durchführt, die ihm von seinem Teamleiter zugeordnet werden. Und dabei werden sowohl der Zeitpunkt wie auch die Art der Durchführung vom Teamleiter oder anderen organisatorischen Vorgaben vorgegeben. Der Großteil der Verantwortung und das Wissens über die Zusammenhänge liegen dabei beim Teamleiter, wofür er ja oft auch besser bezahlt wird. Diese Form der Teamorganisation zu diskreditieren, wollen wir uns an dieser Stelle ersparen. Welche Folgen sie haben kann (und ich möchte hier betonen, dass wir hier von können und nicht von müssen sprechen), ist Ihnen als Leser dieses Artikels selber schon bekannt.

Kommen wir also endlich zu dem, was uns wirklich interessiert, was bedeutet das Selbstorganisieren bei selbstorganisierenden Teams? Vorweg die Anmerkung, dass es dafür keine DIN Norm gibt und auch keine andere verbindliche Vorschrift, wann ein Team als selbstorganisierend gilt und wann nicht. Wir werden gleich eine Reihe von Aspekten besprechen, die Teil der Selbstorganisation eines Teams sein können. Welche davon dann für ein spezielles Team wirklich Sinn machen, hängt immer von den Umständen ab, unter denen dieses Team arbeiten muss und ist mit gesundem Menschenverstand zu entscheiden. Bedenken sie dabei, die Selbstorganisation ist kein Selbstzweck und es gibt auch keinen Orden dafür. Das warum des Ganzen wollen wir uns später ansehen.

Wir hatten es bereits am Anfang, ein wichtiger Punkt bei der Selbstorganisation ist die Organisation der Arbeit. Oder auch: Wer macht Was Wann! Beim wer macht was geht es erst mal darum, wer überhaupt was machen kann. Es gibt gerade bei Projektteams zwei extreme Ausprägungen für die Verteilung der notwendigen Fähigkeiten im Team: Spezialisten oder Generalisten.
Im ersten Fall kann jede notwendige Tätigkeit oft nur von einer, wenn das Team Glück hat von zwei Teammitgliedern ausgeführt werden. Damit beantwortet sich die Frage nach dem wer macht was quasi automatisch. Im zweiten Fall kann jeder im Team alles, das bedeutet, jede notwendige Tätigkeit kann von jedem Teammitglied in einer verantwortbaren Qualität durchgeführt werden. Ein hoher, aber nicht unmöglicher Anspruch, vor allem wenn man ihn dadurch etwas abmildert, das alle notwendigen Tätigkeiten nur von mindestens zwei oder besser drei Teammitgliedern ohne Qualitätsverlust durchführbar sein müssen.
Die Form der Selbstorganisation liegt darin, dass das Team selber entscheidet, welche Ausprägung der Wissensverteilung es wählen möchte, eher die Spezialisierungen oder doch die Generalisierung. Und das Team ermittelt auch selber welche Tätigkeiten für die erfolgreiche Erfüllung aller Teamaufgaben notwendig sind und welche Skills dafür im Team zur Verfügung stehen müssen. Wird externes Knowhow benötigt, ist es Aufgabe des Teams zu beschreiben, was genau benötigt wird, der eigentlichen Einkauf wird in der Regel dann jedoch durch andere Stellen im Unternehmen erfolgen. Geht es dabei jedoch um die Einstellung neuer Mitarbeiter für das Team, dann sollte das Team ein Mitspracherecht bei der Entscheidung haben. Denn das Team kann am besten beurteilen, ob ein neuer Mitarbeiter sowohl vom fachlichen wie auch sozialen Skill ins Team passt.
Entscheidet sich das Team eher für die Variante der generalisierten Wissensverteilung, dann liegt es auch in der Verantwortung des Teams für die notwendige Verteilung des Wissens zu sorgen. Das kann durch schriftliche Dokumentation erfolgen oder durch regelmäßige Vorträge im Team oder durch konsequente Zusammenarbeit von immer zwei Kollegen bei der Durchführung von Aufgaben (in der Softwareentwicklung auch als Pair Programming bezeichnet). Wichtig ist hierbei, dass Wissen, dass noch verteilt werden muss konsequent identifiziert wird. In einem mir bekannten Team führen wir hierfür regelmäßig eine sogenannte Truck-Faktor-Analyse durch. Das bedeutet wir analysieren für jedes Teammitglied, welche Auswirkungen hätte es für das Team wenn der Mitarbeiter morgen von einem LKW (Truck) überfahren würde und damit von heute auf morgen dem Team unwiderruflich nicht mehr zur Verfügung stände. Natürlich können Sie das bei sich auch weniger brachial formulieren, z.B. der Kollege ist wegen Steuerschulden über Nacht aus dem Land geflohen und nun nicht mehr auffindbar oder ähnliches. Sie verstehen schon, worauf es ankommt. Und dann überlegen Sie, ob ohne diesen Kollegen notwendige Tätigkeiten im Team nicht oder nur mit Schwierigkeiten durchführbar wären. Und wenn ja, beschließen Sie, wie Sie das vermeiden können.

Damit ist schon mal die Frage geklärt, wer KANN was. Jetzt kommen wir zur Frage zurück, wer MACHT was. Von außen werden Anforderungen an das Team gestellt. Ein selbstorganisierendes Team bricht die Anforderung in tatsächlich durchzuführende Tätigkeiten (auch als Tasks bezeichnet) runter, gibt sofern gefordert Aufwandsschätzungen ab und verteilt die dadurch entstehende Arbeit innerhalb des Teams. Diese Verteilung der Arbeit kann dadurch geschehen, dass das Team sich regelmäßig oder bei Bedarf trifft und im Gespräch die Aufgaben verteilt oder aber auch durch bestimmte Mechanismen, die allerdings ebenfalls vom Team bestimmt werden. So ein Mechanismus ist zum Beispiel einen Teamwand wie bei Scrum oder Kanban, auf der die anstehenden Tasks aufgeführt sind und die Teammitglieder je nach Verfügbarkeit sich die Aufgaben selber nehmen.

Dann haben wir gerade gesehen, dass eventuell geforderte Aufwandsschätzung vom Team selber erstellt werden und nicht von jemand außerhalb. Das ist sofort einsichtig, da nur der, der die Aufgabe durchführen soll auch wirklich sagen kann, wie lange er dafür brauchen wird. Wenn wir das jetzt noch damit kombinieren, dass das Team selber organisiert, wer was macht, dann ist natürlich sofort klar, dass das Team auch bei der eigentlichen Projektplanung eine wesentliche Rolle spielt. In Scrum ist das beispielsweise durch das Sprint Planningmeeting gelöst. Der Product Owner, ein Produktmanager, Anforderungsmanager oder wie auch sonst die Rolle bezeichnet wird, die dafür verantwortlich zeichnet fachliche Anforderungen anzunehmen, zu bewerten und zu priorisieren stellt dem Team vor, welche fachlichen Anforderungen/Aufgaben in welcher Priorität zu erfüllen sind. Und das Team bestimmt anschließend, welche Tätigkeiten und Aufwände sich daraus ergeben und bis wann diese durchführbar sind, bzw. welche Aufgaben innerhalb eines bestimmten Zeitraums erfüllt werden können.
Klingt verwirrend und aufwändig? Wenn ich unbedingt für die nächsten 24 Monate planen möchte bestimmt. Dann doch besser als einzelkämpfender Projektleiter alleine die Planung machen? Wenn Sie damit bessere, realistischere Projektpläne bekommen, lassen Sie mich es bitte wissen 🙂 Doch das ist eine andere Diskussion.

Was ist, wenn absehbar ist, dass das Team die aktuelle Planung nicht einhalten kann? Traditionell greift nun ein Projektleiter/Teamleiter ein und verordnet Maßnahmen. Nicht bei selbstorganisierenden Teams. Wir kommen später noch zu dem Punkt der Übernahme von Verantwortung durch Team und Teamitglieder. Auch hier ist das Team gefordert zu entscheiden, welche Maßnahmen sinnvoll erscheinen um entweder die Planung doch noch erfüllen zu können oder die Auswirkungen durch die Nichterfüllung zu minimieren. Das kann selbstverordnete Mehrarbeit sein, die Reduzierung der technischen Ansprüche an die Lösung (halt im ersten Schritt nicht das superneue supercoole Framework von XY einsetzen sondern erstmal was bewährtes) oder die Konzentration auf die wichtigsten fachlichen Features.

Was fällt noch unter die Selbstorganisation? Da fällt zum Beispiel auch die Art, wie gearbeitet wird drunter. Bei Softwareentwicklern sind das zum Beispiel Programmiervorgaben, welche Tools verwendet werden, Dokumentation im Code, welche Tests sind zu schreiben bzw. durchzuführen, welche weiteren Maßnahmen sind zur Erhöhung der Arbeitsqualität einzuhalten wie beispielsweise Pair Reviews oder Test Driven Development, Continous Integration oder die Wahl der Iterationslänge.

Was das Team möglicherweise auch selber regeln kann ist die Anwesenheit. Ja, es gibt Situationen und Umstände, in denen die unternehmens- oder bereichsweite Vorgabe von Kernarbeitszeiten Sinn macht. Und in vielen Fällen sind diese Vorgaben leider nur einer formalistischen Denkweise geschuldet. Wenn ein Team in einer bestimmten Phase keine Schnittstellen zu anderen Mitspielern hat oder diese nicht zeitnah benötigt werden, was spricht dann dagegen, dass das Team nachts arbeitet wenn dieses dem Team entgegen käme. Oder die Teammitglieder zeitversetzt arbeiten, solange diese ihre Arbeit untereinander ohne Verlust von Qualität und Zeit koordiniert bekommen? Wenn die Verantwortlichen dem Team unterstellen, dass es im Sinne des Unternehmens denkt, dann können sie dem Team die Entscheidung über die Arbeitszeiten ruhig selber überlassen. Und das schließt auch die Entscheidungen darüber ein, wer wann in Urlaub gehen kann.

Als letztes wollen wir noch die Selbstorganisation der Kommunikation im Team betrachten. Ein selbstorganisierendes Team bestimmt selber darüber, wie es innerhalb des Teams kommuniziert. Damit ist zum Beispiel gemeint, dass das Team festlegt ob es Teammeetings braucht und falls ja wie oft und lang diese sein müssen. Oder wie mit Problemen im Team umgegangen wird, seien es technische oder zwischenmenschliche. Hat ein Teammitglied beispielsweise ein technisches oder fachliches Problem, dann kann es eine Teamvereinbarung sein, dass er formlos eine Quick Design Session einberufen kann Auf der könnte er die anderen Teammitglieder zum Rat oder ihre Meinung bitten. Und es gehört auch zur Teamvereinbarung, ob die Teilnahme an solchen Quick Design Sessions Pflicht ist oder eben nicht.

Wir haben jetzt eine ganze Reihe von möglichen Aspekten der Selbstorganisation eines Teams gesehen. Und allen gemeinsam ist, dass mit Ihnen nicht nur die Freiheit der Entscheidung einhergeht sondern auch die Übernahme von Verantwortung. Befragt man die Entscheider in Unternehmen, ob sie selbstorganisierende Teams einführen möchten, so bekommt man oft zögerliche oder sogar direkt ablehnende Antworten. Der zumeist unausgesprochene Grund dafür ist meist die Annahme, dass die Teams die Freiheit der Entscheidung zum Nachteil des Unternehmens ausnutzen würden. Die Motivation oder Kompetenz zugetraut im Sinn des Unternehmens zu agieren wird oft erst den Team- oder Projektleitern zugetraut.

Die Einführung selbstorganisierender Teams bedingt also den Paradigmenwechsel, dass alle Mitarbeiter des Unternehmens motiviert und befähigt sind, eigenverantwortlich im Sinne des Unternehmens zu agieren. Und dazu gehört auch, dass das Team selber die Verantwortung für die erfolgreiche Bewältigung der Aufgaben übernimmt. Und hier ist mit Team nicht irgendein abstraktes Gebilde gemeint, sondern jedes einzelne Teammitglied muss sich diese Verantwortung zu Eigen machen. Das kann bei Teams, in denen die einzelnen Mitglieder unterschiedliche Ansichten bezüglich der Übernahme von Verantwortung und damit dann auch dem Einsatz zum Erreichen der gemeinsamen Ziele haben, schnell zu interessanten Spannungen führen. Hier setzt ein gruppendynamischer Effekt ein, in dem sich rasch herauskristallisiert, wer „mitzieht“ und wer nicht. In den meisten Fällen wird das Team das intern regeln können und sollte dazu auch die Chance bekommen. „Regeln“ bedeutet dabei oft, dass sich in den gruppeninternen Diskussionen klärt, warum der eine oder andere nicht motiviert genug ist, den notwendigen Einsatz zu zeigen. Und es zeigt sich, ob durch Anpassung der internen Organisation nicht doch alle zufrieden gestellt werden können, oder eben auch nicht. Gruppenzwang ist dabei ein hässliches Wort und meistens auch ein bisschen überzogen. Aber manchmal wirkt er auch Wunder.

Und was mache ich, wenn ich doch einen unverbesserlichen Querschläger im Team habe, der durch seine Verweigerung den Erfolg des Teams und die Gemeinschaft an sich gefährdet? Was machen Sie denn in einem traditionellen Team mit so jemand? Wenn Sie ausreichend taff sind, dann entfernen Sie ihn aus dem Team, in den meisten Fällen wird er jedoch einfach als Ballast geduldet und mitgeschleppt. Ist das wirtschaftlich und hilft es dem Unternehmen? Steigert es die Motivation und Zufriedenheit der restlichen Mitarbeiter? Nein, definitiv nicht! In einem selbstorganisierenden Team wird es aufgrund der verstärkten Gruppeneffekte schwierig, so jemand zu dulden. Bleibt also nur, das Problem endgültig zu lösen. Klingt hart? Ist es auch, jedoch nur für den Verweigerer. Der Rest profitiert.
Nur damit wir uns richtig verstehen, dass ist nicht der Aufruf zu „wer nicht richtig funktioniert, der fliegt“. Die Selbstorganisation in Teams räumt allen Beteiligten wesentlich mehr Möglichkeiten ein, genau die Form des Einsatzes zu zeigen, die ihm jeweils am besten liegt. Und führt damit fast automatisch zu einer wesentlich höheren Motivation. Und auch individuelle Defizite wie fehlende Skills oder das jemanden bestimmte Tätigkeiten „einfach nicht richtig liegen“ können in einem solchen Team wesentlich besser aufgefangen werden. Das Team als Gemeinschaft findet selber raus, wie die individuellen Fähigkeiten jedes Einzelnen am besten genutzt werden können und wie das Team davon am besten profitiert. Und auch wie jeder sich im Team konstant verbessern und damit auch seinen eigenen Marktwert steigern kann. Und das sollte doch Anreiz genug sein. Noch sozialer geht es wohl kaum.

So, nachdem wir jetzt gesehen haben, welche Rechte zur Selbstbestimmung ein selbstorganisierendes Team haben sollte, welche Ansprüche darf umgekehrt der Projektleiter, Teamleiter, Produktmanager, Abteilungsleiter, etc. an das Team haben?
Nun als erstes Transparenz. Wir haben gerade noch davon gesprochen, dass für selbstorganisierende Teams Vertrauen durch die Verantwortlichen ins Team bzw. die Teammitglieder notwendig ist. Dieses Vertrauen ist wesentlich leichter aufzubringen und aufrechtzuerhalten, wenn für die Außenstehenden die Prozesse im Team und die Regeln, nach denen das Team agiert nachvollziehbar sind. Wenn ich als Vorgesetzter wissen möchte, wie das Team intern die Arbeit verteilt, dann ist die Antwort „Machen Sie sich keine Sorgen, wir regeln das schon irgendwie“ nicht besonders vertrauenerweckend. Am besten veröffentlicht das Team seine Regeln pro aktiv, z.B. in einem firmeninternen Wiki. Spätestens aber auf Anfrage sollten die aktuellen Regeln verständlich und vollständig kommuniziert werden.

Ein weiterer Punkt ist, wer die Aufgaben des Teams festlegt. Teams, und auch selbstorganisierende Teams, sind kein Selbstzweck, sondern haben ihre Daseinsberechtigung immer in den Aufgaben, die sie erfüllen sollen. Und die Aufgabe wird dort festgelegt, wo das Geld herkommt. In Köln sagen wir dazu: „Wer die Musik bestellt, der bestimmt auch was sie spielt“. Wenn sich die Aufgaben für das Team ändern oder weitere Aufgaben hinzukommen und das Team das Gefühl hat, für diese neuen Aufgaben eigentlich nicht richtig zu sein, dann kann es natürlich die Verantwortlichen darauf hinweisen. Ein grundsätzliches Verweigerungsrecht besteht aber zumindest in meinem Modell von Welt nicht. Das ist nicht anders, als bei traditioneller Teamorganisation.
Das wird besonders deutlich bei Projektteams, die während der Projektphasen laufend mit neuen Anforderungen konfrontiert werden. Die Auswahl, welche Anforderungen umzusetzen sind und in welcher Priorität, bestimmt der verantwortliche Projektleiter oder Produktverantwortliche. Das Team bestimmt dann darüber, wie die Umsetzung geschieht und wie lange es dauern wird.

Da wo es Sinn macht, gelten natürlich auch unternehmensweite Vorgaben bzgl. der Systemlandschaft, der Architektur, der zu verwendenden Tools und Dokumentations- und Qualitätsvorschriften. Die Betonung liegt jedoch tatsächlich auf „da wo es Sinn macht“. Prüfen Sie in Ihrem Unternehmen mal kritisch, welche der bestehenden Vorschriften tatsächlich unternehmensweit Sinn machen. Die zu verwendenden Tools aus Lizenzgründen einzuschränken kann Sinn machen. Auch die Systemlandschaft zentral reguliert übersichtlich zu halten macht Sinn. Einheitliche Qualitätsstandards finde ich sogar besonders gut. Wobei allerdings hier schnell die Frage aufkommen kann, wie sich dieses Qualitätsstandards einheitlich für ein größeres Unternehmen definieren lassen. Und zwar so, dass wirklich Qualität erzeugt wird und nicht nur unnötige Arbeit in den Teams. Und bei einheitlichen Dokumentationsrichtlinien fangen die meisten Unternehmen schon an mit Kanonen auf Spatzen zu schießen (meist durch wichtige Unternehmensberater dazu aufgestachelt). Und unternehmensweite Programmierrichtlinien sind fast immer mehr schädlich als nützlich. Ich verstehe die gute Absicht hinter all diesen Vorgaben. Aber das Gegenteil von Gut ist oft nicht Böse sondern gutgemeint.

Kommen wir mal zu einer anderen interessanten Frage: Braucht ein selbstorganisierendes Team eigentlich noch einen Teamleiter? Teamintern hat er ja eigentlich keine Aufgaben mehr: Er verteilt nicht die Arbeit, er muss den Urlaub nicht regeln, keine Zeitpläne oder Arbeitsergebnisse kontrollieren. Also unnötig, oder? Nun, nicht so ganz. Der Großteil der Unternehmen ist immer noch streng hierarchisch und meist recht unflexibel organisiert. Und in diesem Umfeld müssen sich dann auch die selbstorganisierenden Teams bewegen. Das bedeutet, dass sie klar definierte Ansprechpartner für die Welt außerhalb des Teams haben müssen. Der Teamleiter ist also kein Vorgesetzter mit Weisungsbefugnis mehr sondern eher ein Dienstleister, der als Schnittstelle und Koordinator für das Team fungiert.

Und wie verhält sich das mit der disziplinarischen Führung bei selbstorganisierenden Teams? Die disziplinarischen Führung beinhaltet in Unternehmen in der Regel die Entscheidungen darüber, wer in eine Organisationseinheit (z.B. das Team) kommt und wer nicht, bzw. diese Einheit verlassen muss, die Beurteilung von Mitarbeitern und das Gehalt derselben.
Bezüglich der Zusammensetzung des Teams, also Einstellung und Entlassung von Teammitgliedern, hatten wir schon gesehen, dass das Team hier ein Mitspracherecht haben sollte. Beim Gehalt gelten die gleichen Regeln wie sonst auch mit einer Ausnahme: Bei variablen Gehaltsanteilen die mit der Erreichung von individuellen Zielen gekoppelt sind, ist darauf zu achten, dass diese individuellen Ziele nicht im Widerspruch zu den aktuellen Teamregeln stehen oder die schon besprochenen Möglichkeiten des Teams zur Selbstorganisation einschränken. Wenn ein Teammitglied als individuelle Vorgabe die Spezialisierung auf ein bestimmtes Thema bekommen hat, das Team aber bei der Wissensverteilung auf Generalisten setzt, dann besteht hier ein Widerspruch der entweder die Teamvereinbarung gefährdet oder aber den variablen Gehaltsanteil des Mitarbeiters. Besser ist es die variablen Gehaltsanteile an Teamziele zu koppeln, Ziele die das Team als ganzen erreichen kann und deren Erreichen damit auch positive Effekte für alle Teammitglieder haben.

Zum Schluss die Königsfrage: Warum sollten Teams selbstorganisierend sein und macht das wirklich bei allen Teams Sinn?
Einen Teil der Vorteile von selbstorganisierenden Teams können wir schon den Argumentationen weiter oben entnehmen. Die stärkere Übernahme von Verantwortung durch das Team selber und die einzelnen Teammitglieder. Die damit verbundene bessere Motivation und die gruppendynamischen Effekte, die in der Regel zu höherer Effektivität führen. Die Selbstregulierungskräfte eines solchen Teams, das fast automatisch die Fähigkeiten der einzelnen Mitglieder optimal einsetzen und die Defizite ausgleichen wird.

In klassischen Teams mit zentraler Führung ist der Teamleiter schnell ein Flaschenhals, wenn es an ihm liegt die Arbeit im Team zu verteilen und zu kontrollieren. Selbstorganisierende Teams neigen dazu, auftretende Flaschenhälse schnell zu identifizieren und zu beseitigen. Dazu ist es übrigens von Vorteil in selbstorganisierenden Teams die agile Denkweise des „inspect and adapt“ zu verankern. In der klassischen Organisationslehre neigen wir dazu Regeln immer als für die Ewigkeit zu betrachten und den Umstand, dass Regeln geändert werden müssen als Versagen anzusehen. Deshalb ist das Erstellen von Regeln oft so komplizierter Akt, weil ja nicht falsch gemacht werden darf und führt so oft zu umfangreichen komplexen Regelwerken, die möglichst jede Eventualität berücksichtigen sollen. Nicht so in der agilen Denkweise. Einfache Regeln erstellen, die Regeln anwenden, beurteilen ob die Regeln zu den gewünschten Ergebnissen führen, wenn notwendig die Regeln anpassen, usw.
Durch dieses Vorgehen entsteht im Team automatisch ein kontinuierlicher Verbesserungsprozess, durch den das Team auch bei sich ändernden Rahmenbedingungen die maximale Leistungsfähigkeit behält.

Ein kleiner Nachteil der selbstorganisierenden Teams ist, dass sie in der Anlaufphase etwas langsamer sind. Wird so ein Team neu aufgebaut, dann muss die Gruppe erst mal anfangen einen ersten Wurf von Regeln zu definieren und auszutesten, welche Regeln die besten Ergebnisse erzielen. Und dass wird anfangs von vielen ausufernden Diskussionen im Team begleitet sein. Vor allem wenn sich die Teammitglieder vorher noch nicht kannten wird das einen recht intensiven Prozess des sich gegenseitig kennenlernen beinhalten. Und dann wird das Team nach und nach Fahrt aufnehmen. Das bedeutet aber im Gegenzug, dass die Selbstorganisation eher ungünstig für Teams mit hoher personeller Fluktuation ist oder zeitlich nur stark begrenzter Lebensdauer.

Um abschließend auf die erste Formulierung zurückzukommen: Ja, selbstorganisierende Teams sind Teams, die ihre Arbeit selber organisieren. Und eben auch noch mehr!

Vortrag ‚Practical Scrum‘ in Venlo

Montag, 26. April 2010 von  
unter News

Am 2. Juni 2010 wird Carsten Czeczine vor den Studenten der Fontys University of Applied Sciences in Venlo den Vortrag ‚Practical Scrum‘ halten. Das ist ein Grundlagenvortrag über Scrum für das Frühjahrssemester. Weitere Informationen gibt es hier.

Die Sprint Retrospektive

Montag, 14. Dezember 2009 von  
unter Fachartikel Scrum

Laut Wikipedia bezeichnet Retrospektive im Allgemeinen einen Rückblick. Dementsprechend ist eine Sprint Retrospektive ein Rückblick auf den gerade abgelaufenen Sprint.

Die Sprint Retrospektive findet nach dem Sprint Review, in dem die Sprint Ergebnisse präsentiert wurde statt und schließt damit den Sprint ab.Ziel der Retrospektive ist die Verbesserung des Scrum Prozesses. Und da wir in Scrum neben dem reinen Prozess auch Wert auf den sozialen Umgang zwischen allen Beteiligten legen, gehört auch dies mit in die Retrospektive.

„Der Inhalt“

Also, was wird in einer Sprint Retrospektive besprochen?

Beispiele:

– Arbeitet das Projekt erfolgreich?

– Werden die Sprintziele erreicht?

– Betrachtung der einzelnen Prozessschritte, wie z.B. das Daily Scrum oder der Sprint Review.

– Werden die Prozessschritte eingehalten?

– Sind die Ergebnisse der Prozesschritte das, was erwartet wurde?

– Welche Ergebnisse werden denn erwartet?

– Wenn Prozessschritte nicht durchgeführt werden, warum ist das so?

– Was müsste sich ändern, damit sie eingehalten werden? Oder besteht überhaupt die Notwendigkeit, sie einzuhalten.

Ganz klassisch kann hier z.B. auch darüber reflektiert werden, ob die Zeitfenster für die Prozessschritte noch angemessen ist. Wenn das Sprint Planning Meeting zum Ende hin immer hektisch wird, weil die Zeit ausgeht bevor das Sprint Backlog vollständig ist, dann könnte hier z.B. festgehalten werden, dass das Meeting eine Stunde länger angesetzt werden muss. Oder auch genau umgekehrt.

Oder z.B. die tagtäglichen Arbeitspraktiken: Werden die Codierstandards eingehalten und wenn nicht, warum? Fehlen Standards/Vorgaben und wenn ja, welche? Unterstützt die verwendete Technologie noch die Anforderungen im Projekt?

Und dann halt auch das Soziale: Wo gibt es zwischenmenschliche Reibungen und warum? Wo scheint Kommunikation zu fehlen oder nicht ausreichend zu sein und warum? Gibt es evtl. Probleme bei den Vorstellungen über die Arbeitszeiten? Und so weiter.

Und Verbesserungen werden in der Regel ja nicht dadurch erzielt, dass man mal darüber gesprochen hat sondern nur durch konkrete Maßnahmen. D.h. als Ergebnis einer jeden Retrospektive müssen konkrete Maßnahmen vereinbart worden sein, die die Verbesserung des Scrum Prozesses zum Ziel haben.

„Die Teilnehmer“

Aus diesem Inhalt ergibt sich schon so ein bisschen die Teilnehmergruppe der Sprint Retrospektive. Teilnehmer sind auf jeden Fall das komplette Team, der Scrum Master und der Product Owner. Weitere Teilnehmer wie z.B. Stakeholder können hinzukommen, dabei gelten aber zwei wichtige Regeln:

  1. nur wenn die weiteren Teilnehmer aktiv zur Prozessverbesserung beitragen können. D.h. sind diese Personen notwendig um Probleme identifizieren oder lösen zu können? Einfach nur Zuschauer sind eher nicht gewünscht. Dafür können die Daily Scrums oder Sprint Reviews benutzt werden.
  2. Alle Teammitglieder, der Scrum Master und Product Owner müssen einverstanden sein. Dabei muss eine Ablehnung auch nicht ausführlich begründet werden. In Retrospektiven kann es, gerade wenn es um soziale Probleme geht, schnell ans Eingemachte gehen und das möchte nicht jeder vor Außenstehenden machen.

Zusammenfassend kann man sagen: So viele wie nötig, so wenig wie möglich.

„Die Dauer“

Wie lange soll die Retrospektive denn dauern?

Wir erinnern uns, dass wir in Scrum ja fast alles in festen Zeitboxen machen. Als Faustformel würde ich sagen, bei einer Sprintlänge von zwei Wochen anfangs jeweils einen halben Tag. Einigen mag das ziemlich lange vorkommen, aber gerade am Anfang eines Projektes wird es ziemlich viel Justierungsbedarf geben und die Retrospektive ist das Werkzeug dafür, um das Projekt im Doing (nicht im Bezug auf die Anforderungen) auf Kurs bringen zu können. Wenn der Justierungsbedarf nachlässt, d.h. in der Retrospektive kommen nichtmehr genug „echte“ Themen auf, um wirklich den halben Tag auf Dauer zu benötigen, dann kann die Zeitbox entsprechend verkürzt werden. Das ist übrigens etwas, was in der Retrospektive als Ergebnis entstehen kann.

Und jetzt wird es noch ein paar geben, die einen halben Tag zu wenig finden. Die mögen aber bedenken, dass die Retrospektive ja in jedem Sprint stattfindet, hier also alle zwei Wochen. Und in der Regel entstehen auch nicht in jedem Sprint so viele neue Probleme oder Umstände, dass jeweils ein halber Tag zur Reflektion benötigt wird. Anfangs vielleicht ja, weil vieles neu ist aber das sollte sich zügig ändern. Und deshalb ist es auch nicht notwendig, dass am Ende jeder Retrospektive alles geklärt sein muss. Offene Themen werden dann halt in die nächste Retrospektive mitgenommen und dort weiter bearbeitet.

„Wo“

Es empfiehlt sich übrigens, wie bei den meisten Meetings, sich für die Retrospektive einen möglichst störungsfreien Raum zu suchen, in dem alle Teilnehmer ausreichend Platz und Sitzgelegenheiten haben und auch Platz für Teamarbeiten an einer Metaplanwand oder Whiteboard sind. Auf Beamer und Rechner würde ich übrigens großzügig verzichten, da dieses selten die Teamarbeit fördert.

„Die Moderation“

Ja und dann ist noch die Moderation der Retrospektiven zu klären. Ein externer Moderator, der der Situation völlig unbelastet gegenübersteht und eventuell, weil er das hauptberuflich macht auch das größtmögliche Maximum an Moderationserfahrung mitbringt, wäre natürlich das schönste. Aber machen wir uns nichts vor, die Wahrscheinlichkeit dass ein Unternehmen alle zwei Wochen einen externen Moderator finanzieren wird tendiert eher gegen Null.

In der Regel wird es also eher der Job des Scrum Masters sein, die Retrospektive zu moderieren und normalerweise sollte das auch mehr aus ausreichend sein. Sinn macht das Extrainvestment in einen externen Moderator gegebenenfalls für die ersten ein zwei Retrospektiven, wenn der Scrum Master noch wenig Erfahrung in der Moderation hat, sodass er sich hier was abschauen kann. Oder wenn die sozialen Probleme im Projekt anwachsen und der Scrum Master entweder selber involviert ist und damit eine unvoreingenommene Moderation nicht möglich ist oder er sich das Moderieren in dieser Situation noch nicht zutraut. Letzterer Grund ist übrigens kein Grund zur Schande. Ganz im Gegenteil, wenn der Scrum Master dies ehrlich eingesteht und Hilfe anfordert anstatt es doch selber zu probieren und die Situation möglicherweise damit noch verschlimmert. Wir erinnern uns: In Scrum werden Probleme immer offengelegt und aktiv angegangen.

„Der Ablauf“

Wie läuft nun so ein Sprint Retrospektive konkret ab:

Noch vor der ersten Retrospektive oder direkt als erstes der ersten Retrospektive müssen die Grundregeln/Grundprinzipien vereinbart werden. An folgenden Regeln führt für erfolgreiche Retrospektiven eigentlich kein Weg vorbei:

  1. Gegenseitiger Respekt
  2. Ehrliche Kommunikation
  3. Trennung von Person und Sache

Diese Regeln müssen von allen akzeptiert werden und jeder Teilnehmer hat jederzeit das Recht, sich auf diese Regeln zu berufen.

Weitere Regeln können dann individuell vom Team vereinbart werden.

Wenn das geklärt ist, dann kann es losgehen.

Es gibt nicht DIE Vorgehensweise oder Art, eine Retrospektive durchzuführen. Maßgeblich sind eigentlich nur die gerade genannten Grundregeln und das am Anfang benannte Ziel, konkrete Maßnahmen zur Verbesserung des Scrum Prozesses zu erarbeiten. Wer sich hier ein bisschen tiefer einarbeiten möchte, dem empfehle ich das Buch „Agile Retrospectives: Making Good Teams Great“ von Esther Derby und Diana Larsen. Einen Link dazu stelle ich in die Show Notes.

Fürs erste möchte ich hier jetzt eine Vorgehensweise vorstellen, mit der wir in meinem aktuellen Projekt erfolgreich arbeiten.

Die Retrospektive gliedert dabei auf in vier Phase: Einführung, Datensammlung, Themenbearbeitung und Abschluss.

In der Einführung erklärt der Moderator nochmal kurz die Zielsetzung, den Ablauf und die Regeln. Hier holt der Moderator vom Teilnehmerkreis auch das Commitment für Ziel, Ablauf und Regeln ein und ggfs. können hier noch Abweichungen gemeinsam festgelegt werden.

Anschließend erklärt jeder Teilnehmer kurz, wie er sich fühlt und was er von dem Meeting erwartet. Alternativ kann auch jeder Teilnehmer seine Stimmung ausdrücken, indem er auf einem Stimmungsbarometer an einer Wand einen Punkt klebt oder Strich macht und somit die Gesamtstimmung im Team visualisiert wird. Das ganze dient gleichzeitig zur Auflockerung und zur Einstimmung auf das Thema.

Bei der Datensammlung wird gesammelt, was den so im letzten Sprint passiert ist und welche Probleme das Projekt derzeit hat. Das können neu aufgetretene Probleme sein oder aber auch ältere, die das Projekt schon länger ungelöst mit sich rumschleppt.

Eine Methode, um das zu erreichen ist Mad Sad Glad. Als erstes schreiben alle Teilnehmer Karten mit positiven und negativen Ereignissen. Das kann man von der Anzahl völlig offen lassen oder z.B. auch auf jeweils 3 positive und negative Karten beschränken (jede Karte aber nur ein Ereignis). Einfach mal ausprobieren, was bei Ihnen besser funktioniert. Jeder Autor markiert seine Karte auch als positiv oder negativ, indem er eine Smiley oder ein Nichtsmiley darauf malt. Alternativ können auch Karten mit unterschiedlichen Farben verwendet werden.

Wenn alle ihre Karten geschrieben haben, dann werden diese an einer Metaplanwand gesammelt. Dazu stellt jeder Teilnehmer nacheinander seine Karten kurz vor und hängt sie dabei an die Wand. Die Betonung liegt dabei auf kurz, keine Romane. Fragen oder Kommentare durch andere Teilnehmer sind nicht erlaubt. Eine Sortierung findet auch noch nicht statt. Natürlich steht es dem Autor frei, seine Karte in die Nähe einer anderen zu hängen, die er als thematisch verwand empfindet, aber das bedeutet erst mal noch nichts.

Dann werden die Karten gemeinsam gruppiert. Dabei wird darüber gesprochen, was genau gemeint ist oder wie es gemeint ist und so weiter. Nach einer Zeit sind die Karten gruppiert und jede Gruppe bekommt eine gemeinsame Überschrift, das Thema der jeweiligen Gruppe.

Ist das geschehen, dann werden die Themen (die Gruppen sind nun zu Themen geworden) gemeinsam priorisiert. Dazu darf jeder Teilnehmer insgesamt drei Klebpunkte an die Themen verteilen, die ihm am wichtigsten sind. Die muss er übrigens nicht alle auf einzelne Themen verteilen, wenn ihm ein Thema ganz besonders wichtig ist, dann kann er auch seine ganzen Punkte an dieses vergeben.

Das Thema mit den meisten Punkten ist das wichtigste, das mit den zweitmeisten das nächstwichtigste und so weiter.

Wir gehen in die Phase Themenbearbeitung über. Dazu betrachten wir kurz nochmal, dass jeder Teilnehmer sowohl positive wie auch negative Karten schreiben durfte. Daraus ergibt sich, dass Themen eine mehr oder weniger starke Tendenz haben werden, als positiver oder negativer Faktor wahrgenommen zu werden.

Es gibt immer mal wieder die Meinung, dass Positives in einer Retrospektive nicht weiter besprochen werden muss, da es ja eh schon gut ist. Das sehe ich anders. Andere vertreten den Standpunkt, dass man aus Gründen der Motivation natürlich auch über Positives reden muss. Auch da bin ich nicht dabei, denn wir wollen in unserer Retrospektive greifbare Ergebnisse erzielen und nicht einfach mal nur drüber reden. Ja, aber was denn jetzt, drüber reden oder nicht? Die Antwort lautet, drüber reden, wenn daraus ein echter Nutzen gezogen werden kann. Nur drüber zu reden, weil es so schön war und man sich damit selber auf die Schulter klopfen kann, ist in einer Retrospektive Zeitverschwendung. Wenn man aber im Gespräch darüber Lehren für andere Bereiche des Projekts ziehen kann oder Möglichkeiten erarbeiten, etwas was gut ist noch besser zu machen, dann wird hier ein echter Mehrwert erzielt. Erfahrungsgemäß werden diese Themen aber erst eine höhere Priorität bekommen, wenn zumindest die drückendsten negativen Themen gelöst sind.

Aber zurück zur Themenbearbeitung. Die Themen werden in der Reihenfolge ihrer Priorität bearbeitet und zwar sowohl die negativen wie auch die positiven. Bei jedem Thema wird von der Gruppe (diesmal sind die Teilnehmer der Retrospektive gemeint, nicht die gruppierten Karten) zuerst die Ursache erarbeitet, also warum ist etwas ein Problem, warum funktioniert etwas nicht oder warum funktioniert etwas so gut. Hierbei kann z.B. die Methode der fünf Warums verwendet werden, bei der fünfmal nach dem Warum gefragt wird. Natürlich nicht fünfmal nach dem gleichen Warum (obwohl stete Wiederholung soll ja auch Lerneffekte erzielen) sondern jede Antwort auf ein Warum wird erneut hinterfragt um damit auf die tieferen Ursachen eines Umstandes zu kommen.

Wenn die Ursache geklärt ist, dann geht es daran konkrete Maßnahmen zu beschließen, die für die Zukunft Verbesserungen bewirken sollen, also einen negativen Effekt zu beseitigen oder zu mindern bzw. einen positiven zu verstärken. Maßnahmen werden vom Moderator schriftlich festgehalten, ein Verantwortlicher aus dem Teilnehmerkreis und ein Zieldatum bestimmt.

Wenn alle Themen bearbeitet sind oder, was wahrscheinlicher ist, die Zeit für diese Phase rum ist, dann kommen wir zum Abschluss der Retrospektive.

Beim Abschluss führen wir quasi eine kleine Retrospektive der Retrospektive durch. Dabei werden gemeinsam kurz folgende Fragen besprochen.

  1. War der zeitliche Rahmen in Ordnung? Retrospektive zu kurz oder zu lang?
  2. Wurden konkrete Ergebnisse erzielt? Wenn nicht sollte dies das Thema der nächsten Retrospektive sein.
  3. War die Art der Durchführung hilfreich?

Die Ergebnisse hieraus gehen direkt in die nächste Retrospektive ein.

„Was noch“

Damit wäre die Retrospektive durch. Aber noch ein paar kleine Hinweise.

Natürlich kann man die beschlossenen Maßnahmen einfach in ein Textdokument schreiben, dass dann niemand mehr beachtet und in Vergessenheit gerät. Mehr Effekt erzielt man jedoch, wenn die Maßnahmen zusammen mit den Verantwortlichen und Terminen groß auf Flipchartpapier geschrieben und offen im Teamraum aufgehängt werden. Das erhöht die Change, dass irgendwas davon auch erledigt wird erheblich. Außerdem sollte zum Beginn jeder Retrospektive der Status der noch unerledigten Maßnahmen abgefragt werden. Wird eine Maßnahme trotz abgelaufenen Termin zum wiederholten Male nicht erledigt, dann kann dies durchaus ein direkt ein Thema für die Retrospektive sein.

Und dann gibt es da noch eine paar Situationen, die in Retrospektiven auftreten können und in denen der Moderator gefordert ist, die Retrospektive zu retten.

Persönliche Angriffe: Wir haben weiter vorne gesagt, eine der Grundregeln für Retrospektiven ist die Trennung von Person und Sache. Normalerweise bedeutet dies, dass über Sachthemen und nicht über persönliches Verhalten diskutiert wird. Da wir in Scrum, wie aber auch schon gesagt, auch die zwischenmenschlichen Aspekte nicht außer Acht lassen, kann es manchmal auch notwendig und zielführend sein, Zwischenmenschliches zu thematisieren. Allerdings muss der Moderator hier viel Fingerspitzengefühl zeigen, bei der Entscheidung, was zulässig ist und was nicht. Haben nur vereinzelte Personen Probleme untereinander, dann sollte der Punkt aus der Retrospektive herausgezogen werden. Die betroffenen Personen sollen evtl. unter Mithilfe eines Moderators das Problem in einer eigenen Runde besprechen und klären. Betreffen die Probleme aber das ganze Team und hemmen die Produktivität des Teams, dann ist das ein Thema für die Retrospektive. Aber auch hier gilt das Grundprinzip des gegenseitigen Respekts. Keine Beleidigungen, Vorwürfe müssen auch belegt werden können, keine unzulässigen Verallgemeinerungen. Bei Verstößen hiergegen muss der Moderator sofort eingreifen und notfalls die Retrospektive auch mal unterbrechen, damit sich die Gemüter auch mal wieder beruhigen können.

Schweigen: Es gibt ja nichts furchtbareres, wenn man eine Retrospektive startet und dann, wenn nach Themen gefragt wird, alle nur schweigen. Es muss nicht so extrem sein, aber wenn Punkte nicht angesprochen werden, obwohl klar ist, dass sie da sind, dann gibt es da scheinbar ein Problem. Meist ist dies ein Vetrauensproblem, entweder in den Sinn der Retrospektive selber, also „Wozu soll das gut sein, dass ändert doch eh nichts“ oder in Anwesende. Sollte der Moderator in diese Situation kommen, dann hilft hier nur doch, auf die Metaebene zu wechseln und die Situation offen anzusprechen. Also klar adressieren, dass er das Gefühl hat, dass nicht alles angesprochen wird und er ein Vertrauensproblem vermutet. Sind Vorgesetzte von Teilnehmern anwesend, so kann dies durchaus der Grund sein. In diesem Fall kann es hilfreich sein, die nächste Retrospektive ohne diese Vorgesetzten durchzuführen und zu sehn, ob es dann besser wird. Als letztes Mittel bleiben dem Moderator nur noch Einzelgespräche, um die Ursachen für das Schweigen zu finden und zu beheben, denn gelöst werden muss dieses Problem. Ohne eine funktionierende Retrospektive kann sich ein Scrumprozess nicht weiterentwickeln und damit das Projekt nicht optimal unterstützen. Bei aller Sorge um eine funktionierende Retrospektive darf der Moderator aber nicht vergessen: In seltenen Fällen gibt es tatsächlich keine oder nur wenige Probleme, die besprochen und gelöst werden müssen. Also bitte nicht dort ein Problem unnötig erzeugen, wo eigentlich keins ist.

Schwafeln: Wenn viel gesprochen wird, ohne dass dabei was Konkretes rauskommt, dann nennt man das schwafeln. So begrüßenswert es ist, wenn die Teilnehmer in der Retrospektive viel reden, wenn einzelne Teilnehmer sich zwar viel mitteilen, dabei aber eigentlich nur heiße Luft erzeugen, dann muss der Moderator auch hier eingreifen und gezielt nach den eigentlichen Inhalten fragen. Zeit ist ein knappes Gut und es sollte gut genutzt werden. Es geht allerdings nicht darum, jede Art von informeller Kommunikation zu unterbinden. Eine Retrospektive sollte durchaus auch Spaß machen. Aber wenn einzelne Teilnehmer anfangen sich zu produzieren und damit massive Zeit für sinnvollen Inhalt vergeuden, dann kann das den Nutzen einer Retrospektive stark beeinträchtigen.

Wenn alle zwei oder vier Wochen konsequent eine Retrospektive durchgeführt wird, dann schleicht sich schnell Routine ein und diese kann auf Dauer die Effektivität einer Retrospektive beeinflussen. Abhilfe schafft hier, den Ablauf und Inhalt der Retrospektiven immer mal wieder zu variieren.

Anstatt die Karten mit den Ereignissen bei der Vorstellung zufällig auf der Metaplanwand zu verteilen, können diese z.B. anhand eines Zeitstrahls zeitlich geordnet werden. Oder man nimmt anstatt eines einfachen Zeitstrahls den Sprint Burndown und vergleicht mal, ob bestimmte Ereignisse evtl. mit Entwicklungen im Sprintfortschritt in Korrelation stehen könnten. Obwohl das teilweise mit Vorsicht zu genießen ist. Oder man ändert ausnahmsweise mal den Fokus einer Retrospektive. Normalerweise werden in einer Retrospektive ja rückblickend die Ereignisse des abgelaufen Sprints bzw. auch der Zeit davor betrachtet. Wenn die aktuellen Probleme im Projekt aber nicht zu drückend sind, dann lenkt man den Fokus mal in die Zukunft. Die Teilnehmer spielen mal zur Abwechslung eine Runde „was wäre wenn“. Alle zusammen formulieren mal, wie ihrer Ansicht nach das Projekt aussähe, wenn die Rahmenbedingungen völlig frei definierbar wären. Dann definiert man, wie die Rahmenbedingungen denn konkret sein müssten und anschließend wird überlegt, was in der tatsächlichen Welt unternommen werden müsste, um auf die idealisierten Rahmenbedingungen zu kommen. Quasi eine legitime Zeit zum Träumen mit dem Anspruch aber hieraus konkreten Projektnutzen zu ziehen.

„Und noch was“

So, jetzt haben wir noch zwei Punkte, über die wir sprechen müssen. Was ist mit unbehandelten Themen und nochmal ein genauerer Blick auf den zeitlichen Rahmen innerhalb der Retrospektive.

Wir hatten es schon angesprochen, nicht alle Themen die bei der Datensammlung aufgekommen sind, werden auch immer in der Themenbearbeitung ihren Platz finden. In vielen Retrospektiven werden hier mehr oder weniger Themen unbehandelt übrig bleiben. Was passiert nun mit diesen? Nun, das kann man unterschiedlich handhaben. Eine Möglichkeit ist tatsächlich, alle unbehandelten Themen wegzuwerfen und bei der nächsten Retrospektive komplett neu anzufangen. Wenn die Themen wichtig waren, dann werden sie auch hier wieder hochkommen. Allerdings besteht hier die Gefahr, dass wenn ein Thema bereits dreimal unbehandelt weggeworfen wurde, es bei der vierten Retrospektive nicht mehr angesprochen wird. „Wird ja sowieso nie behandelt werden“ ist die Denkweise, die sich da schnell einnistet verbunden mit einem gewissen Frust einiger Teilnehmer.

Besser ist es da, die unbehandelten Themen als Startset mit in die nächste Retrospektive zu nehmen. Diese Themen werden zusammen mit allen ihren Karten bereits auf der Metaplanwand angebracht, allerdings wird die Priorität aus der letzten Retrospektive nicht mit übernommen. Diese ist tatsächlich wieder offen. Dann werden in der Datensammlung wieder Ereignisse gesammelt und nun entweder bereits bestehenden Themen zugeordnet oder eben neue Themen gebildet. Und dann wird wieder priorisiert und die Themen wie gehabt bearbeitet. Wichtig ist dabei, dass die Prioritäten wieder offen sind und unter Berücksichtigung der aktuellen Situationen neu vergeben werden.

Kommen wir jetzt nun wirklich zum letzten Punkt, der zeitlichen Einteilung innerhalb der Retrospektive. Grundsätzlich ist natürlich jedes Team völlig frei in der Entscheidung darin, wie viel Zeit es auf was verwenden möchte. Aber man darf natürlich nicht vergessen, dass eine Retrospektive nicht einfach nur ein nettes get-togeher ist, sondern konkrete Ergebnisse erzielen soll. Dementsprechend ist es wenig vorteilhaft, 90% der Zeit mit dem Sammeln von Themen zu verbringen und dann nur noch eine halbe Stunde Zeit zum bearbeiten zu haben.

Ich mache mal einen Vorschlag für den von mir vorgestellten Ablauf bei der Annahme eines zweiwöchigen Sprints und einer halbtägigen Sprint Retrospektive, also vier Stunden.

Einführung: 15 Minuten. Kann beim ersten Mal etwas länger sein, weil hier evtl. die Spielregeln für die Retrospektive geklärt werden müssen und die Teilnehmer noch etwas länger brauchen, um das erste Mal ihre Erwartungen zu formulieren. Aber ab dem zweiten Mal müsste es in 15 Minuten gehen.

Datensammlung: 30 – 60 Minuten. Es hängt ein bisschen davon ab, wie viele neue Themen zu erwarten bzw. wie viele alte Themen schon vorhanden sind. Am Anfang, wenn vieles noch nicht eingespielt ist oder später in turbulenten Zeiten, wenn alle merken, dass es nicht optimal läuft, würde ich eher die 60 Minuten nehmen, denn es ist wichtig, dass die Themen benannt werden. Wenn sich dahingegen in den letzten Retrospektiven gezeigt hat, dass nicht mehr so viele neue Themen aufkommen, sollte der Zeitrahmen für die Datensammlung reduziert werden.

Themenbearbeitung: 120 – 150 Minuten. Die Länge dieses Blocks ist umgekehrt proportional zur Länge der Datensammlung. Je mehr, umso besser, denn nur bearbeitete Themen sind gute Themen.

Abschluss: 15 Minuten. Auch hier gilt, kann beim ersten Mal länger sein, da viel über das Erlebte der ersten Retrospektive verarbeitet werden muss. Also mal lieber 30 Minuten ansetzen. Ab dem zweiten Mal aber nur 15 Minuten. Wenn es deutlich mehr über die eigentliche Retrospektive zu besprechen gibt, dann lohnt es sich evtl. mal eine eigene Retrospektive nur zu diesem Thema zu machen.

Hey, das sind ja nur 3 ½ Stunden. Wir haben doch vier Stunden zur Verfügung! Ja schon, aber ohne gelegentliche Pausen hält das niemand durch. So zwischen Datensammlung und Themenbearbeitung würde ich eine Pause einlegen und dann nochmal eine während der Themenbearbeitung. Aber auch das muss schlussendlich jedes Team selber regeln.

Wichtig bei diesen Einteilungen ist, dass sie allen Teilnehmern klar sind. Der Moderator stellt den Ablauf mit den vorgegebenen Zeiten einschließlich der Pausen in der Einführung vor. Und diese Zeiten sollten als Obergrenzen auch wirklich eingehalten werden. Wenn 60 Minuten Datensammlung angesetzt sind, dann ist nach 60 Minuten auch Schluss. In zwei Wochen ist die nächste Retrospektive, da kann dann weitergemacht werden, aber für aktuelle Retrospektive ist Schluss! Es sind aber wie gesagt Obergrenzen. Wenn nach 45 Minuten bei besten Willen kein echtes neues Thema mehr gefunden werden kann, dann sitzen wir natürlich nicht die restlichen 15 Minuten schweigend da oder machen Unsinn. Wir gehen dann halt eben schon vorzeitig in die nächste Phase über, in diesem Fall hätten wir dann 15 Minuten mehr Zeit für die Bearbeitung der Themen. Ist doch super!

„Geschaft“

Das war es, Sie wissen jetzt alles, was Sie für eine erfolgreiche erste Retrospektive brauchen und haben auch die notwendigen Werkzeuge zur Hand, um Ihre Retrospektiven selber weiter zu entwickeln.

Dies ist das Skript der Episode „Die Sprint Retrospektive“ des Podcasts Scrumidable vom 13.12.2009.