Schrödingers Katze im Projektmanagement

… oder, wie geht es eigentlich meinem Projekt?

Wenn wir ein großes Projekt durchführen wollen, dann wissen wir, dass es zu Abweichungen vom Projektplan kommen kann. Und niemand von uns mag es, erst am Ende des Projektes diese Abweichungen zu entdecken oder festzustellen, dass das Projekt ein Fehlschlag war. Deutlich angenehmer ist es, von diesen Abweichungen früher zu erfahren. Denn dann können wir darauf reagieren und das Projekt immer noch zum Erfolg führen. Diese Erkenntnis ist nun nicht neu im Projektmanagement und Generationen von Projektmanagern haben sich schon mit der Fortschrittskontrolle von Projekten beschäftig und entsprechende Instrumente entwickelt. Und doch scheitern immer wieder Projekte scheinbar überraschend in der Schlussphase. Wie kann das sein?

1935 schlug der Physiker Erwin Schrödinger ein faszinierendes Gedankenexperiment vor. In eine undurchsichtige Stahlkammer wird eine Katze zusammen mit einer winzigen Menge einer radioaktiven Substanz, einem Geigerschen Zählrohr und einem Kolben Blausäure eingesperrt. Bei der radioaktiven Substanz besteht eine 50 prozentige Chance, dass innerhalb einer Stunde eines der Atome zerfällt, was von dem Geigerschen Zählrohr gemessen würde und in diesem Falle das Zertrümmern des Kolbens mit der Blausäure durch einen Hammer auslösen würde. Mit dem Ergebnis, dass die Katze stirbt. Dann wird eine Stunde gewartet.
Da nur eine 50 prozentige Chance besteht, dass eines der Atome zerfällt, existiert die Katze in dieser Stunde gleichzeitig in zwei sich wiedersprechenden Zuständen: Sie ist tot und sie ist lebendig (und vermutlich ziemlich verärgert).
Erst wenn wir nach Ablauf der Stunde die Stahlkammer öffnen und nachsehen, wird einer der beiden Zustände real und der andere verliert seine Bedeutung. In der Quantenphysik sagen wir auch, mit der Messung kollabiert das System der überlagernden Zustände.

Was hat das nun mit Projektmanagement zu tun?

Erfolgreiche Projekte basieren auf sinnvollem Projektcontrolling und erfolgreicher Projektsteuerung. Beides lebt davon, den aktuellen Zustand eines Projektes korrekt messen zu können. Und hier fängt nun oft das Problem an.

Die Wurzel unseres Problems liegt in der Art, wie wir Projekte planen. Bevor wir mit der Umsetzung anfangen:

• Sammeln wir alle Anforderungen an das zu erstellende Ergebnis
• Erstellen wir daraus ein detailliertes fachliches Konzept
• Erzeugen wir basierend auf dem fachlichen Konzept ein detailliertes und vollständiges technisches Konzept
• Leiten wir aus dem technischen Konzept alle notwendigen Tätigkeiten ab
• Erstellen wir den Projektplan, der genau festlegt, wer bis wann was tun wird

Das Ergebnis ist quasi die vollständige Beschreibung des Lösungswegs. Die regelmäßige Fortschrittskontrolle findet nun in der Regel als Abgleich zwischen Tätigkeiten, die bis jetzt hätten fertig sein sollen und Tätigkeiten, die bis jetzt tatsächlich geleistet wurden statt. Wir messen den Projektfortschritt also auf der Basis geleisteter Arbeit gegen geplanter Arbeit. Klingt erst mal logisch.

Der Irrtum dieses Verfahrens liegt in der Annahme, dass der Projektplan vollständig und die Umsetzung fehlerfrei ist. Und der Schlussfolgerung, dass damit das Befolgen des Projektplans automatisch zum gewünschten Projektergebnis führt. Herauszufinden, dass dem allerdings oft nicht so ist, das ist nur durch realistisches Testen der Ergebnisse möglich. In der klassischen Projektplanung findet dies zumeist erst zum Ende des Projektes statt und da kann dann das Erwachen schmerzhaft sein. Wir finden eventuell erst in der Schlussphase des Projektes heraus, dass das Produkt nicht fertig ist oder nicht funktioniert, obwohl doch alle geplanten Tätigkeiten durchgeführt wurden. Jetzt noch das Projekt innerhalb von Time & Budget zu retten, ist schier unmöglich.

Der Grund für diese späte Erkenntnis ist: Wir messen das Falsche. Wir messen die Menge an geleisteter Arbeit und vergleichen das mit der Menge an Arbeit, von der wir glauben, dass sie notwendig ist. Was wir nicht messen ist das erzielte Ergebnis. Damit verbleibt unser Projekt trotz einer scheinbaren Messung in einem überlagerten Zustand, es ist gleichzeitig ein voller Erfolg und ein totaler Misserfolg. Im Bild von Schrödingers Katze wäre das so, als würden wir den Zustand der Katze rein durch das Verstreichen der Zeit bestimmen wollen, ohne dabei die Tür der Stahlkammer zu öffnen.

Wenn wir ein Projekt bewerten wollen, dann stellt sich zuerst die Frage nach dem erzielten Ergebnis, also was kann das erzeugte Produkt. Dicht gefolgt von der Frage nach den Kosten. Niemand wird uns aufrichtig für unseren unermüdlichen Arbeitseinsatz und die vielen geleisteten Stunden danken, wenn das Ergebnis nicht stimmt. Oder haben Sie schon Lobeshymnen für die vielen Stunden Arbeit gehört, die in den neuen Berliner Flughafen gesteckt wurden? Nein, was unsere Kunden an erster Stelle interessiert ist, ist das Produkt fertig und funktioniert es!

