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.

Kanban Vortrag bei der RheinJUG im Februar 2011

Samstag, 8. Januar 2011 von  
unter News

Am 3. Februar 2011 hält Carsten Czeczine einen Grundlagenvortrag über Kanban bei der RheinJUG in Düsseldorf. Alle Informationen zu diesem Termin gibt es hier.

Update: Der Vortrag ist mittlerweile gehalten und er hat ganz eindeutig nicht nur Carsten Czeczine viel Spass gemacht. Die Resonanz war sehr gut. Hier finden Sie die Nachlese zum Vortrag vom Veranstalter.
Und hier die Präsentationsunterlagen als PDF.

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!

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.

Prioritäten von Anforderungen – Kategorie oder Reihenfolge?

Freitag, 6. November 2009 von  
unter Fachartikel Scrum

Ein typisches Problem in jedem Projekt (nicht nur in der Softwareentwicklung) ist die Frage der Prioritäten der Anforderungen. Was muss zuerst erledigt werden, was hat Zeit für später, auf was kann ggfs. ganz verzichtet werden.

Es gibt verschiedene Methoden und Verfahren, diese „Wichtigkeiten“ der Anforderungen zu bestimmen, auf die ich hier nicht näher eingehen möchte. Was mich hier aus aktuellem Anlass eher beschäftigt ist die Frage, wie diese Priorität anschließend festgehalt wird.
Aktuell sind mir dazu zwei Modelle geläufig: a) Einteilung in feste Kategorien und b) relative Priorität in Form einer Reihenfolge.

Betrachten wir beide Modelle mal kurz getrennt voneinander:

Kategorien: Zur Einteilung der Anforderungen wird eine Anzahl n Kategorien definiert. Besonders beliebt sind die Kategorien „Priorität 1“ bis „Priorität 5“. Wenn sich der Prozessverantwortliche noch besonders Mühe gibt, dann bekommen die Kategorien noch so sprechende Bezeichnungen/Beschreibung wie z.B. „Must have“, „Nice to have“ oder auch „Sehr wichtig“, „Wichtig“ oder „Normal“. Dass sich mal jemand getraut hätte eine Kategorie ganz offen als „Wird wohl niemals gemacht werden“ zu deklarieren, habe ich leider noch nicht erlebt. Aber ehrlich wäre es.

Mittels einer geeigneten Methode (z.B. Kano Modell) oder oft auch Bauchgefühl wird jeder Anforderung nun einer dieser Prioritätskategorien zugeordnet.

Der Vorteil dieses Modell ist, dass die meisten Methoden zur Priorisierung primär nur dieses Modell unterstützen (wie z.B. das Kano Modell) und dass neue Anforderung mit teilweise wenig Aufwand einfach in eine der Kategorien gesteckt werden können.
Nachteile ergeben sich aber oft in der Abarbeitung der Anforderung nach Priorität bzw. bei der Planung von Iteration in agilen Vorgehensmodellen. Dazu weiter unten aber mehr.

