Nach dem Ausflug in die verschiedenen Konzepte der (Organisation-)Psychologie und den Grundlagen des agilen Projektmanagements befassen wir uns mit einer möglichen Umsetzung, dem WARUM und der Gestaltung von Verhalten(-sweisen) mit Hilfe von agilen Vorgehensmodellen. Man kann insbesondere bei Scrum, das das agile Manifest in ein Vorgehensmodell umsetzt, einen Rahmen schaffen, um Verhalten zu gestalten und gewissermaßen zu führen.
Die Umsetzung eines Vorgehensmodells in die Projektpraxis ist aber nicht die Copy-Paste-Anwendung des Modells, sondern die Aufgabe des (Projekt-)Managments mit Verhaltensgestaltung in kleinen Schritten den Projekterfolg immer wieder nachzujustieren.
Die fiktive Geschichte unten soll zeigen, wie es sein könnte und kann als Denkanstoß dienen, indem sie versuchen, Absatz für Absatz zu erkennen, welche psychologischen Konzepte dahinter stecken und warum Personen in bestimmte Verhaltensmuster fallen. Viel Spaß durch die Reise des Projektes – Agile Wirkstatt.
Das Team-Alignment
In der Projekt-Praxis werden Teams i.d.R. fachlich und meist aufgrund der aktuellen Verfügbarkeit für ein Projekt „ausgewählt“. Die unterschiedlichen Persönlichkeitstypen und Stärken werden in den seltensten Fällen oder gar nicht berücksichtigt. Für das agile Projektmanagement benötigt man aber ein ausgeglichenes Team, indem alle Persönlichkeitstypen mit unterschiedlichen Stärken vorhanden sind. Ist das nicht der Fall, so sollte der Projektleiter diese fehlenden Persönlichkeitstypen zumindest erkennen und zum Beispiel versuchen, andere Teammitglieder mit den fehlenden Persönlichkeitstypen oder Stärken in das Team einzuphasen oder durch geeignete Maßnahmen (z.B. mit Hilfe der Methode Behavioural Design) fehlende Persönlichkeitstypen oder Stärken zu kompensieren. Herrscht ein starker Überhang bestimmter Persönlichkeitstypen, so kann nur schwer oder kein selbstorganisiertes Teams entstehen.
Eine Möglichkeit, woran man kontinuierlich am Team-Alignment arbeiten kann, kann beispielsweise mit Hilfe der Insights MDI und/oder Gallup[1] erfolgen. Es gibt ebenso zahlreich andere Möglichkeiten eine Einordnung von Persönlichkeitstypen und Stärken vorzunehmen.
Diese Ergebnisse können dann sukzessive im Verlauf des Projektes vom Projektleiter (oder Scrum Master) nachjustiert werden. Die Anpassung kann im Verlauf eines Projektes notwendig sein, da getroffene Einschätzungen von den im Projekt beobachteten Faktoren abweichen oder sich Personen aufgrund ihrer neuen Rolle und ihren Aufgaben von ihrem vorhergehenden Persönlichkeitsbild bzw. den Stärken verändert haben.
Beispiel: Insights Farben und MDI
Um eine Vorstellung zu bekommen, wird im weiteren Verlauf das MDI Tool mit den 4 Persönlichkeitstypen als Anschauungsbeispiel eingesetzt. Sowohl im Sport, Militär oder auch bei jedem anderen Hochleistungsteam müssen die wichtigsten Stärken und Persönlichkeitstypen gut ausbalanziert sein um den maximalen Erfolg zu gewährleisten. Die eingesetzten vier Farben der Insighs MDI beschreiben vier grundlegende Persönlichkeitstypen, die im Tool durch Zahlen klassifiziert werden. Einen Auszug einer Persönlichkeitsklassifizierung zeigt die unten dargestellte Tabelle »MDI Tool – Auszug einer Auswertung«. Des Weiteren unterscheidet man noch die Selbstsicht und die Fremdsicht, die in der Auflistung unten in Klammern aufgeführt wird:
- Der gewissenhafte Typ (blau): vorsichtig, präzise, besonnen, hinterfragend, formal (steif, misstrauisch, kalt, reserviert, unentschlossen)
- Der initiative Typ (gelb): umgänglich, enthusiastisch, offen, überzeugend, redegewandt (erregt, hektisch, indiskret, extravagant, voreilig)
- Der stetige Typ (grün): vertrauensvoll, ermutigend, mitfühlend, geduldig, entspannt (fügsam, indifferent, beleidigt, anhängig, stur)
- Der dominante Typ (rot): fordernd, entschlossen, willensstark, zielgerichtet, sachorientiert (aggressiv, beherrschend, antreibend, intolerant, anmassend)
| Nummer | Blau | Rot | Grün | Gelb |
| 1 | 60 | 0 | 35 | 5 |
| 2 | 30 | 10 | 40 | 20 |
| 3 | 40 | 30 | 10 | 20 |
Die Abbildung »Auswertung des Team-Alignments mit 4 Insights Farben« zeigt eine mögliche Auswertung eines Teams. In dieser Auswertung sieht man sofort, dass im Team ein dominanter und inspirierender Typ mit ihren Eigenschaften fehlen, die in diesem Projekt z.B. durch einen Scrum Master, der das Team unterstützt, und eines weiteres neues Teammitglied kompensiert werden könnten. Die Kompensation hängt auch sehr stark an der Aufgabe und den Verantwortlichkeiten und können nicht beliebig eingesetzt werden.
Einführung agiler Werkzeuge und Methoden
Führt man ein agiles Projektmanagement und agile Vorgehensweisen ein, so ist die erste Iteration einer der wichtigsten Abschnitte, um die neuen Teammitglieder an die neue Situation heranzuführen und die ersten potentiellen Verbesserungen umzusetzen. In dieser Phase ist der Projektleiter bzw. Teamentwickler (Scrum Master) gefragt Verhaltensweisen in der Kommunikation, im Umgang und in der Art und Weise, wie das Team miteinander zusammenarbeitet, zu steuern und in eine richtige Richtung zu lenken. Hierzu stehen uns neben den reinen inhaltlichen Artefakten wie User Stories, Backlogs, etc. auch die Möglichkeiten zur Verfügung, innerhalb der inhaltlichen Artefakte Verhalten zu gestalten (Behavioural Design). Die Zusammenhänge und potentiellen Möglichkeiten werden teilweise in den nächsten Kapiteln als Beispiele veranschaulicht.
Einführung von User Stories
Im Vorfeld kann zur Erstellung von User Stories ein fachlich versiertes Teammitglied (in Scrum ist das der Product Owner und wird im weiteren Verlauf auch als solcher bezeichnet) Anforderungsworkshops mit dem Fachbereich abhalten, indem er nicht nur die Anforderungen, sondern auch soweit möglich, die Bedürfnisse und Erwartungen der Kunden aufnimmt (siehe »Akzeptanzkriterien, Conditions of Satisfaction«) und als Repräsentant des Kunden diese seinem Team vorstellen, um mit dem Team die User Stories (siehe »User Stories«) diskutieren zu können.
Eine Möglichkeit ist, zu Beginn des Projektes aus den Fachabteilungen mehrere Gruppen mit jeweils sechs bis acht Personen zu bilden, die bereits mit einem ähnlichen Legacy-System gearbeitet haben. Für diese Gruppen könnten die unten aufgelisteten Fragesequenzen gestellt werden:
- Was soll in der neuen Anwendung erhalten bleiben?
- Ungenutztes Potential: Was soll in der neuen Anwendung zukünftig verändert werden?
- Prozesssicht: Welche Veränderungen sind im Planungsprozess zu erwarten?
- Persönliche Sicht: Was wünscht du dir persönlich in der neuen Anwendung?
- Best Practices: Welche Best Practices aus anderen Systemen / Prozessen wären in der neuen Software sinnvoll?
Der erste Tag kann genutzt werden um die Mitglieder der unterschiedlichen Gruppen in das Thema des Projektes einzuweisen und im ersten Durchlauf bestimmte Fragesequenzen zuzuordnen, um ihre Anforderungen und Erwartungen auf Karten niederzuschreiben.
Der Zeitraum pro Fragesequenz kann mit einer Zeit von exakt 45 Minuten (siehe »Timeboxing und Iteration«) angesetzt werden. Nach diesem Zeitraum wechselt die Gruppe zur nächsten Fragesequenz. Nach ein paar Stunden können so etwa 200 – 300 Karten (Gruppenstärke 5-6 Gruppen) mit Anforderungen und Erwartungen (z.T. nicht funktionale Anforderungen) von den Fachabteilungen erstellt werden.
Anschließend werden diese Karten vom Product Owner sortiert, ähnliche Fragen zu sinngemäßen Anforderungsdomänen gruppiert und jede Anforderung durchgelesen, um weitere Fragen an die Mitglieder der Fachabteilungen aufzubereiten, die am nächsten Tag von den Gruppen beantwortet werden sollten. Diese fachliche Einbindung des Product Owners in die Thematik und das Stellen von Fragen vom Product Owner zu den Mitgliedern der Fachabteilungen kann an mehreren Tagen (Workshop-Charakter) wiederholt werden. Am Ende sollte der Product Owner nicht nur von den Anforderungen und Prioritäten ein sehr gutes Bild, sondern auch von den Erwartungen, die an das Projekt gestellt wurden haben. Am Ende der Woche, zum Beispiel, könnte der Product Owner beginnen die User Stories für sein Team zu schreiben. Dieser Initiale Anforderungsworkshop kann in ähnlicher Weise und mit weniger Personen im weiteren Verlauf des Projektes iterativ wiederholt (siehe hierzu auch die Methodik SAFe).
Da die User Stories (siehe »User Stories«) zu den einfachsten Werkzeugen gehören, ist die Einführung als solche technisch unkritisch und deshalb auch der erste Schritt in Richtung agiles Vorgehen. Den Teammitgliedern kann in diesem Zusammenhang noch einmal die Syntax der User Stories (siehe »Syntax der User Stories«) an praktischen Beispielen im Projekt erläutert und auch gezeigt werden was gute und schlechte User Stories ausmacht.
Dieser anfängliche Schritt bietet eine erste Gelegenheit, das Team bewusst zu beobachten und durch die Phasen der Teamentwicklung zu führen, Persönlichkeitstypen zu identifizieren und Stärken zu beobachten. In der Praxis ist es häufig auch so, dass trotz des anfänglichen Anforderungsworkshops mit den Fachabteilungen auf der Seite der Entwickler viele Fragen gestellt werden, die der Product Owner (noch) nicht beantworten kann oder sich unsicher ist und diese dann so schnell wie möglich an die Fachabteilung weitertragen und beantworten muss.
Als Projektleiter, Teamentwickler oder Scrum Master sollte man sich in den ersten Tagen stets bewusst sein, dass sich das Team in der Forming-Phase befindet, die grundlegend erstmals höflich, abwartend und vorsichtig ist (»Teamarbeit und Teamentwicklung«). Diese vermeintlich ruhige Phase kann vom Projektleiter zum Beispiel mit kritischen sachbezogenen Fragen gestört werden, um bei den einzelnen Teammitgliedern bewusst eine kognitive Dissonanz zu erzeugen, indem man beispielsweise nach den Akzeptanzkriterien einer schlecht formulierten User Story oder nach den konkrete W-Fragen frägt (siehe »Einstellung« und »Stress«). Diese W-Fragen können zum Beispiel folgendermaßen formuliert werden:
- Was genau ist zu tun?
- Welche Rolle soll das konkret einsetzen?
- Warum soll genau diese Rolle das machen und nicht eine andere?
- Wie soll die Rolle das machen?
- Wann soll die Rolle diesen Schritt machen?
- Wo genau wird die Rolle eingesetzt?
- Wieso wird es nicht anders gemacht?
- usw.
In dieser Zeit ist es möglich, sehr schnell alle Phasen nach Tuckman zu durchlaufen, indem die Mitglieder aus der Forming-Phase in eine Storming-Phase mit Konflikten, Konfrontationen und das typische Im-Kreis-Drehen gebracht werden[2].
Team Building bei Konflikten oder unstimmiger Kommunikation
Fast in jedem Projekt und insbesondere, wenn Teams aus unterschiedlichen Bereichen oder sogar Unternehmen kommen, kommt es zu Konflikten und unstimmiger Kommunikation. „Man versteht sich nicht“. Das ist aber ein typisches Phänomen und kann durch aktive Maßnahmen durch den Projektleiter oder einem Scrum Master sensibilisert und gelöst werden.
Nehmen wir an, dass bei einigen Mitgliedern der Fachabteilungen und bei den Entwicklerteams, die die Anwendung beschreiben und umsetzen mussten im Verlauf Stimmen wie: „Das wissen die jetzt immer noch nicht?“ – „Das ist doch klar, was für eine Frage!“ – „Ich brauche Entwickler die mitdenken!“ (»Konflikt und Konfliktlösung«) aufkommen. Ist das Team nicht mehr fähig die Lage einzufangen und zu lösen, muss zu diesem Zeitpunkt der Projektleiter das Team unterstützen.
In dem oben genannten Fall können die Team-Mitglieder durch eine Teambuilding-Maßnahme sensibilisiert werden, indem sie zum Beispiel Rücken an Rücken, nur durch verbale Kommunikation, dem Gegenüber erklären müssen, wie er sein Papier falten soll. Die zweite Person muss so gut wie möglich diese Faltbewegungen mitmachen. Das klingt banal und ist zu Beginn auch einfach, aber im Verlauf wird diese Kommunikation immer aufwändiger. In diesem Szenario kann man auf die Schwierigkeit und auf die Fehlertoleranz von Sprache genauer eingehen und hierfür ein tieferlegendes Verständnis schaffen.
Ein weiteres Beispiel bei der Erstellung von User Stories könnte sein, dass in der verbalen Kommunikation immer mehr durcheinander gesprochen wird, das Gesprochene immer lauter wird und dominante Mitglieder andere in ihrer Kommunikation unterbrechen. Das ist der Moment, worin der Projektleiter (oder Scrum Master) nicht sofort einschreiten sollte, um der aktuellen Situation genügend Raum zu lassen und dem Team eine Chance zu geben diesen Raum selbst kontrollieren zu können. Wenn das Team aber keinen Ausweg findet, könnte der Projektleiter diese Runde und die Kommunikation unterbrechen und diese anhand von gerade durchlebten Situationen erklären und den Konflikt als offene Kritik (siehe »Konflikt und Konfliktlösung«) darlegen. In dieser Situation könnte der Projektleiter dem Team zeigen was eine offene Kommunikation bedeutet, indem man nicht durch Fingerzeige Kritiken und Verbesserungsvorschläge generiert, sondern durch sein eigenes Empfinden (siehe »Werte und Kultur«). Hier kann der Projektleiter beispielsweise aufzeigen, dss man nicht die Formulierung »Man hat gesehen … und man hat das als störend empfunden …«, sondern ganz bewusst eine Ich-bezogene Formulierung, wie zum Beispiel »Ich habe gesehen … und ich habe das als störend empfunden …«. Der Vorteil einer solchen Kommunikation ist es, Raum für Diskussionen zu schaffen, nicht zu generalisieren (z.B. … man hat …) und auch persönliche Kritik (z.B. … ich habe es als störend empfunden …) empfangen zu können.
Aus dieser Storming-Phase könnten beispielsweise durch Regeln vom Projektleiter (wie z.B. einem Sprechball, die Art der Formulierung, usw.) oder durch Regeln die direkt aus dem Team kommen, Sprint für Sprint ein Übergang in die Norming-Phase eingeleitet werden, indem man die neuen Verhaltensweisen und Abgrenzungen einführt, die durch ein Team-Commitment (siehe »Commitment und Identifikation«) sofort oder in der nächsten Retrospektive verabschiedet werden können. Erfolgreich durchgeführt erkennt man bereits teilweise den Übergang in die Performing-Phase einiger Team-Mitglieder, die u.a. durch Offenheit, Engagement und Ideenreichtum gekennzeichnet sein können.
Einführung der Backlogs
Die Einführung des Backlogs kann eine weitere Herausforderung an das Team darstellen, insbesondere an den Product Owner dar. Sind genügend User Stories für das Team vorhanden , sollte der Product Owner des Teams erstmal diese der Fachabteilungen vorstellen. Hierbei werden i.d.R. die einzelnen Stories vorgestellt und von den Fachabteilungen priorisiert und freigegeben.
Den Fachabteilungen und dem Product Owner wird in dieser Phase noch einmal klar gemacht, dass das Team später anhand der Prioritäten eigenverantwortlich seine Teamplanung verändern kann und ggf. User Stories selbständig in die nächste Timebox verschieben darf, wenn die Zeit dafür nicht mehr ausreicht. Es wird auch allen Teammitgliedern und dem Product Owner nochmals deutlich gemacht, dass sich die Prioritäten im Backlog nach der definierten Timebox wieder ändern können.
In diesem Prozess kommt es i.d.R. zeitweise zu Problemen, da in den Fachabteilungen sehr unterschiedliche Erwartungshaltungen gegenüber einer bestimmten Anforderung vorherrschen können. Alle Begründungen, die die unterschiedlichen Fachabteilungen für die Art der Priorisierung der Anforderungen vorbringen haben aus deren Sicht auch ihre Berechtigung. In solchen Fällen kann man durch die Teilung einer bestimmten Anforderung in mehrere Anforderungsfragmente das Problem entschärfen, indem man von einer bestimmten Anforderungen einer Fachabteilung nur bestimmte Teilanforderungen und von der andren Fachabteilung ebenfalls nur bestimmte Teilanforderungen umsetzt. Man sollte versuchen die Fachabteilungen in eine Win-Win Situation zu bringen (»Kooperation und Konkurrenz«).
Nachdem die Prioritäten fixiert sind, legen das gesamte Entwicklungsteam über das Planning Poker die User Stories fest, die in der definierten Timebox von z.B. 4 Wochen umgesetzt werden sollen.
Einführung des Planning Pokers
Da Schätzungen immer subjektiver Natur sind und durch das Wissen und den Erfahrungen der einzelnen Mitglieder im Team geprägt sind, können hier Konfliktpotentiale stecken. Ähnlich wie im Kapitel »Einführung von User Stories« werden hier in kurzer Zeit alle Phasen von Tuckman durchlaufen, deren Eigenschaften aber von der Intensität und vom Konfliktpotential durchaus größer sein können als bei den User Stories. Den Mitgliedern im Team sollte während dieser Phase auch noch einmal verdeutlicht werden, dass sie ein Commitment als Team bezüglich dieser Schätzungen abgeben und sich mit den Schätzungen als Team identifizieren müssen (siehe »Commitment und Identifikation«).
In den meisten Fällen driftet die Schätzung in den ersten Runden einer User Story meist sehr weit auseinander, da jeder Entwickler bestimmte Erfahrungswerte und Vorwissen mitbringt. Das typische Vorgehen ist hier, dass derjenige, der die niedrigste Schätzung hat, dem Team erklärt, warum er diesen Aufwand und nicht einen höheren schätzt und umgekehrt. Der Vorteil ist, dass auch schüchterne, oder stille Teammitglieder ihren Standpunkt gegenüber dominanten Teammitgliedern erklären müssen. Zu Beginn kann man feststellen, dass die Teammitglieder anfänglich sehr höflich und vorsichtig den Erklärenden Fragen stellten, wenn sie nicht seiner Meinung waren. Dominante Teammitglieder könnten veruschen dem Erklärenden ins Wort zu fallen oder durch Gegenargumente oder herunterspielen der Schätzung diesen zu verunsichern oder zu manipulieren (siehe »Einstellung«). Hieraus kann bei einem Team sehr schnell ein chaotischer Sprechchor und Einzeldiskussionen entstehen. In diese Situation ist es ratsam einzugreifen (Projektleiter, Scrum Master) und die beobachteten Punkte im Team zu diskutieren. Als Werkzeug kann man im Team einen Sprechball einführen, sodass nur derjenige zu Wort kommt , der den Ball in Händen hält.
In den folgenden Runden des Planning Pokers kann es sein, dass das Team selbständig erkennt, dass einzelne Teammitglieder weitaus mehr Erfahrung in bestimmten Bereichen mitbringen als andere und es entsteht eine natürliche Erfahrungs- und Wissenshierachie (siehe »Lernende Organisation«) und eine selbständige Optimierung des Planning Pokers, indem man z.T. bestimmte Aufgaben bestimmten Personen zuordnet und diese Schätzung als Basis für die Planung genommen wird. Voraussetzung ist, dass diese Person dann auch die Umsetzung durchführt. Die dominanten Teammitglieder können sich als sehr gute Spezialisten herausstellen, die bestimmte Anforderungen extrem schnell und qualitativ hochwertig umsetzen können. Ein anfänglich schüchternes Teammitglied könnte nach wenigen Planning Poker Runden als Facilitator bei schwierigen Anforderungen vom Team ernannt werden, da er sehr schnell komplexe Zusammenhänge erkennt und diese auch einfach in das Team transportieren kann und so zu einem Generalisten wird.
Ziel ist es, dass die Planning Poker Runden von einer Sitzung zur anderen immer besser laufen und vom Team organisiert werden. Hier kann zum Beispiel mit Hilfe des MDI-Tool beobachtet werden, ob bestimmte Persönlichkeitstypen sich weiter entwickeln oder ausbrechen. Durch den direkten Austausch mit seinem Team kann man beobachten, dass sich bei manchen Teammitgliedern die Selbst- und die Fremdsicht immer mehr annähern.
Es könnte aber eine Ausnahme geben – die Anzahl der geschätzten User Stories wurde immer weniger, da die Zeit für eine Schätzung einer Anforderung immer höher wurde. Da Zeit wertvoll ist, könnte das Team daraufhin ein striktes Timeboxing für das Planning Poker einführen und sich selbstorganisiert für eine Schätzung einer Anforderung nur mehr 5 Minuten in Anspruch nehmen. Es könnte aber auch sein, dass diese Maßnahme nur für zwei Planning Poker Runden aufrechterhalten wurde, da die Teammitglieder sehr unzufrieden wurden (siehe »Einführung der Timebox«). Diese zwei Szenarien lassen erkennen, dass Timeboxing ein Werkzeug sein kann um Zeit wertvoller zu machen, zu priorisieren und um Verhalten zu gestalten (Behavioural Design)
Durch diese Unzufriedenheit bei den Planning Poker Runden und einer offenen Kommunikation stellt das Team mit der Zeit fest, dass bei den Planning Poker Runden oft erst Erfahrung und Wissen ausgetauscht werden müssen, aber man hier einen extrem guten Erfahrungs- und Wissensfluss zwischen den Teammitgliedern erreicht – eine Art Schulung und fachliche Ausbildung! Aus diesem Grund könnte das Vorgehen speziell beim Planning Poker an das Team angepasst werden (siehe »Einführung der Timebox«).
Einführung der Timebox
Die Einführung von Timeboxing stellt i.d.R. für alle Teammitglieder amfänglich eine Herausforderung dar. Es könnte sein, dass nach der ersten Retrospektive viele Teammitglieder angeben, dass sie zwar den Eindruck hatten schneller Ergebnisse liefern zu können, aber dass sie selbst mit den abgegebenen Lösungen nicht zufrieden sind. Nach einer genaueren Analyse stellt das Team aber dann fest, dass die Abnahmekriterien zwar alle erfüllt sind, aber sie selber noch gerne das eine oder andere zusätzlich an Kriterien (Definition of Ready) aufgenommen hätten, weil es nach Auffassung einiger Entwickler „sinnvoll“ oder notwendig gewesen wäre (siehe »Timebox und das Parkinsonsche Gesetz«).
Im Planning Poker, in denen die Teammitglieder das Timeboxing zum ersten Mal eingesetzt hatten, gab es zu Beginn immer unterschiedliche Aussagen über die Erwartung der Methode Timboxing im Projekt. Zum einen war die Meinung einiger Gruppenmitglieder, dass das Festhalten an einen festen Zeitrahmen sie zu sehr treiben würde (z.B. eine Aussage eines Entwicklers: »Da kommt man sich ja vor wie auf einer Galeere«)[3], zum anderen fanden einige Gruppenmitglieder die Methode für gut und lobten die Tatsache, dass man sich nun auf das Wesentliche konzentrieren kann. Speziell die Analyse im Planning Poker lieferte ein überraschendes Ergebnis. Die Teammitglieder hatten das Gefühl, dass durch die Einführung der Timebox die Kommunikation für eine User Story nicht ausreicht und diese eher verschlechtert wurde. Zudem erkannte man auch, dass speziell das Planning Poker eine Ausbildungsfunktion hat, um fachliches und technisches Wissen besser zu verstehen. Aufgrund dieser Erkenntnis wurde nach sehr kurzer Zeit das Timeboxing in dieser Art und Weise aufgegeben. Das Team erhöhte eigenständig die vorher eingeführte 5-Minuten Timebox auf 10 Minuten und alle User Stories die nicht in diesen 10 Minuten geschätzt werden konnten wurden auf die nächste Planning Poker Runde verschoben. Das Commitment hierfür war, dass man sich auf diese User Stories für das nächste Planning Poker vorbereitet. Erkannte man fachliche oder technische Erfahrungs- und Wissensdefizite bezüglich einer User Story, initiierte man eine 30-Minuten Schulung für die Teammitglieder, die dann am Ende des Tages abgehalten wurde.
Für die Teammitglieder, die der Methode des Timeboxing zu Beginn eher skeptisch gegenüberstanden fand man durch regelmäßige persönliche Gespräche und Interviews heraus, dass diese Personen in der Vergangenheit überwiegend Einzelkämpfer waren oder diese Personen, wenn sie Fehler machten, oft kritisiert wurden. Zeit war für diese Personengruppe also in der Vergangenheit ein wichtiger Faktor, um sich gegenüber allen möglichen Fehlern und somit gegen Kritik absichern zu können. Diese Tatsache konnte anfangs dadurch etwas entspannt werden, indem man diese Personengruppe immer wieder verdeutlicht, dass bei dem Prinzip des agilen Vorgehens nicht ein Einzelner die Verantwortung trägt, sondern das gesamte Team. Wichtig ist auch, wenn solche Situationen eingetreten, das Team so zu steuern, dass diese Personen einen ehrlichen Eindruck und die positive Erfahrung bekommen, dass das gesamte Team hierfür eine Lösung findet und man nicht alleine gelassen wird.
Es könnte sein, dass durch die Auswertung des Burndown-Chart bereits nach der 6 Iteration feststellt, dass der Fokus-Faktor im Projekt von 0,55 auf 0,7 verbessert wurde und das Timeboxing dem Parkinson’sche Gesetz[4] entgegen wirkte. In den Retrospektiven vermerken die Gruppenmitglieder, dass die Kommunikation klarer und transparenter geworden ist und sich bei der Umsetzung das Verständnis der Fachlichkeit verbessert hat und sich nur auf die Eigenschaften konzentriert, die für die Ergebniserreichung notwendig sind (z.B. Aussage eines Testers »Seit Einführung des Timeboxing habe ich wesentlich weniger Features zu testen, die nicht oder anders in der Spezifikation (bzw. User Stories) stehen«).
Nach einigen Iterationen (4-6) und einer klaren Erwartungshaltung bzgl. der Ergebnisse aus den Schätzungen und einer Einführung einer Definition of Ready, konnte die vorher überwiegende negative Einstellung bzgl. des Timeboxing, in eine neutrale bzw. positive Einstellung gegenüber dieser Methode beobachtet werden.
Einführung des Taskboards und des Daily Meetings
Speziell in der Softwareentwicklung hat man die Herausforderung, dass man diese nicht wirklich greifen kann. Fortschritt, Aufgaben, Fehler, etc. werden meist nur durch Zahlen in speziellen Reports, wie beispielsweise einem Bugreport oder einem klassischen Projektstatusreport dargestellt. Dies führt oft zu versteckten und schwer verständlichen Problemen, die u.U. auch von außen nicht gesehen werden.
Das Taskboard wird am ersten Tag eingeführt und veranschaulichte anfangs nur drei Prozessgruppen – Offen, in Arbeit, Erledigt (siehe Abbildung »Einfaches Taskboard«).
Das Taskboard wird anfänglich fast täglich weiterentwickelt und verändert, indem neue Prozessgruppen hinzugefügt oder aber auch wieder entfernt werden. Den Teammitgliedern wird von Beginn an das Anliegen mitgegeben, dass das Taskboard nicht als statisches Gebilde gesehen werden soll, sondern immer seinen Zweck der Sichtbarkeit von Aufgaben, Fehler, User Stories, usw. dienen muss.
Mit der Einführung der Daily Meetings und dem Task Board wird allen Teammitgliedern das Projekt vor Augen gehalten und Engpässe bzw. die Anzahl von offenen Aufgaben visuell dargestellt. Durch diese beiden Werkzeuge wird die Kommunikation im Team belebt und aufrechterhalten. Auch von den Fachabteilungen kommen überwiegend positive Feedbacks bzgl. des Taskboards, da Mitglieder der Fachabteilungen beim Vorbeigehen den aktuellen Stand ihrer User Stories sehen und verfolgen können. Von einigen Mitgliedern der Fachabteilungen kommen folgende Statements: „Jetzt verstehe ich erst, wie komplex Softwareentwicklung ausgehend von der Anforderung bis zum Rollout ist“, „Unglaublich wie viele Aufgaben meine User Story erzeugt hat, das hätte ich mir nie gedacht“, „Ich bin erstaunt, dass am Ende diese Funktion so implementiert wurde, dass es meine Erwartungen erfüllt hat.“, „Beim nächsten Anforderungsworkshop werde ich versuchen nur die wichtigsten Anforderungen weiterzugeben.“
Im späteren Verlauf des Projektes und durch die, über das Taskboard geschaffene Transparenz und dem Feedback der Fachabteilungen, wird im laufe der Zeit viel Verständnis und Motivation auf beiden Seiten für die Umsetzung der Anwendung geschaffen (siehe »Netzwerke«). Dadurch wird auch der Wille zur Zusammenarbeit und das gegenseitige Vertrauen erzeugt und das transparente Vorgehen von beiden Seiten gelobt.
Einführung des Burndown-Charts
Gleichzeitig mit der Einführung des Taskboards und der Daily Meetings wird auch das Burndown-Chart eingeführt. Am Anfang des Projektes kannten sich die Teammitglieder kaum und konnten auch keine Aussage über ihre Performance machen. Zusätzlich diente das Burndown-Chart auch zeitliche Probleme darzustellen oder auch Abwesenheiten durch Schulungen oder Krankheiten in der Performance zu berücksichtigen.
Für das Entwicklungsteam bedeutete das Burndown-Chart auch eine Möglichkeit, bestimmte Prozesse zu optimieren oder Prozessgruppen im Taskboard so zu verändern, dass die Wartezeiten zwischen unterschiedlichen Prozessgruppen minimiert wurden.
So wurde zum Beispiel eine partielle Abnahme von User Stories durch den Product Owner ermöglicht, indem man mehrere funktionale Aufgaben erstellt hat, die einzeln einen Status »zur Abnahme freigegeben« zugewiesen bekommen konnten. Dies beschleunigte den Abnahmeprozess und der Product Owner musste nicht am Ende einer User Story alle Funktionen abnehmen, sondern konnte in der Zwischenzeit seine verfügbare Zeit für die Abnahme einzelner Funktionen widmen.
Das Entwicklungsteam schaffte es nach 6 Iterationen, den Fokus-Faktor von 0,55 auf 0,7 zu verbessern.
Einführung der Retrospektive
Ein wichtiges Werkzeug, zur Verbesserung von Prozessen, Steigerung der Produktivität, Leistungsfähigkeit und Qualität, war die Retrospektive. Hier fanden sich alle Teammitglieder am Ende einer Iteration ein und diskutierten Erfahrungen und Erlebnisse, die in der letzten Iteration gut oder weniger gut gelaufen sind.
In der ersten Retrospektive wurde aus drei Themen ein Thema vom Team identifiziert, das im nächsten Sprint optimiert werden soll. Hierbei handelte es sich um das Testen von Funktionen und Anforderungen. Auf der Abbildung »Identifizieren von Themen« erkennt man in der dritten Spalte unten die Punkteverteilung, wobei die Smilies die Zufriedenheit in »Gut, Mittel, Schlecht« einteilten. Hier waren bis auf ein Teammitglied alle im unteren Bereich. In der ersten Spalte wurde die Kommunikation von allen als »Gut« bewertet. Die Spalten 2 und 4 waren gemischt bewertet worden.
Nachdem das Thema Testen als das wichtigste Thema identifiziert wurde und das Team sich die Frage stellte, was man bei der nächsten Iteration beachten muss um besser zu werden, wurden die verschiedenen Prozess-Schritte auf Karten niedergeschrieben. Da nicht alle Prozess-Schritte verbessert werden müssen, sollten die Teammitglieder diese markieren, bei denen die meisten Probleme auftraten. Hier wurden die Prozess-Schritte und Vorgänge »Zeit einplanen« und »Testfälle spezifizieren« ermittelt und auch die Verantwortlichen festgelegt, die in der nächsten Iteration diese beiden Themenkomplexe besonders beobachten sollen (siehe Abbildung »Identifizieren von Verbesserungen«). In der Diskussion anschließend wurden Lösungen gefunden und Commitments geschaffen wie die Verbesserung der beiden Themen umgesetzt werden können.
In den weiteren Retrospektiven wurden Änderungen am Entwicklungsprozess beschlossen (siehe z.B. Product Owner Abnahme), Vorgehen bei Abwesenheit durch Teammitglieder durch Krankheit oder kurzfristigen Urlaub besprochen, Veränderungen am Taskboard vorgeschlagen oder die Definition von »Fertig« durch eine feinere »Definition of Done«-Dokument festgelegt.
Durch jede Retrospektive wurden die Teamabstimmung immer bessern und die Kommunikation immer offener. Nach der neunten Retrospektive konnte das Team eigenständig handeln und erreichte am Ende einen Fokus-Faktor von 0,87.
[1] Siehe http://www.insights.de/ und https://www.gallup.com/de/gallup-deutschland.aspx
[2] Bohinc, Thomas: Projektmanagement, Soft Skills für Projektleiter; 3. Auflage; GABAL Verlag GmbH; Offenbach; 2008; S.100-105.
[3] vgl. Zusammenfassung aus den Interviews und Retrospektiven
[4] Wikipedia: Parkinson’sche Gesetz; http://de.wikipedia.org/wiki/Parkinsonsche_Gesetze; 25.04.2012
No Comments