Wie können wir dieses Problem der falschen Fortschrittsmessung lösen? Nur indem wir in kurzen Abständen die Tür zur Stahlkammer öffnen und uns vom tatsächlichen Zustand der Katze überzeugen. Wir lassen das System der überlagernden Zustände durch die konkrete Messung kollabieren. Im Projektmanagement bedeutet das, dass wir uns in kurzen Abständen die tatsächlichen Ergebnisse ansehen, die bisher erzielt wurden.

Das Projektmanagementframework Scrum zeigt, wie das funktionieren kann. In Scrum werden innerhalb kurzer Iterationen von maximal vier Wochen Länge sogenannte potentiell auslieferfähige Produktinkremente erzeugt. Das bedeutet, es werden immer vollständige Funktionalitäten erstellt und zwar in finaler Marktqualität. Finale Marktqualität bedeutet in diesem Kontext, dass innerhalb der Iteration alle notwendigen Tätigkeiten durchgeführt werden, um diese Funktionalität ausliefern zu können. Bei den meisten Produkten würde das z.B. das vollständige Testen und Dokumentieren bedeutet. Das Ziel ist, dass eine Funktionalität am Ende einer Iteration wirklich fertig ist, es existieren keine versteckten Restaufwände für diese Funktionalität mehr.

Was sind jetzt versteckte Restaufwände? Versteckte Restaufwände sind alle die Tätigkeiten, die Sie ungeplant zu einem späteren Zeitpunkt durchführen müssen, damit die Funktion wirklich funktioniert. Zum Beispiel, dass Sie in der Test- oder Abnahmephase Ihres Projektes feststellen, dass eine Funktionalität nicht ordnungsgemäß funktioniert und Sie diese nun nachbessern müssen. Das ist Aufwand, den Sie höchsten indirekt durch Puffer eingeplant haben. Wobei Sie aber nicht wissen können, wie viel Puffer Sie tatsächlich brauchen werden. Oft ist es das, was Ihnen am Ende Ihres Projektes die Kopfschmerzen bereitet.

In Scrum bewerten wir am Ende jeder Iteration, welche Funktionalitäten wirklich fertig sind und welche nicht. Wir bekommen damit einen realistischen Überblick über den Zustand unseres Projektes und eine realistische Information darüber, wie schnell wir tatsächlich sind.
Auf diese neue Art der Bewertung umsteigen führt in vielen Projekten erst mal zur Ernüchterung. Plötzlich liegt Schwarz auf Weiß der Nachweis vor, dass die ursprünglichen Erwartungen mehr oder weniger zu optimistisch waren. Gerne wird nun die überraschend geringe Entwicklungsgeschwindigkeit erst mal dem Mehraufwand durch das direkte Testen zugeschrieben. Und Sie ahnen schon, welche Maßnahme dann gerne als erstes zur Steigerung der Projektperformance gewählt wird. Doch das ist purer Selbstbetrug, diesen Aufwand zum Testen und Nachbessern müssen Sie so oder so betreiben. Je weiter Sie ihn nach hinten verschieben, desto mehr erhöhen Sie das Risiko eines Projektfehlschlages.

In erfolgreichen Projekten stellen wir uns den Problemen, sobald sie auftreten und reduzieren damit Projektrisiken so gut wie möglich. Meine Lieblingsfrage, die ich Projekt- und Produktmanagern immer wieder gerne stelle ist: „Wann möchten Sie wissen, dass Sie ein Problem in Ihrem Projekt haben?“ Und die einzige sinnvolle Antwort darauf lautet: „So früh wie möglich!“ Je früher im Projekt Sie wissen, dass Sie ein Problem haben, umso mehr Optionen haben Sie noch, dieses Problem zu lösen und das Projekt so erfolgreich zu Ende zu führen.

„Ja, aber bei uns ist es nicht möglich innerhalb von vier Wochen eine ganze Funktionalität zu realisieren“. Wirklich? In der Tat gibt es vereinzelte Themenkomplexe, in denen Kernfunktionalitäten nicht so weit reduzierbar oder sinnvoll zerlegbar sind. Aber das ist bei weitem nicht so oft der Fall, wie es uns viele Projektmanager oder Produktverantwortliche glauben machen wollen. Denken Sie selber mal darüber nach, könnte es genau diese Sichtweise von zu großen Funktionalitäten sein, die die Entwicklung Ihrer Produkte so komplex und herausfordernd macht?

Ein anderer gerne genommener Einwand ist: „Wir können nicht innerhalb von vier Wochen etwas entwickeln und vollständig testen. Unsere Tests sind dafür viel zu Aufwändig.“ Sind diese Tests zu aufwändig, weil sie so gut und umfassend sind? Oder weil sie nicht effizient genug durchgeführt werden? Auch hier gilt die gleiche Antwort wie zuvor. Ja, in einigen Kontexten sind die Tests und anderen Abnahmeverfahren tatsächlich, selbst bei bester Organisation, nicht in einem derart kurzen Zeitraum machbar. Und auch hier ist das deutlich seltener der Fall, wie es zuerst scheint.

Was wir also sehen ist, dass es für die Umstellung von Projekten auf ein realistischen Bewertungs- und Messverfahren in kurzen Intervallen nicht einfach mit dem Beschluss getan ist, sich alle vier Wochen die Ergebnisse ansehen zu wollen. Tatsächlich ist es dazu notwendig, den gesamten Prozess, wie Produkte und Projekte geplant, entwickelt und getestet werden unter die Lupe zu nehmen und auf das Ziel der stückweisen Abnahme in kleinen Inkrementen umzustellen.
Eine Anstrengung die sich jedoch immer lohnt, denn sie führt zu einem Unternehmen, das in der Zukunft in kürzerer Zeit die bessern Produkte in besserer Qualität entwickeln wird. Überlassen wir also Schrödingers Katze den Physikern und arbeiten lieber mit eindeutigen Zuständen.