Reihenfolge: Die Anforderungen werden abhängig von ihrer Wichtigkeit/Dringlichkeit in eine lineare und eindeutige Reihenfolge gebracht. Hier weiß man genau genommen immer nur, die Anforderung A ist wichtiger als die Anforderung B und diese wiederum wichtiger als die Anforderung C. Man fängt mit zwei Anforderungen an und fügt dann weitere Anforderungen im Bubblesort-Verfahren (http://de.wikipedia.org/wiki/Bubblesort) in die Reihenfolge ein.

Nachteil ist, dass der initiale Aufbau der Reihenfolge etwas aufwändig scheint, da man die einzelnen Anforderungen bei der Frage nach ihrer Priorität nicht isoliert betrachten kann. Und auch bei der Aufnahme weiterer Anforderungen ist ein Vergleich mit den anderen Anforderungen notwendig. Dabei muss man aber bei der Einsortierung nicht immer ganz unten anfangen; wenn ich weiß, meine neue Anforderung H ist wichtiger als die bereits einsortierte Anforderung D, dann ist sie auch automatisch wichtiger wie alle Anforderungen unterhalb von D und ich muss mich nur auf die Vergleiche oberhalb von D konzentrieren. Da kann es sich anbieten statt Bubblesort das Verfahren des binären Suchens (http://de.wikipedia.org/wiki/Binäres_Suchen) anzuwenden. Das ist doch mal spannend, mathematische Sortierverfahren bei der Priorisierung von Anforderungen einzusetzen. Die Mathematiker jetzt aber bitte nicht alle melden und darauf hinweisen, dass es optimalere Algorithmen für die Sortierung gibt. Ich kann mir nur schwer vorstellen, dass tatsächlich ein Produktverantwortlicher oder Anforderungsmanager einen mathematischen Sortieralgorithmus verwenden wird, die Vergleiche dienen hier nur als anschauliche Beispiele.

Vorteil der relativen Prioritäten (wie ich das Modell mit der Reihenfolge ab hier mal nennen möchte) ist, dass ich hier nun eine eindeutige Reihenfolge habe, in der die Anforderungen umzusetzen sind. Was ist, wenn ich zwischen zwei Anforderungen nicht entscheiden kann, welche von beiden wichtiger ist? Münze werfen oder die weiteren Begleitumstände beachten (ist klar, dass eine der beiden Anforderungen aufgrund äußerer Umstände erst später umsetzbar sein wird, dann kann sie auch direkt weiter nach unten wandern. Dies gehört aber zum Thema, wie überhaupt bestimmt werden kann, welche Anforderungen wichtiger sind wie andere. Das behandeln wir mal in einem anderen Artikel).

Werfen wir beide Modell nun mal in den Ring und betrachten wir ihre Stärken und Schwächen im direkten Vergleich.

Bei einer kleinen überschaubaren Anzahl an Anforderungen machen sich beide Kandidaten recht gut. Die Vergabe der Prioritäten im auf Kategorien basierenden Ansatzes ist wie bereits oben besprochen ja eh recht trivial (Priorisierungsmethode der Wahl anwenden, Ergebnis nehmen und auf Kategorien transformieren, fertig). Aber auch im relativen Modell ist der direkte Vergleich der Wichtigkeit der Anforderungen untereinander schnell erledigt. Und auch bei der Abarbeitung der Anforderungen bzw. der Einplanung zeigen sich beide Modelle hilfreich.

Aber wie sieht es mit einer großen Anzahl an Anforderungen aus, wie sie schon in durchschnittlichen Projekten schnell erreicht ist?
Wir unterstellen mal eine initiale Anzahl von 100 Anforderungen zum Projektstart. Und hier wird es langsam interessant.

Betrachten wir als erstes wieder den Aufwand für die initiale Priorisierung der Anforderungen.
Im auf Kategorien basierenden Modell nehmen wir mal die typische Aufteilung in fünf Kategorien an, die wir hier als P1 bis P5 bezeichnen wollen, wobei P1 für die wichtigsten Anforderungen stehen wird und P5 für die unwichtigsten. Die Verteilung der 100 Anforderungen auf die fünf Kategorien ist erneut mit wenig Aufwand verbunden. Na gut, mit verhältnismäßig wenig Aufwand, natürlich muss jede der 100 Anforderungen bewertet werden, das ist schon Arbeit. Als Ergebnis bestimmen wir in unserem Beispiel, dass 30 Anforderungen nun P1 sind, 40 P2, weitere 20 P3 und die restlichen 10 verteilen sich gleichmäßig auf P4 und P5. Das ist irgendwie nicht unüblich, dass der überwiegende Teil der initialen Anforderungen ziemlich wichtig zu sein scheint.

Beim relativen Modell steigt der Aufwand deutlich, denn hier müssen nun die 100 Anforderungen im Verhältnis zueinander nach Wichtigkeit sortiert werden. Das klingt aber schlimmer als es dann wirklich ist. Man fängt mit zwei Anforderungen an und fügt dann Anforderung für Anforderung hinzu. Und wie oben schon mal erklärt, muss nicht bei jeder Anforderung unten mit der Sortierung angefangen werden sondern in der Regel kann direkt weiter oben in der Reihenfolge eingestiegen werden (weiter unten sage ich da noch was zu).

Wie sieht es jetzt mit der Einplanung der Anforderungen aus? Auch hier treffen wir für unser Beispiel ein paar vereinfachte Annahmen. Wir definieren, dass wir mit Scrum arbeiten, dass alle Anforderungen mit einem Aufwand von einem Story Point (SP) geschätzt sind und dass wir in einen Sprint 20 Story Points unterbringen können.
Wenn wir nun unseren ersten Sprint planen, dann stellen wir im Kategorienmodell fest, dass wir insgesamt 30 SPs haben, die Priorität vor allem anderen haben. Soweit war das Modell ja schon mal hilfreich. Im ersten Sprint unterbringen können wir aber nur 20 SP. Welche sollen wir da nun nehmen? Hier fangen wir dann vermutlich an, diese 30 Anforderungen untereinander zu vergleichen, um innerhalb dieser Gruppe eine gewisse Sortierung zu erzielen. Das gleiche gilt dann für die nächsten Sprints. Vorausgesetzt, die 20 geplanten SPs des ersten Sprints werden auch umgesetzt, stehen für den zweiten Sprint 10 weitere SPs der Priorität P1 an und 40 der Priorität P2, von denen aber nur 10 im Sprint Platz finden. Also wieder vergleichen und sortieren innerhalb von P2, und so weiter. Wir fangen uns hier also den Aufwand ein, den wir vorher bei der initialen Priorisierung vermeintlich gespart hatten.
Bei der bereits eindeutig sortierten Reihenfolge des relativen Modells haben wir diese Probleme hier nicht mehr, es ist jederzeit klar was als nächstes wichtig ist. Dafür haben wir aber vorher mehr Aufwand reinstecken müssen.

Und jetzt kommen wir zur Königsdisziplin, eine neue Anforderung, die wichtiger ist wie alles andere, sagen wir eine gesetzliche Vorgabe, die scheinbar über Nacht vom Himmel gefallen ist (neue gesetzliche Vorgaben werden vor allem in Konzernen ja gerne mal so lange ignoriert, bis sie dann auf den letzten Drücker doch plötzlich unvermeidbar scheinen).
Wie bilde ich das mit meinen Kategorien ab? P1 ist ja schon das wichtigste, aber meine neue Anforderung ist ja sogar noch wichtiger als die 30 bereits als P1 eingestuften Anforderungen. Definiere ich jetzt adhoc eine neue Kategorie P0, die noch über P1 steht? Da dauert es garantiert nicht lange, bis auch diese neue Kategorie regelmäßig gefüllt wird, denn hochpriore Kategorien haben die Eigenschaft, Anforderungen anzuziehen. Wir haben hier also ein nichttriviales Problem, dass in vielen Fällen damit gelöst wird, dass zusätzlich zur eigentlichen Kategorie noch ein weiteres Attribut wie z.B. Severity (in Bugzilla) hinzugefügt wird. Das kann dann z.B. so erklärungsbedürftige Ausprägungen wie blocker, critical, major, normal, minor, trivial und enhancement (diese gibt es so z.B. eben in Bugzilla aber auch anderen Tools) annehmen. Das ist aber nicht nur redundant, sondern kann auch zu Inkonsistenzen führen. Was ist denn nun wichtiger, eine Anforderung mit P1/enhancement oder eine mit P3/blocker? Und wieso kann eine P3 Anforderung ein Blocker sein, bzw. wieso kann ein scheinbarer Blocker nur die Priorität P3 haben? Das führt zu Chaos!

Bei der eindeutigen Reihenfolge des relativen Modells ohne Kategorien ist das Problem der neuen hochprioren Anforderung leicht zu lösen. Die neue Anforderung einfach ganz oben einsortieren, Problem gelöst.

Bis hierhin scheint das relative Modell also besser geeignet zu sein.

Jetzt hatte ich aber weiter oben ausgeführt, dass die meisten Methoden zur Priorisierung von Anforderungen eher das Denken in Kategorien unterstützen. Das jetzt schon mehrfach zitierte Kano Modell der Kundenzufriedenheit z.B. teilt Produktmerkmale (aus denen Anforderungen werden) in die fünf Kategorien Basis-, Leistungs-, Begeisterungs-, Unerhebliches und Rückweisungsmerkmal ein.
Muss ich nun auf diese Methoden verzichten, wenn ich mit einem relativen Prioritätsmodell arbeiten möchte? Natürlich nicht! Wenn ich eine eindeutige Reihenfolge meiner Anforderungen aufbauen möchte, dann muss ich die Wichtigkeit der einzelnen Anforderungen irgendwie begründen können. Warum ist denn die Anforderung A wichtiger als die Anforderung B? Da brauche ich für beide Anforderungen irgendwelche Anhaltspunkte dafür, weshalb sie wichtig oder auch nicht wichtig sind. Und genau dafür sind viele Methoden der Priorisierung eine große Hilfe. Mit ihnen kann ich zumindest schon mal ein grobes Raster schaffen, dass mir bei der ersten Vorsortierung hilft. Und wenn die Anforderung A nach dem Kano Modell in die Kategorie Basismerkmal fällt und die Anforderung B in die Kategorie Leistungsmerkmal, dann weiß ich ganz automatisch, das A wichtiger ist als B. Und nur wenn die Anforderung C ebenfalls ein Basismerkmal zu sein scheint, muss ich mir im Vergleich von A und C mehr Informationen heranziehen um hier eine eindeutige Entscheidung zu fällen.

Fazit:
Kommen wir zur Antwort auf die sich nun stellende Frage, ob Kategorien in der Priorisierung von Anforderungen strikt abzulehnen sind. Nein, sie sind eine hilfreiche Zwischenstufe auf dem Weg zu einer sortieren Reihenfolge relativer Wichtigkeit und diese Zwischenstufe kann nicht nur viel Zeit sparen sondern bei der Verwendung geeigneter Methoden die fundierte Basis für die Bewertung der relativen Wichtigkeiten liefern. Nur davon, dann bei diesen Kategorien stehen zu bleiben und auf dieser Basis dann z.B. die Sprint- oder Releaseplanung zu betreiben oder die Priorität von Anforderungen zu kommunizieren, rate ich dringend ab.