In der Quantenphysik dient Schrödingers Katze als Parabel, um den quantenmechanischen Effekt der Zustandsüberlagerung zu veranschaulichen und führt dort zu neuen Erklärungsversuchen unserer Welt oder so faszinierenden Ideen wie der Theorie unendlich vieler paralleler Universen.
Im Projektmanagement dahingegen führt Schrödingers Katze zu Kopfschmerzen und zu manchmal scheinbar unendlicher Frustration. Hier lässt sich Schrödingers Katze übrigens auch gut mit einer alten Weisheit der Dakota-Indianer kombinieren: Wenn dein Pferd tot ist, steig ab!
Diese Weisheit wird gerne im Kontext des Projektmanagements zitiert, um klar zu machen, dass gescheiterte Projekte losgelassen werden sollen. Aber wie wir oben schon gesehen haben, scheitern viele an der Frage, ob das Pferd denn wirklich schon tot ist.

So gesehen leiden viele Projekte sogar an Schrödingers Pferd!

Warum sich Gedränge so sehr lohnt

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.

Seminar Test Driven Development mit Java

Unter dem Schulungslabel binaris education bieten wir nun eine Schulung über Test Driven Development mit Java an. Am Beispiel der Programmierung eines LEGO Mindstorms Roboters zeigen wir die verschieden Phasen bei der Entwicklung von Software mit TDD.

Weitere Informationen und Termine zu diesem Seminar finden Sie hier.

Was sind selbstorganisierende Teams?

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 „richtige“ Sprintlänge

Eine Frage, vor der alle Scrumteams schon mal standen ist: wie lang soll die Sprintlänge sein?
Was durch die Bank hinweg die gesamte Scrumliteratur vorschreibt ist, dass die Länge der Sprints zumindest über einen gewissen Zeitraum hinweg fix sein soll. Die Länge der Sprints will damit also im Vorhinein schon mal gut überlegt sein.

Stöbern wir durch die Bücher von Ken Schwaber oder durch verschiedene Artikel von Jeff Sutherland, dann stoßen wir da meist auf eine vorgeschlagene Länge von 30 Tagen. Bei Schwaber wird es nicht genauer erklärt, aber ich vermute mal, dass er mit diesen 30 Tagen einfach auf einen Kalendermonat abzielt, also ca. vier bis fünf Wochen und nicht auf 30 Werktage, was sechs Wochen ergeben würde. Etwas weiter geforscht ergibt sich aber scheinbar ein allgemeiner Konsense bei der Aussage, ein Sprint sollte zwischen einer bis vier Wochen lang sein.

Aber was bedeutet das jetzt für uns, wenn wir unser Projekt neu aufsetzen und die Sprintlänge festlegen wollen? Wann nehmen wir eine Woche? Wann vier? Und wann irgendwas dazwischen? Damit wollen wir uns in diesem Artikel befassen.

Rufen wir uns erstmals in Gedächtnis zurück, warum wir in Scrum überhaupt mit Iterationen arbeiten: Wir wollen in einem definierten Zeitraum ein in sich sinnvoll abgeschlossenes Ergebnis erreichen, das sogenannten potentiell auslieferbaren Produktinkrement.
Vielen Neueinsteigern in Scrum fällt es schwer, sich vorstellen zu können innerhalb einer Woche ein sinniges in sich abgeschlossenes Produktinkrement erstellen zu können. Dadurch geht die Tendenz eher zu längeren Sprints. Gleichzeitig scheinen sich aber mittlerweile in vielen Unternehmen die Prioritäten von Anforderungen im Stundentakt zu ändern, meist weil ständig neue und natürlich wichtigere-wie-alles-andere Anforderungen auftauchen. Die manchmal fast schon panisch anmutende Angst, irgendwelche Markttendenzen verpassen zu können und deshalb möglichst innerhalb von Stunden auf neue Erkenntnisse oder Vermutungen reagieren zu wollen, kann Projektverantwortliche schon mal in den Wahnsinn treiben und drückt die angestrebte Sprintlänge wieder nach unten.

Wir sehen uns scheinbar einem Zielkonflikt gegenüber und das alleine macht schon deutlich, dass es auf die Frage der richtigen Sprintlänge keine Pauschalantwort gibt.

Versuchen wir die Faktoren mal einzeln zu betrachten, sodass jeder von Ihnen die Möglichkeit hat, seine aktuelle oder zukünftige Projektsituation unter den einzelnen Gesichtspunkten zu bewerten.

Fangen wir mit der Frage an, was bedeutet eine möglichst kurze Sprintlänge für ein Projekt?
Zuerst fällt positiv auf, dass wir mit einer kurzen Sprintlänge auch eine recht kurze Reaktionszeit auf geänderte Anforderungen haben. Wenn wir die Regeln von Scrum hart spielen und der Sprint damit gegen Änderungen von außen geschützt ist, dann beträgt die durchschnittliche Reaktionszeit auf geänderte Umstände die Hälfte der Sprintlänge. Bei einer Sprintlänge von einer Woche also 3 ½ Tage.
Als nächstes Sticht der Umstand ins Auge, dass in einen kurzen Sprint natürlich auch nur entsprechend wenige Anforderungen passen und diese außerdem auch entsprechend klein sein müssen. An der Bewertung, ob dies positiv oder negativ ist, scheiden sich die Geister und es hängt auch von den Projektumständen ab. Es mag tatsächlich Projekte geben, in denen Anforderungen nicht auf die erforderliche Maximalgröße runter gebrochen und dann noch isoliert voneinander umgesetzt werden können. Objektiv ist das allerdings wirklich nur selten der Fall.
Eine kurze Sprintlänge zwingt den Produkt Owner und das Team auf jeden Fall zu einer klaren Fokussierung auf ein oder maximal zwei Ziele pro Sprint, weil ansonsten in der kurzen Zeit vermutlich keine in sich sinnvoll abgeschlossenen Features zu realisieren sind. Dementsprechend sind auf den Sprint Reviews auch selten die großen Würfe zu erwarten, dafür aber ständig neue Verbesserungen, Erweiterung, neue Features. Bei kurzen Intervallen wirkt dies wie ein kontinuierlicher Strom an Fortschritt.

Eher anspruchsvoll um nicht zu sagen schwierig ist bei kurzen Sprintlängen jedoch die Entwicklung einer größeren und investitionssicheren Systemarchitektur. Hier steigen die Anforderungen an gute Architekturvorgaben und an einen sauberen Programmierstil, wenn die Systemarchitektur nicht jede Woche neu erfunden oder völlig aus dem Runder laufen soll. Dementsprechend müssen hierfür im Team auch die entsprechenden Skills vorhanden sein oder bewusst aufgebaut werden. Darüber, wie auch in kurzen Sprints saubere Architektur entstehen und erhalten bleiben kann und was dafür notwendig ist, werde ich in einem anderen Artikel schreiben, wenn wir uns mit inkrementeller Architektur befassen.

Das führt uns direkt zur Betrachtung von langen Sprintlängen. Welche Auswirkungen haben diese auf ein Projekt?
Wenn wir bei einer kurzen Sprintlänge die kurze Reaktionszeit gelobt haben, dann ist sofort klar, dass dies bei langen Sprintlängen nicht mehr so ist. Bei einer Sprintlänge von vier Wochen beträgt die durchschnittliche Reaktionszeit jetzt schon 2 Wochen! Dass kann Stakeholder mit vermeintlich dringenden Begehren schon mal ein bisschen ungeduldig werden lassen.
Umgekehrt bietet die lange Sprintdauer aber auch viel Raum für Anforderungen. Dass soll aber dennoch nicht davon ablenken, dass auch hier klare Sprintziele mit Schwerpunkten für jeden einzelnen Sprint gesetzt werden sollen. Bitte behalten Sie das im Auge, die Gefahr ist sonst groß, dass sich das Team bei der Umsetzung der Anforderungen verzettelt und durch den fehlenden Fokus viel an Energie verloren geht.
Die kurzen Sprints erfordern, das Anforderungen knapp und knackig sein müssen, um in die Sprints zu passen und dafür müssen sie ziemlich präzise beschrieben sein, damit überhaupt abgeschätzt werden kann, ob sie in einen Sprint passen. Die langen Sprints verleiten leicht dazu, diese Präzision zu vernachlässigen, da die Anforderung schon irgendwie passen wird. Das rächt sich aber relativ schnell und deshalb muss auch bei langen Sprints die gleiche Sorgfalt auf die präzise Beschreibung der Anforderungen gelegt werden. Zumindest für die Anforderungen, die in einen Sprint eingeplant werden sollen.
Viel Platz für Anforderungen bedeutet aber auch die Möglichkeit, größere zusammenhängende Teile der Systemarchitektur in einem Stück planen und umsetzen zu können. Es ist also leichter, die Systemarchitektur aufzusetzen und Grundlagen zu schaffen. Und natürlich ist es ein schönes Gefühl in jedem Sprint Review nicht bloß ein zwei Kleinigkeiten sondern gleich einen großen Batzen an Neuerungen im Produkt zeigen zu können. Das dafür aber auch nur alle vier Wochen.

Hm, alles recht interessante Gesichtspunkte, aber so zwingend hilft das noch nicht weiter, zumindest nicht in allen Fällen. Betrachten wir ein paar einzelne Gesichtspunkte etwas genauer.

Bei kurzen Sprintlängen stellt sich die Frage des Overheads bzgl. der Meetings. Wir erinnern uns, in Scrum haben wir mit dem Sprint Planning, dem Sprint Review und der Sprint Retrospektive drei Regelmeetings, die einmal pro Sprint abgehalten werden. Bei einwöchigen Sprints wären das zwischen 12 und 15 Meetings im Monat, bei vierwöchigen Sprint halt genau 3. Klingt erst mal nach erheblichen Overhead bei kurzen Sprints. Allerdings darf man nicht vergessen, dass bei kurzen Sprints auch die Meeting wesentlich kürzer sein können, da ja nur der Inhalt einer wesentlich kürzeren Zeitperiode besprochen werden muss. Sollten Sie in Ihrem Team die Disziplin haben, Meetings nicht länger zu gestalten, wie wirklich notwendig ist, dann ist die höhere Anzahl an Meetings pro Monat kein Hinderungsgrund für kurze Sprintlängen. Ufern bei Ihnen jedoch Besprechungen grundsätzlich aus ohne dass Sie das einschränken können, dann wäre eher eine längere Sprintdauer zu empfehlen, bei der Sie dann weniger Meetings pro Monat haben.

Ein Punkt, den wir schon angesprochen hatten ist die Reaktionszeit auf Änderungen in den Anforderungen bzw. die Neupriorisierung von Anforderungen. Ich glaube ich habe es mal in einem der Bücher von Ken Schwaber gelesen, die entscheidende Frage bezüglich der Sprintlänge war: Wie lange kann der Product Owner den Mund halten? Übersetzt bedeutet das, wie lange kann der Product Owner das Team vor der Einflussnahme durch Stakeholder schützen? Wenn die Geschäftsführung regelmäßig neue Ideen ausbrütet, die natürlich immer wichtig sind und deshalb aus Sicht der Geschäftsführung immer sofort gemacht werden sollen, wie lange kann der Product Owner diese Stakeholder bremsen beziehungsweise wie viel Geduld und Verständnis für die Belange des Softwareentwicklungsprozesses bringen die einflussreichsten Stakeholder auf. Ist es diesen Stakeholder verständlich zu machen, dass neue Ideen und Anforderungen nur alle vier Wochen in Angriff genommen werden können oder bestehen die Stakeholder trotz aller Erklärungen auf möglichst sofortige Berücksichtigung ihrer Anforderungen?

Und jetzt zum nächsten Knackpunkt.
Es ist ja schön, wenn wir in der Lage sind Anforderungen in kleine, voneinander unabhängige und präzise beschriebene Pakete zu zerlegen, unsere Meeting kurz und effizient zu halten und auch trotz kürzester Sprintlänge eine vorbildliche Systemarchitektur planen und aufbauen zu können. Wert hat das Ganze aber nur dann, wenn am Ende jedes Sprints ein potentiell auslieferbares Produktinkrement entsteht und dazu gehört nach den Definitionen von Scrum auch, dass der produzierte Code getestet ist. Natürlich ist jedes Team selber für seine „Definition of done“ verantwortlich und damit kann der Anspruch, was als potentiell auslieferbar gilt natürlich auch beliebig weit nach unten gedrückt werden. Aber sinnvoll ist das nicht! Bei der Wahl der Sprintlänge ist also auch zu berücksichtigen, in welchem Zeitraum neue Funktionen sinnvoll getestet werden können. Ein möglichst hohes Maß an Testautomatisierung und eine ständig verfügbare Test- und Integrationsumgebung verkürzen den notwendigen zeitlichen Aufwand und ermöglichen so kürzere Sprintlängen. Aber überall da, wo manuelle Test notwendig oder Testumgebungen nicht ständig verfügbar sind (aus welchen Gründen auch immer), überall da ist bei der Planung der Sprintlänge zu berücksichtigen wann die für die Test erforderlichen Ressourcen zur Verfügung stehen. Idealerweise sind Tester aus der Fachabteilung fester Bestandteil des Teams und zu 100% für diese Tätigkeit eingeplant, aber wo sind die Bedingungen für ein Projekt schon ideal. Wenn mir meine Tester nur alle vier Wochen für jeweils fünf Tage zur Verfügung stehen, dann kann ich keine zweiwöchigen Sprints fahren, denn wie will ich im jeweils zweiten Sprint testen?
Das Gleiche gilt auch für das Sprint Review. Inhalt des Sprint Reviews ist es, dem Product Owner und den Stakeholdern die Ergebnisse des Sprints zu präsentieren. Dabei geht es dem Team nicht bloß darum, sich im Lichte seiner Leistungen zu sonnen, obwohl das natürlich auch schön ist. Nein, ein wichtiges Ziel des Sprint Reviews ist das direkte Feedback von Product Owner und Stakeholder darüber, ob die neuen Funktionen oder Korrekturen in Art und Umfang dem entsprechen, was sich die Stakeholder vorgestellt hatten oder auch nicht. Dieses Feedback ist wichtig für die ständige Verbesserung des Entwicklungsprozesses und auch für evtl. Kurskorrekturen bei der Priorisierung der nächsten Anforderungen. Bei einer einwöchigen Sprintdauer bedeutet das aber auch, dass jede Woche zumindest einige Stakeholder die Zeit für das Sprint Review haben müssen. Ist das dauerhaft nicht der Fall, dann ist fraglich ob die einwöchige Sprintlänge wirklich Sinn macht.

Ein in meinen Augen eher kosmetischer Punkt, den wir hier aber dennoch nicht verschweigen wollen sind die Auswirkungen der Sprintlängen auf die Schwankungen in der Velocity eines Teams. Um sowohl für die Planung der nächsten Sprints wie auch für die grobe Releaseplanung eine Vorstellung über die zukünftige Entwicklungsgeschwindigkeit zu haben, halten wir für jeden abgelaufenen Sprint die Anzahl der erledigten Aufwände fest. Das können Story Points sein oder auch ideale Tage oder Gummibärchen, wie wir sie in meinem aktuellen Projekt gerne nennen. Daraus bilden wir einen Chart, der uns die Entwicklung der Entwicklungsgeschwindigkeiten graphisch aufbereitet und uns eine Prognose für die zukünftige Entwicklungsgeschwindigkeit ermöglichen soll.
Jetzt ist aber zu beachten, dass ein plötzlicher Ausfall eines Mitarbeiters für einen Tag, z.B. durch Krankheit, die Velocity eines kurzen Sprints wesentlich stärker beeinflusst wie die eines langen Sprints. Und bei langen Sprints besteht auch eine größere Wahrscheinlichkeit, dass in jedem Sprint mal jemand überraschend einen Tag ausfällt. Das heißt, die Velocity wird in längeren Sprints eher gleichmäßiger ausfallen als in kurzen.

Spielt das eine Rolle? Ich denke nicht. Auf dem Chart sehen die vermutlich stark unterschiedlichen Entwicklungsgeschwindigkeiten bei kurzen Sprintlänger zwar etwas wild aus, für die Berechnung eines Trends ergeben sich aber keine echten Unterschiede. Dieser Punkt ist also eindeutig zu vernachlässigen.

Kommen wir zurück zum Anfang, unserer Problemstellung, wie lang soll die Sprintlänge für unser neues Scrumprojekt sein. Sind wir da wirklich weitergekommen? Vielleicht ja. Möglichweise ist einer der Umstände, die wir gerade beschrieben haben der Schlüsselfaktor. Die schnelle Reaktionszeit, die unsere Stakeholder von uns verlangen oder die fehlenden Testkapazitäten. Dann kann daran die, ich nenne sie mal „initiale“ Sprintlänge festgemacht werden. Wenn aber keiner dieser Faktoren so deutlich ins Auge sticht oder einfach noch nicht bekannt ist, nun dann trifft man einfach eine Annahme und startet damit.

Ich hatte am Anfang davon gesprochen, dass die Sprintlänge zumindest über einen gewissen Zeitraum hinweg fix sein soll. Hintergrund ist, dass damit ein gewisser Flow geschaffen werden soll, in dem sich hilfreiche Abläufe einschleifen und den Entwicklungsprozess einfach und stabil halten sollen. Bei jedem Sprint die Dauer des Sprint zu ändern, würde dem im Wege stehen. Das bedeutet aber eben nicht, dass die Dauer der Sprints einmal festgelegt wird und dann nie wieder verändert werden darf. Scrum ist eine agile Methodik und einer der Grundpfeiler ist und bleibt „inspect and adapt“ und das gilt auch für die Sprintlänge. Einfach mal mit was starten, sehen wie es läuft und bei Bedarf anpassen.

Meine Empfehlung für die ersten Sprints: Wenn das Team neu in Scrum ist oder die Skills für inkrementelle Architektur nicht vorhanden sind oder das Testen größtenteils noch manuell erfolgt und auch andere Faktoren im Testen noch nicht optimal sind, dann als initiale Sprintlänge vier Wochen wählen. Dabei aber kontinuierlich daran arbeiten, die Bedingungen für kürzere Sprintzeiten zu verbessern, d.h. die Grundlagen in inkrementeller Architektur zu schaffen, die Tests zu automatisieren, ständig verfügbare Testumgebungen aufzubauen und so weiter. Und dann nach und nach die Sprintlängen alle paar Monate um eine Woche zu reduzieren. Dabei ist für mich persönlich der Einwochensprint nicht zwingend das Endziel. In vielen Fällen pendeln sich Scrumprojekte bei einem Zweiwochenzyklus ein, das scheint ein guter Kompromiss zwischen den beiden Extremwerten zu sein. Aber schussendlich muss jedes Projekt seinen eigenen Zyklus finden.

Das Kano-Modell der Kundenzufriedenheit

In meinem Artikel „Prioritäten von Anforderungen – Kategorie oder Reihenfolge“ hatte ich mehrfach Bezug auf das Kano-Modell der Kundenzufriedenheit genommen ohne dieses dabei näher zu erläutern. Diese fehlende Erläuterung möchte ich hier nun nachholen.

Die meisten von uns, die sich schon mal mit Produkt- oder Anforderungsmanagement auseinandersetzen durften oder immer noch dürfen, kennen das Problem der Entscheidung: In welcher Reihenfolge sind Anforderungen umzusetzen bzw. welche sind überhaupt umzusetzen. Selten mangelt es an Anforderungen an das, was ein zu erstellendes Produkt alles können soll, unzählige Interessenvertreter haben ihre eigenen Vorstellungen davon, was absolut unverzichtbar ist und damit auf jeden Fall umgesetzt werden muss. Und zwar immer als allererstes!

Das Kano-Modell versucht hierbei Licht ins Dunkel zu bringen und dem armen Entscheider, der es allen Recht machen und am Ende aber auch die Verantwortung für den Erfolg des Produktes tragen muss ein Werkzeug an die Hand zu geben, dass in diesem Wirrwarr die Streu vom Weizen trennt und für die Entscheidung, was wann umgesetzt wird eine nachvollziehbare Grundlage schafft. Damit ist aber auch direkt klar, was das Kano-Modell nicht macht: Es unterstützt nicht bei der Erhebung der Anforderungen. Um diesen teilweise unübersehbaren Pool an Anforderungen zu generieren, müssen also andere Techniken verwendet werden, die in diesem Artikel jedoch nicht besprochen werden (vielleicht lasse ich mich hierzu ja auch demnächst zu einem Artikel hinreißen).

Zum geschichtlichen beschränke ich mich auf den Hinweis, dass das Kano-Modell auf Prof. Dr. Noriaki Kano von der Universität Tokio zurückgeht. Mehr historisches dazu interessiert zumindest mich derzeit nicht.

Also zurück zum Handwerklichen oder besser erst mal zu einer ganzen Reihe von Definitionen.

Als erstes müssen wir festhalten, dass im Kano-Modell nicht von Anforderungen sondern von Produktmerkmalen gesprochen wird. Anforderungen sollten sich in der Regel auf Produktmerkmale beziehen, d.h. sie „fordern an“, dass das Produkt ein bestimmtes Merkmal aufweist bzw. nicht aufweist. Ein Produktmerkmal selber ist eine für den Kunden spürbare Eigenschaft des Produkts, also z.B. dass er sich anmelden kann. Und unter Kunden verstehen wir hier den Personenkreis, der mit unserem neuen Produkt umgehen muss bzw. es kaufen soll.

Jetzt wieder zurück zum Kano-Modell. Dort werden Produktmerkmale in fünf Kategorien aufgeteilt:

Basis-/Must-Have Merkmal: Basismerkmale eines Produktes sind so grundlegend und selbstverständlich, dass sie dem Kunden erst bei Nichterfüllung bewusst werden. Werden sie aber nicht erfüllt, dann entsteht nicht unerhebliche Unzufriedenheit. Umgekehrt entsteht aber bei Erfüllung nicht wirkliche Zufriedenheit. Ein Beispiel hierfür kann die Möglichkeit zur Anmeldung an eine Software sein.

Lineares-/Leistungsmerkmal: Lineare Merkmale sind dem Kunden durchaus bewusst und sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit abhängig vom Ausmaß der Erfüllung. Ein Beispiel hierfür ist die Performance eines Softwareprodukts.

Begeisterungsmerkmal: Begeisterungsmerkmal sind Nutzen stiftende Merkmale, mit denen der Kunden nicht unbedingt rechnet. Sie zeichnen das Produkt gegenüber der Konkurrenz aus und rufen Begeisterung hervor. Eine kleine Leistungssteigerung kann zu einer überproportionalen Nutzenstiftung führen. Die Differenzierungen gegenüber der Konkurrenz können gering sein, die Nutzenstiftung aber dennoch enorm.

Unerhebliches Merkmal: Sind sowohl bei Vorhandensein wie auch beim Fehlen ohne Belang für den Kunden. Sie können daher keine Zufriedenheit stiften, führen aber auch beim Fehlen nicht zu Unzufriedenheit.

Rückweisungsmerkmal: Rückweisungsmerkmale führen beim Vorhandensein zu Unzufriedenheit, beim Fehlen jedoch nicht zu Zufriedenheit. Ein Beispiel hierfür wäre ein Kopierschutz.

Soweit so gut, ich habe jetzt also auf der einen Seite fünf Kategorien und auf der anderen einen Sack voll mit Anforderungen. Aber wie ordne ich jetzt meine Anforderungen in diese fünf Kategorien ein? Eine Möglichkeit wäre, dass ich als der Produktverantwortliche dieses anhand der Beschreibungen oben jetzt selber mache. Dafür muss ich aber die zukünftigen Kunden und deren Bedürfnisse schon ziemlich genau kennen und die Wahrscheinlichkeit, dabei des Öfteren mal daneben zu liegen dürfte recht hoch sein.

Besser also, ich frage die potentiellen Kunden selber und zwar möglichst viele davon. Aber auch hier die Frage, nach welchen Kriterien ist eine Anforderung einer der fünf Kategorien zuzuordnen. Die Beschreibungen oben sind verhältnismäßig dürftig, dürften von jedem etwas anders verstanden werden und darüber hinaus ist dies schon eine recht anspruchsvolle und komplexe Tätigkeit. Ich will damit nicht sagen, dass alle Endkunden zu … äh … damit überfordert wären, aber machen wir uns nichts vor, gerade wenn ich eine größere Gruppe von Personen zu etwas befragen möchte, dann sinkt die Qualität des Ergebnisses mit der steigenden Komplexität der Fragestellung.

Das Kano-Modell geht deshalb einen anderen Weg, den einer biopolaren Befragung. Jeder Proband wird zu jedem Merkmal jeweils mit einer funktionalen und einer dysfunktionalen Frage konfrontiert oder verständlich ausgedrückt, er soll zu jedem Merkmal mitteilen, wie er es fände, wenn es vorhanden ist und wie, wenn es fehlt.

Als Antwortmöglichkeiten stehen ihm für beide Fragen zur Verfügung:

– Ich mag es genau so
– Ich erwarte, dass es so ist
– Mir egal
– Ich kann damit leben
– Das stört mich

Super, jetzt habe ich pro Merkmal sogar zwei Antworten von einem Probanden, wie soll ich denn daraus jetzt zu meiner Kategorie kommen? Hier kommt die Magic des Kano-Modells ins Spiel und zwar in Form der Antworten-Kategorien-Matrix.

Wir finden in dieser Matrix in den Schnittmengen der möglichen Antworten auf die beiden Fragen alle unsere fünf Kategorien wieder plus zweimal eine unlogische Kombination. Bei dieser Antwortenkonstellation scheint irgendwie der Sinn der Fragestellungen abhanden gekommen zu sein. Entweder ignorieren oder die Frage nochmal stellen und dabei nochmal den Schwerpunkt auf das Verständnis der Fragestellungen legen.
Aus den Antworten auf die beiden Fragen eines Probanden kann nun also die Kategorie einfach abgelesen werden. Und machen wir nun nicht nur einmal sondern pro Produktmerkmal fragen wir möglichst viele potentielle Kunden und halten das Ergebnis tabellarisch fest. In der Tabelle unten habe ich mal ein Beispiel dafür erstellt. Wir haben drei Merkmale befragt und die Verteilung der Zielkategorien der einzelnen Befragungen prozentual in einer Tabelle zusammengefasst.

Bei dem Produktmerkmal 1 haben wir mit 43,8% eine eindeutige Spitze für lineares Merkmal, bei dem Produktmerkmal 2 mit 54,3% eine eindeutige Spitze für Basismerkmal. Beim Produktmerkmal 3 jedoch haben wir zwei Spitzen, einmal 36,6% für Basismerkmal und dann nochmal 39,1% für Begeisterungsmerkmal. Dies kann darauf hindeuten, dass wir zwei unterschiedliche Arten von Kunden für unser Produkt haben, die unterschiedliche Erwartung an unser Produkt hegen. Hier macht es Sinn, sich klarzumachen, welche unterschiedlichen Kundenarten das sind und anschließend festzulegen, auf welche von beiden Kundenarten wir mehr fokussieren wollen.

Kommen wir zurück zu unserer Ausgangssituation, wir sind ein armer Produktverantwortlicher und alle Interessenvertreter haben uns mit Unmengen an Anforderungen zugeschüttet. Wir haben aus (fast) all diesen Anforderungen Produktmerkmale extrahiert und diese durch das Kano-Modell in Kategorien eingeordnet. Ist damit jetzt klar, welche Anforderungen bzw. Produktmerkmale umzusetzen sind und in welcher Reihenfolge?
Leider nicht so ganz. Fangen wir mit den einfachen Fällen an, die Rückweisungsmerkmale und die unerheblichen Merkmale. Das Kano-Modell priorisiert Produktmerkmale aus Sicht des Kunden und aus dieser Sicht sollte auf Rückweisungsmerkmale auf jeden Fall verzichtet werden und unerhebliche Merkmale sollten nur am Schluss umgesetzt werden, wenn noch Zeit und Geld da ist. Obwohl sie aus dieser Sicht eigentlich nur Resourcenverschwendung sind. Also besser auch nicht umsetzen. Allerdings bestimmen ja nicht immer nur die Kundenwünsche die Notwendigkeiten zu Produktmerkmalen. Bevor diese Merkmale also tatsächlich komplett gefeuert werden, erst noch prüfen was die Intention zu diesen Merkmalen war. Bei gesetzlichen Vorgaben oder technischen Notwendigkeiten kann die Welt schon ganz anders aussehen. Aber wenn nichts dergleichen zutrifft, raus damit, schlanke Produkte designen.

Kommen wir zu unserem Dreigestirn: Basis-, lineare und Begeisterungsmerkmale.
Mit Basismerkmalen gewinnt man keinen Blumentopf, wenn sie aber fehlen floppt wahrscheinlich das ganze Produkt. Also müssen sie wohl rein. Wie dringend sie rein müssen, also mit welcher Priorität verglichen mit den Linearen und Begeisterungsmerkmalen, hängt davon ab, wie ich die Release auf den Markt bringe. Wenn ich klassisch im Wasserfall arbeite und vermutlich nur alle 12 Monate ein neues Release rausbringe (oder sogar noch langsamer), dann müssen alle Basismerkmale bereits im ersten Release drin sein, denn die Kunden werden das Produkt solange nicht akzeptieren, wie die Basismerkmale nicht enthalten sind oder mit der baldigen Nachlieferung zu rechnen ist. Wenn ich dahingegen in wesentlich kürzeren Zeitabständen meine Releases ausliefere, z.B. jeden Monat oder alle zwei und dieses auch entsprechend kommuniziere, dann sind Kunden schon eher geneigt, dass Fehlen von Basismerkmalen für kurze Zeit in Kauf zu nehmen. Natürlich muss dass, was ich da ausliefere in sich funktionsfähig sein, alles andere wäre ja völliger Unsinn. Aber anstatt für den gesamten geplanten Funktionsumfang des Produktes erst mal nur die Basismerkmale zu ersten und auszuliefern und dem Kunden damit ein „ist ja ganz nett“ zu entlocken, fokussiert man nur einen bestimmten Funktionsbereicht und realisiert diesen mit seinen notwendigen Basismerkmalen plus weitere Lineare und Begeisterungsmerkmalen. Der Kunden gewinnt damit einen guten Eindruck dessen, was in nach und nach bei unserem Produkt erwarten wird und kann evtl. auch schon mit der Teilfunktionalität schon Mehrwerte für sich erzielen.

Wäre das mit den Basismerkmalen schon mal geklärt, aber wie gewichten wir lineare gegenüber Begeisterungsmerkmalen. Begeisterungsmerkmale sprechen oft sehr subjektives Empfinden gegenüber einen Produkt an und gewinnen in der Regel eher durch den Überraschungseffekt oder das Alleinstellungsmerkmal (das hat halt kein anderer so, deshalb ist es cool). Beides nutzt sich mehr oder weniger schnell ab. Lineare Merkmale dahingegen stellen meist tatsächliche Wehrwerte des Produktes für den Kunden dar, die meist auch auf Dauer erhalten bleiben.
Rein ökonomisch gesehen wären deshalb die linearen Merkmale den Begeisterungsmerkmalen vorzuziehen. Aber unsere Kunden sind alle Menschen und die Begeisterungsmerkmale sind es, die dann doch oft die Kaufentscheidung oder die Akzeptanzbereitschaft für unser Produkt stark beeinflussen. So gesehen ist die Entscheidung für Begeisterungsmerkmale irgendwie auch ökonomisch. Zumindest für den, der das Produkt verkauft :-).

Die gesunde Mischung macht es aus. Ein Produkt nur mit linearen Merkmalen ist zwar wertvoll, aber unsexy, ein Produkt nur mit Begeisterungsmerkmalen verleitet zwar zum schnellen Kauf aber nicht zur Nutzung. Ein guter Erfahrungswert ist, den Schwerpunkt auf lineare Merkmale zu setzen, damit der Kunden tatsächlich echten Mehrwert erhält und das mit einer Handvoll Begeisterungsmerkmale zu würzen, damit er sich auch für unser Produkt entscheidet bzw. die Nutzer das Produkt bereitwillig akzeptieren.

So, ich hoffe das hat ein bisschen Licht ins Dunkel gebracht. Die Quintessenz ist, das Kano-Modell bietet eine gute Unterstützung dabei, sich der Qualität von Anforderungen bewusst zu werden und sich aus der Vielzahl an Anforderungen auf die zu konzentrieren, die bei den Kunden gut ankommen werden. Es ist aber zum Leidwesen einiger kein Mechanismus, in den ich oben einfach alles rein kippe und unten kommt dann die fertige Reihenfolge heraus. Der gesunde Menschenverstand der Produktverantwortlichen ist immer noch erforderlich.

Und zumindest ich bin froh darüber!

Quellen:

• http://de.wikipedia.org/wiki/Kano-Modell
• „Agile Estimating and Planning“ von Mike Cohn 2006

Die Sprint Retrospektive

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?

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.

Vortrag auf dem Scrum Day 2009

Der Vortrag „Wie entsteht Architektur in Scrumprojekten“ von Carsten Czeczine wurde für den Scrum Day 2009 in Düsseldorf angenommen. Weitere Informationen hierzu gibt es hier.

Schulung Scrum Grundlagen

Carsten Czeczine wird über die GFU Cyrus AG im Dezember 2009 und Mai 2010 zwei offene Grundlagenschulungen über Scrum halten. Informationen und Anmeldungen zu dieser Schulung gibt es hier.

Nächste Seite »