Agiles Projektmanagement Quiz – Part 4: Sprint Review – Was haben wir geschafft?

Let’s Quiz

Herzlich willkommen zum Agile- Projektmanagement-Quiz – Part 4. Auch dieses Mal wird es um eine reale Projektsituation gehen, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Wie in den vergangenen drei Teilen unserer Quizreihe könnt ihr hier erneut eure Scrum-Kenntnisse und euer Projektmanagementwissen an realen Projektbeispielen testen. Du hast einen oder mehrere Teile unserer Quizreihe verpasst? Kein Problem, du findest diese weiterhin auf unserem Blog. In den ersten drei Teilen haben wir uns mit dem Sprint Planning, dem Sprint Backlog sowie dem Reporting auseinandergesetzt.

Im letzten Quiz haben wir uns das Reporting näher angeschaut. Es ging um die Fragen, wie erfolgreich unser Team ist, wie viele Story Points (User Stories) abgearbeitet wurden und welche Möglichkeiten es gibt dies übersichtlich darzustellen – Stichwort Burndownchart. Doch wann sind User Stories eigentlich abgearbeitet? Wie wird dies definiert und wer entscheidet das? Unser heutiges Quiz beschäftigt sich genau damit. Viel Spaß!

Sprint Review – Was haben wir geschafft?

Scrum sieht zum Ende jedes Sprints ein sogenanntes Sprint Review vor. In diesem Meeting präsentiert das Entwicklungsteam dem Product Owner (PO) die Ergebnisse seiner Arbeit aus dem letzten Sprint. Zusätzlich nehmen auch weitere interessierte Stakeholder an diesem Termin teil – beispielsweise Vertreter aus dem Fachbereich oder die Autoren der entwickelten User Stories. Die Resultate werden live am System präsentiert. Zusätzlich ist es dem Team möglich Feedback zu sammeln, Verbesserungsvorschläge vorzubringen sowie Lob und Kritik auszutauschen. Auf Basis des Gezeigten entscheidet schließlich der PO, ob die entsprechende User Story als fertig (engl. done) angesehen werden kann oder ob nochmal nachgebessert werden muss. Bei dieser Einschätzung hilft dem PO ein weiteres Scrum-Artefakt. Die sogenannte Definition of Done (DoD).

Definition of Done – Was ist das?

Die „Definition of Done (DoD)“ beschreibt die Vorgaben des Product Owners an das Produkt. Sie ist maßgeblich dafür verantwortlich, ob eine User Story nach der (vermeintlichen) Umsetzung als done gekennzeichnet werden kann. Für die Einhaltung der DoD ist das Scrum-Team verantwortlich, welches die DoD sowohl bei der Sprintplanung, als auch bei der Umsetzung von User Stories immer berücksichtigen muss. Eine typische Definition of Done, aus Sicht des Product Owners, kann beispielsweise so aussehen:

  • Akzeptanzkriterien sind erfüllt
  • Tests sind erfolgreich
  • Software ist auf Integrationsumgebung ausgeliefert
  • Constraints sind eingehalten (z.B. Design Vorgaben, Usability Vorgaben)
  • Benutzerdokumentation ist fortgeschrieben

 

Oftmals werden die Kriterien des Product Owners noch durch zusätzliche Aspekte aus Betriebs- oder IT-Sicht ergänzt. So könnte die DoD beispielsweise zusätzlich beinhalten, dass neben dem Benutzer- auch das Betriebshandbuch fortgeschrieben ist und die Testabdeckung mindestens 80% beträgt.

Es ist wichtig, dass die DoD allen Beteiligten klar kommuniziert und verständlich ist. Die DoD ist in gewisser Weiße ein Bestandteil jeder User Story, welcher in der Aufwandsschätzung berücksichtigt werden muss. Bei nicht klar definierten oder nicht ausreichend kommunizierten Kriterien besteht die Gefahr, dass der Aufwand für die Umsetzung einer User Story unterschätzt wird. Als Resultat werden zu viele User Stories in den Sprint eingeplant, von denen letztendlich vielleicht keine die DoD erfüllt und im Sprint Review nicht vom Product Owner abgenommen wird.

In einem solchen Fall klingt es verlockend, die DoD zum Sprintende aufzuweichen, um doch noch ein paar User Stories abzuschließen. Dies ist jedoch nicht ratsam, da hierdurch das Projekt mit der Zeit eine immer größere „Schuld“ aufbaut. Am Ende kann es einen ganzen Sprint kosten beispielsweise fehlende Tests und Dokumentationen entsprechend nachzuziehen. In der Praxis passiert dies häufig und ist auch nicht gänzlich zu vermeiden. Dennoch: die DoD ist der Qualitätsanspruch an das Projekt – welchen es nach Möglichkeit immer einzuhalten gilt.

Der Praxisfall – ein Sprint Review Meeting

Als Praxisfall für unser heutiges Quiz dient uns folgendes Beispiel. Im Sprint Review Meeting eines agilen Projektes werden die Ergebnisse des Sprints vorgestellt.

Die Definition of Done des Projektes ist:

  • Software wird auf Testumgebung ausgeliefert
  • Akzeptanztests sind durchgeführt und alle erfolgreich
  • Betriebsreife Index ist erfüllt

 

Teilnehmer des Meetings sind:

  • Team
  • Scrum Master
  • Product Owner
  • Gesamtprojektleiter
  • Testmanager
  • Inbetriebnahme Manager
  • Agiler Coach

 

Die Ergebnisse werden direkt im System gezeigt und vorgeführt. Zu Beginn des Meetings wird zudem eine Liste mit den Sprintergebnissen präsentiert.

PrioritätUser StoryStory PointsStatus
1Story D12Fertig, bis auf Teil „xy“. Die Story kann erst mit Story T fertiggestellt werden.
2Story E20Fertig, aber noch nicht getestet.
3Story F8Fertig.
4Defect zu Story B aus vorherigem SprintFertig.
5Defect zu Story C aus vorherigem SprintKonnte nicht reproduziert werden und muss zusammen mit dem PO analysiert werden.
Update auf der PROD Umgebung (Anforderung kam während des Sprints)Fertig und eingespielt.

Die Präsentation der Sprint Ergebnisse auf dem System wird vom Entwickler mit den folgenden Worten eingeleitet:

„Wundert euch nicht über die komischen Daten. Auf der Entwicklungsumgebung haben wir keinen Abzug der Echtdaten. Die Funktionen kann ich euch aber alle zeigen.“

Jetzt seid ihr an der Reihe!

Frage 1: Wie viele User Stories können im Burndown Chart als fertig eingetragen werden?

Frage 2: Welche User Stories können in die Produktionsumgebung eingespielt werden?

Frage 3: Welche Tipps habt Ihr für das Team, um im nächsten Sprint mehr User Stories fertig zu bekommen?

Auch für diesen Fall gibt es nicht die richtige Lösung. Sende uns gerne Deine Antworten per Kontaktformular oder poste einen Kommentar unter diesen Beitrag. Dann senden wir dir gerne die Musterlösung, das heißt unsere Empfehlung mit der Projektsituation umzugehen, per Mail zurück. Wir freuen uns auf deine Ideen!

 

Hier findest Du Teil 1, 2 und 3 der Projektmanagement-Reihe:

Zum 1. Teil des PM Quiz – Sprint Planning – Aller Anfang ist schwer

Zum 2. Teil des PM Quiz  – Sprint Backlog – Der Sprint kann los gehen!

Zum 3. Teil des PM Quiz – Reporting – Ist unser Projekt erfolgreich?

 

Mehr agiles Projektmanagement gibt es hier

 

Agiles Projektmanagement Quiz – Part 3: Reporting – Ist unser Projekt erfolgreich?

Let’s Quiz

Herzlich willkommen zum Agile- Projektmanagement-Quiz – Part 3. Hier könnt Ihr eure Scrum-Kenntnisse und euer Projektmanagementwissen an realen Projektbeispielen testen. Wie in den letzten beiden Teilen unserer Quiz-Reihe geht es wieder um eine Projektsituation, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Auch in diesem Fall stammt die Projektsituation aus einem agilen Projekt, in dem das Vorgehensmodell Scrum eingesetzt wurde. Falls Du noch nicht mit Scrum vertraut und auf der Suche nach weiteren Informationen bist, dann schau gerne in den ersten beiden Teilen unserer Quiz-Reihe vorbei. Dort wirst du sicher fündig!

In den ersten beiden Teilen haben wir uns mit dem Sprint Planning sowie dem Sprint Backlog beschäftigt. Nun ist der Sprint vorbei und es steht die Überprüfung aus, wie erfolgreich wir das Sprint Backlog abgearbeitet haben. Haben wir unser Sprint Ziel erreicht? Konnten wir alle User Stories erfolgreich umsetzen, die wir für den Sprint eingeplant hatten?

Reporting – Ist unser Projekt erfolgreich?

Ein konsequent umgesetztes Reporting ist unweigerlich mit dem Projekterfolg verbunden. Auch in agilen Projekten ist es daher wichtig den Projektfortschritt kontinuierlich zu überprüfen.

Im Optimalfall sind zum Sprintende alle User Stories vollständig abgearbeitet und umgesetzt. In der Praxis zeigt sich jedoch häufig auch ein anderes Bild und das Sprintziel konnte nicht erreicht werden. Die Gründe hierfür sind vielfältig. Möglicherweise haben Informationen zu einzelnen Arbeitspaketen gefehlt, oder aber es fehlten schlicht die personellen Kapazitäten im Team, um alle Aufgaben vollständig abzuarbeiten.

In jedem Fall lassen sich zum Ende eines Sprints wertvolle Erkenntnisse darüber gewinnen, wie erfolgreich gearbeitet wurde und was im kommenden Sprint Planning berücksichtigt werden muss, um das Sprintziel in Zukunft zu erreichen.

Da die Summe aller erreichten Sprintziele den Fortschritt des Projektes als Ganzes repräsentiert, eignen sich diese Informationen auch hervorragend, um den Gesamtfortschritt aufzuzeigen und zu dokumentieren.

Burndown Chart

Ein in der Praxis gängiges Instrument, um den Projekt- und oder Sprintfortschritt zu überprüfen, sind die sogenannten Burndown Charts. Sofern gewisse Rahmenbedingungen erfüllt sind, ist die Anwendung denkbar. Welche Rahmenbedingungen das sind, erfahrt Ihr gleich. Zunächst wollen wir uns das Prinzip eines Burndown Chart näher anschauen. Wie ist es aufgebaut? Was sagt es aus?

In einem Burndown Chart werden auf der y-Achse die Story Points der einzelnen User Stories aufgetragen, die noch abgearbeitet werden müssen. Die x-Achse weist die Sprints des Projektes aus. Mit jedem Sprint verringert sich der Vorrat an verbleibenden Story Points im Backlog. Im Idealfall fällt die Kurve linear bis zum Projektende ab, bis irgendwann keine Story Points mehr vorhanden sind und sämtlicher Arbeitsaufwand „verbrannt“ ist.

In der nachfolgenden Abbildung seht ihr ein exemplarisches Burndown Chart für den Burndown im Projekt. Der Verlauf des realen Burndowns ist zwar nicht ideal, dafür aber realistisch. Der Grund hierfür liegt in der schwankenden Velocity des Teams. Die Velocity gibt an, wie viele Story Points je Sprint durch das Team abgearbeitet wurden. Nach einer Eingewöhnungsphase steigt diese langsam an. Entsprechend schneller sinkt auch die rote Kurve (Real Burndown) ab. Der Estimated Burndown (blaue Kurve) zeigt den prognostizierten Zustand – eine linear abfallende Kurve, die von einer konstanten Velocity des Teams ausgeht.

Produkt Burndown
Burndown im Projekt – eigene Darstellung

Nun wollen wir auf die eingangs genannten Rahmenbedingungen zurückkommen. Welche Bedingungen müssen erfüllt sein, damit ein Burndown Chart funktioniert und aussagekräftig ist?
Das Burndown Chart funktioniert super, wenn…
• … die Teamstärke über alle Sprints stabil ist
• … die Sprintlänge gleich bleibt
• … das Product Backlog zu Projektstart vollständig gefüllt, mit Story Points geschätzt und priorisiert ist.

Sind diese Rahmenbedingungen nicht erfüllt steigt damit auch die Komplexität. Unmöglich ist die Arbeit mit dem Burndown Chart aber auch dann nicht.

Eine Anwendung des Charts ist auch auf einzelne Sprints denkbar. In diesem Fall gibt die y-Achse die Story Points eines Sprints an während die x-Achse Zeitpunkte innerhalb des Sprints ausweist.

Kombiniert man die beiden Charts hat man zwei sehr gute Instrumente, um ganz einfach den Projektfortschritt zu messen.

Burndown Chart
Burndown im Sprint – eigene Darstellung

Übrigens: Burndown Charts lassen sich auch in anderen Projekten anwenden, sofern man anstelle von Sprints in Meilensteinen und anstelle von User Stories in offenen Aufgaben denkt.

Der Praxisfall – ein magisches Dreieck

Im konkreten Praxisfall wurde im letzten Viertel eines agilen Projektes der Arbeitsfortschritt des Projektes im Rahmen des magischen Dreiecks durch den Projektleiter überprüft.

Magisches Dreieck
Magisches Dreieck – eigene Darstellung

Der Projektleiter stellte fest, dass…
85% der Zeit verstrichen ist,
35% des Scope umgesetzt wurden und
65% der geplanten Kosten bereits verbraucht wurden.

Jetzt seid Ihr an der Reihe!

Frage 1: Mit welchen Mitteln konnte der Projektleiter das feststellen?
Frage 2: Welche möglichen Ursachen kann dieser Projektstatus haben?
Frage 3: Was sollte der Projektleiter eurer Meinung nach tun, um die Situation zu verbessern?

Auch für diesen Fall gibt es nicht die richtige Lösung. Sende uns gerne Deine Antworten per Kontaktformular oder poste einen Kommentar unter diesen Beitrag, dann senden wir Dir gerne die Musterlösung, das heißt unsere Empfehlung mit der Projektsituation umzugehen, per Mail zurück. Wir freuen uns auf deine Ideen!

Hier findest Du Teil 1, 2 und 4 der Projektmanagement-Reihe:

Zum 1. Teil des PM Quiz – Sprint Planning – Aller Anfang ist schwer

Zum 2. Teil des PM Quiz  – Sprint Backlog – Der Sprint kann los gehen!

Zum 4. Teil des PM Quiz – Sprint Review – Was haben wir geschafft?

 

Mehr agiles Projektmanagement bekommst du hier

Agiles Projektmanagement Quiz – Part 2: Sprint Backlog – Der Sprint kann los gehen!

Let’s Quiz

Herzlich willkommen zum Agiles-Projektmanagement-Quiz – Part 2. Hier kannst Du Deine Scrum-Kenntnisse und Dein Projektmanagementwissen an realen Projektbeispielen testen. Es geht es um eine konkrete Projektsituation, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Das heutige Quiz beschreibt eine Projektsituation aus einem agilen Projekt, in dem das Vorgehensmodell Scrum eingesetzt wurde. Scrum beschreibt einen iterativen Prozess für die Softwareentwicklung, die Planung erfolgt in Sprints. Weitere Informationen gibt es in der Quiz-Beschreibung zum ersten Quiz.

Im ersten Teil der vierteiligen Quizreihe „Sprint Planning – Aller Anfang ist schwer“ ging es um die Planung des Sprints. Dies erfolgt im Rahmen eines Sprint Planning Meetings, in dem die Arbeitspakete festgelegt und geplant werden, die in diesem Sprint umgesetzt werden. Diese User Stories bilden das Sprint Backlog.

Die Stories im Sprint Backlog müssen so spezifiziert sein, dass sie umgesetzt werden können. Denn nur, wenn alle benötigten Informationen in einer User Story enthalten sind, darf diese im Sprint Planning in den Sprint gezogen werden.

Sprint Backlog – Bereit zur Umsetzung

Im heutigen Quiz geht es um dieses Sprint Backlog. Wir haben im Sprint Planning 1 geklärt, welche der fertig spezifizierten User Stories in diesem Sprint umgesetzt werden müssen. Aus dem Sprint Planning 2 geht hervor, wie sich die Stories konkret umsetzen lassen. Daraus ist unser Sprint Backlog entstanden.

Das wäre zumindest die Idealvorstellung. Häufig ist es jedoch so, dass Stories im Sprint landen, die nicht ausreichend spezifiziert sind, so dass eine konkrete Planung der Umsetzung nicht möglich ist. Doch wie lässt sich dies verhindern?

Im Scrum Guide ist beschrieben, dass eine Story „ready“ sein sollte, um im Sprint Planning durch das Entwicklungsteam ausgewählt werden zu können. Deshalb ist es von zentraler Wichtigkeit, dass alle Projektbeteiligten ein gemeinsames Verständnis davon haben, was „ready“ bedeutet. Um dies sicherzustellen, ist es hilfreich eine „Definition of Ready (DoR)“ festzulegen, die genau dies definiert. Es handelt sich dabei um eine Liste von Kriterien, die an User Stories gestellt werden. Die DoR ist die Anforderung des Scrum-Teams an die Qualität und an die Informationen einer User Story. Der Product Owner sorgt dafür, dass diese Qualität im Product Backlog gewahrt ist. Die Idee dahinter ist, dass nur vage beschriebene User Stories nicht in einen Sprint gelangen können, sondern nur solche, die der DoR entsprechen.

Typische Anforderungen in einer DoR sind:

  • User Story ist User-zentriert beschrieben
  • Akzeptanzkriterien (funktional und nicht funktional) sind beschrieben
  • Abhängigkeiten sind beschrieben
  • Rahmenbedingungen und Voraussetzungen sind beschrieben
  • Alle Referenzen für die Umsetzung liegen vor (z.B. CI-Guidelines, Usability-Guidlines)
  • Der Business Value ist bewertet
  • Die Schätzung liegt vor
  • Testfälle liegen vor

Der Praxisfall – ein Prototyp für eine Messe

Die Projektsituation entstand im Kontext Condition Monitoring und Predictive Maintenance. Im konkreten Projekt hat das Team in vier Sprints einen Prototyp für eine Messe realisiert. Da der Prototyp auf der Messe vorgestellt werden sollte, war es entscheidend, am Tag der Messe eine funktionsfähige Anwendung zur Verfügung zu haben. Es musste also in möglichst kurzer Zeit eine Anwendung fertiggestellt werden, die zwar noch nicht produktiv einsetzbar ist, aber potenziellen Endanwendern einen möglichst großen Funktionsumfang präsentiert.

Im ersten Sprint war die Qualität der fachlichen User Stories, nach Coaching der Product Owner durch doubleSlash, recht gut, und die Arbeit schritt voran. In der Tabelle siehst Du den aktuellen Stand.

SprintSprint LängeSprint BacklogTechn./fachl. User StoriesAusreichend spezifiziert
11 Woche167/9Alle

In einem verlängerten Sprint Planning konnten User Stories geeignet geschnitten und die offenen Fragen geklärt werden.

22 Wochen3222/1010 fachliche User Stories sind nicht ausreichend spezifiziert, aber für den Sprint angenommen.
32 Wochen??Das Backlog ist unvollständig!
41 Woche??Das Backlog ist leer!

Das Projekt befindet sich jetzt einen Tag vor Abschluss von Sprint 2. Es fehlen immer noch einige der Nachspezifikationen für die angenommenen 10 fachlichen User Stories.
Ein erneutes Coaching-Angebot, um beim Verfassen der User Stories zu unterstützen, haben die Product Owner aus Kapazitätsgründen abgelehnt.

Fragen:

Frage 1: Welche Auswirkungen haben die fehlenden Spezifikationen auf das Ergebnis des laufenden Sprints?

Frage 2: Welche Risiken siehst Du für das Projektergebnis?

Frage 3: Was kann der Projektleiter tun, um das Projekt erfolgreich abzuschließen?

Auch für diesen Fall gibt es nicht die richtige Lösung. Schick uns gerne Deine Antworten per Kontaktformular oder poste einen Kommentar unter diesen Beitrag, dann senden wir dir gerne die Musterlösung, das heißt unsere Empfehlung mit der Projektsituation umzugehen, per Mail zurück. Wir freuen uns auf deine Ideen!

Hier findest Du Teil 1, 3 und 4 der Projektmanagement-Reihe:

Zum 1. Teil des PM Quiz – Sprint Planning – Aller Anfang ist schwer

Zum 3. Teil des PM Quiz – Reporting – Ist unser Projekt erfolgreich?

Zum 4. Teil des PM Quiz – Sprint Review – Was haben wir geschafft?

 

Mehr agiles Projektmanagement bekommst du hier

Agiles Projektmanagement Quiz – Part 1 Sprint Planning – Aller Anfang ist schwer

Let’s Quiz Agile

Herzlich willkommen zum Quiz Agiles Projektmanagement. Hier kannst Du Deine Scrum-Kenntnisse und Dein Projektmanagementwissen an realen Projektbeispielen testen.

Stell Dir vor, Du bist in der Rolle eines Coaches und musst – ohne tieferes Verständnis des Projektinhaltes – dem Team Feedback zu seinem Arbeitsprozess, seinem Reporting oder seinem Anforderungsmanagement geben.

Wir bieten Dir eine vierteilige Quiz-Reihe an, die anhand von abstrahierten Beispielen aus unseren Projekten und Coaching-Workshops zeigt, wo die zentralen Herausforderungen im agilen Projektmanagement liegen und wie man zielgerichtet mit ihnen umgehen kann. Denn meist gibt es keine eindeutige, allgemeingültige Musterlösung, sondern verschiedene Möglichkeiten, um mit solchen Projektsituationen umzugehen.

Basis sind Projektsituationen, die wir selbst erlebt haben und für die wir eine Lösung finden mussten. Und natürlich erfährst Du hier auch, wie wir mit der jeweiligen Projektsituation umgegangen sind.

In unserem Quiz betrachten wir Projektsituationen aus folgenden vier Bereichen:

  • Sprint Planning
  • Sprint Backlog
  • Reporting
  • Sprint Review

 

Die beschriebenen Projektsituationen stammen vor allem aus agilen Projekten, in denen das Projektmanagement-Vorgehensmodell Scrum beziehungsweise eine vom jeweiligen Kunden adaptierte Variante eingesetzt wurde.

Scrum beschreibt einen iterativen Prozess für die Softwareentwicklung, eine Iteration wird als Sprint bezeichnet. Er startet mit dem Sprint Planning, in dem die Arbeitspakete (User Stories) festgelegt und geplant werden, die in diesem Sprint umgesetzt werden. Diese User Stories bilden das Sprint Backlog.

Wie in jedem Projekt ist das Reporting ein zentrales Element im Projektmanagement, in Scrum erfolgt dies häufig mit Hilfe von Burndown Charts. Den Abschluss eines Sprints bildet das Sprint Review, in dem das Team dem Produkt Owner die Ergebnisse des Sprints präsentiert.

Ablauf Scrum Prozess
Abbildung 1: Scrum Prozess – eigene Darstellung

Bei vielen Projekten im agilen Umfeld sprechen wir von hybriden Projekten, da sie Ansätze des agilen und phasenorientierten Projektmanagements vereinen. Generell gelten die im Quiz beschriebenen Projektsituationen nicht ausschließlich für agile Projekte. Ähnliche Projektsituationen können genauso auch in Projekten auftreten, in denen nach phasenorientierten Projektmanagement-Modellen wie dem Wasserfallmodell oder dem V-Modell vorgegangen wird. Viele Themen gehen auch über das jeweilige Vorgehensmodell hinaus und betreffen generell das Projektmanagement. Denn es geht darum, Situationen richtig einzuschätzen und im Projektmanagement Entscheidungen zu treffen.

Sprint Planning – aller Anfang ist schwer

Im ersten Quiz geht es um das Sprint Planning: Am Anfang eines Sprints müssen wir die Arbeitspakete planen, die wir in diesem Sprint umsetzen. Diese sind in Form von User Stories beschrieben, um benötigte Funktionalitäten jeweils aus der Sicht des Anwenders zu definieren.

Das Sprint Planning klärt für einen Sprint die Frage, was zu tun ist und wie es zu tun ist. Der Product Owner ist für das „Was“ verantwortlich, das Team für das „Wie“. Deshalb teilt man das Sprint Planning in zwei Teile. Nur wenn vom Product Owner alle Fragen für das Team beantwortet sind, wird es eine User Story zur Umsetzung in den Sprint aufnehmen. Ist dies der Fall, plant das Team im zweiten Teil des Sprint Planning, wie es die jeweilige User Story umsetzt.

Scrum Cooking Workshop

Die erste Projektsituation entstand in einem Scrum Cooking Workshop. In diesen Workshops wird die Idee von Scrum spielerisch in einem agilen Kochprojekt vermittelt.
Im konkreten Projekt geht es um ein Mittagessen in einer Premium Kantine. Ziel ist es, dem Kunden und Endanwender, in diesem Fall dem Kantinen-Gast, die Gerichte anzubieten, die er sich vorgestellt hat. Neben dem Gast gibt es jedoch auch andere Stakeholder, deren Anforderungen berücksichtigt werden müssen, zum Beispiel den Betreiber der Kantine.

Der Product Owner ist für die Priorisierung und Spezifikation der Anforderungen an die Speisen verantwortlich, die das Team zubereitet. Er muss also die – teilweise wenig konkreten – Vorstellungen der Stakeholder (Kantinen-Gäste, Kantinen-Betreiber, etc.) sammeln und in konkrete, umsetzbare Arbeitspakete umwandeln. Eine Herausforderung dabei ist, dass es auch widersprüchliche Anforderungen geben kann, die dann aufgelöst werden müssen.

Der Scrum Master muss dafür sorgen, dass der agile Prozess eingehalten wird. Das heißt, er muss unter anderem dafür sorgen, dass die Scrum-Meetings wie Sprint Planning und Dailys durchgeführt werden.

Natürlich könnte man auch direkt mit dem Projekt starten, ohne viel Zeit in die Planung zu investieren. Aber das rächt sich erfahrungsgemäß im Laufe des Projekts: Im konkreten Projekt ist z.B. der Fall eingetreten, dass das Team Abhängigkeiten zwischen Tasks aufgrund der unfertigen Planung viel zu spät erkannte. Ein Ofengericht wurde dann aufgrund der fehlenden Ofenvorheizphase zu spät und ziemlich „bissfest“ serviert. Und wenn solche Situationen schon in einem – im Vergleich – einfachen Kochprojekt eintreten, wie sieht es dann erst bei komplexen Softwareprojekten aus?

Über mehrere Sprints hinweg werden verschiedene Gerichte gekocht. Wie in jedem Projekt können dabei auch unvorhergesehene Situationen eintreten, etwa der Ausfall eines Teammitglieds oder nicht verfügbare Technologien wie ein fehlendes Rührgerät.

Der konkrete Fall – Mittagessen in der Premium Kantine

In unserem Mittagessen-Projekt in der Premium Kantine geht es um folgende Situation: Das Scrum Team besteht aus vier Köchen, einem Scrum Master und einem Product Owner. Zwei Sprints, in denen das Scrum Team eine Vor- und eine Hauptspeise zubereitet hat, sind bereits abgeschlossen. Das Ziel für den dritten Sprint ist die Nachspeise.

Der Product Owner hat zwei User Stories für das Sprint Planning mitgebracht.

User Story 1Als Gast in der neuen Premium Kantine möchte ich mit Geschäftspartnern aus Italien eine Himbeer-Mascarpone Schichtcreme genießen. Sie soll das italienische Menü gebührend abrunden, und die Partner sollen sich wohlfühlen.“
User Story 2Als Betreiber der neuen Premium Kantine möchte ich, dass die Details des Gerichtes in einem italienischen Ambiente präsentiert werden. Mein Ziel ist es, darüber zu entscheiden, ob ich das Gericht ins Kantinenprogramm aufnehme.“

 

Akzeptanzkriterien sind:
  • nicht zu süß
  • 15:00 Essen
  • kleine Gläschen
  • mediterran angerichtet
  • mindestens zwei Schichten, obenauf Himbeeren

Das Ergebnis des Sprint Plannings findet sich am Taskboard:

Taskboard agiles Projektmanagement
Abbildung 2: Taskboard – eigene Darstellung

Stell Dir vor, ein Teammitglied muss wegen einer dringenden Telefonkonferenz das Team für einige Zeit verlassen, und Du übernimmst dessen Platz.

Frage 1: Welche Fragen stellst Du, um möglichst schnell mit der Arbeit anfangen zu können?

Frage 2: Mit wem klärst Du Deine Fragen?

Frage 3: Ist das Taskboard, so wie es aufgebaut ist, aus Deiner Sicht geeignet, damit das Team selbstorganisiert arbeiten kann? Findest Du Dich mit den Aufgaben gut zurecht? Aus welchen Gründen ist dies so?

Interesse an der Lösung?

Auch für diesen Fall gibt es nicht die richtige Lösung. Schick uns gerne Deine Antworten per Kontaktformular oder poste einen Kommentar unter diesen Beitrag, dann senden wir dir umgehend die Musterlösung, das heißt unsere Empfehlungen mit der Projektsituation umzugehen, per Mail. Wir freuen uns auf deine Ideen!

Hier findest Du Teil 2, 3 und 4 der Projektmanagement-Reihe:

Zum 2. Teil des PM Quiz  – Sprint Backlog – Der Sprint kann los gehen!

Zum 3. Teil des PM Quiz – Reporting – Ist unser Projekt erfolgreich?

Zum 4. Teil des PM Quiz – Sprint Review – Was haben wir geschafft?

 

Mehr agiles Projektmanagement bekommst du hier

Agiles Anforderungsmanagement: die wesentlichen Kernelemente für erfolgreiche IT-Projekte

Immer häufiger werden IT-Lösungen nach dem Lean-Start-Up Prinzip realisiert. Beginnend mit der initialen Entwicklung eines, auf die Kernfunktionen fokussierten Produktes zum Markteinstieg („Minimal Viable Product – MVP“), wird das Produkt nach dem Go-Live durch direktes Marktfeedback, weiterentwickelt und optimiert.

Das erfordert ein entsprechendes Umdenken, auch im Anforderungsmanagement. Was sind die wesentlichen Kernelemente, die beim agilen Anforderungsmanagement über Erfolg und Misserfolg eines Softwareprojektes entscheiden?

Eine Frage auf die es vermutlich viele verschiedene Antworten gibt. In folgendem Blogbeitrag wollen wir uns dem Thema auf den drei Ebenen „Prozess“, „Tooling“ und „Mindset“ annähern und praxisnah darauf eingehen, wie agiles Anforderungsmanagement in diesen Bereichen jeweils Beachtung finden kann. Die Inhalte stammen größtenteils aus unserem Vortrag, den wir auf der ModernRE 2019 in Berlin gehalten haben.

Der Prozess: Von der Idee zur spezifizierten Anforderung

In einem Projekt liegt die thematische Verantwortung beim Fachbereich. Daher erstellt und aktualisiert dieser regelmäßig die Vision des Produkts – das Zielbild. Anhand dieser Vision werden viele Ideen abgeleitet um dieses Zielbild zu erreichen.

Die technische Verantwortung liegt wiederum beim IT Team. Das IT Team hat eine etwas andere Perspektive auf das Produkt und daher auch andere Ideen, als der Fachbereich, Im besten Falle ergänzen sich die Sichtweisen der IT mit der des Fachbereiches.

Von der Idee zur spezifizierten Anforderung
Abbildung: Von der Idee zur spezifizierten Anforderung

Eine Besonderheit ist es, dass alle Teammitglieder dazu aufgerufen sind ihre Ideen an einen eigens hierfür eingerichteten Bereich, dem sogenannten Ideen-Backlog, einzutragen und zu detaillieren. Ideen kommen dabei von einzelnen Teammitgliedern, die Verbesserungs- und Optimierungspotenziale erkannt haben, von externen Studien, in Form von direktem Feedback von Kunden, oder Dritten aus dem Markt.

In regelmäßigen Abständen findet durch den Fachbereich eine Begutachtung aller neuer Ideen aus dem Ideen-Backlog statt. Bei der inhaltlichen Prüfung der Ideen wird der bereits priorisierte Backlog betrachtet, sodass neue Ideen, die weiterverfolgt werden sollen, direkt priorisiert werden können. Auf diese Weise ist sichergestellt, dass immer die Idee als nächstes im Detail spezifiziert wird, die den größten Nutzen für Dritte und Kunden stiftet oder die größte Relevanz für das Produkt hat.

In der Spezifikation werden die Themen detailliert und im Sinne des Anforderungsmanagements spezifiziert. Es müssen beispielsweise Stakeholder ermittelt werden, die in einem Kick-off-Termin in das Vorhaben eingeweiht werden. Erste Erkenntnisse und Anforderungen werden notiert und grafisch in Form von Wireframes, Mockups oder mittels eines passenden Diagrammtyps aufbereitet. Ein Spezifikationstemplate hilft, wiederkehrende Fragen und Sachverhalte standardisiert zu betrachten und so keine wichtigen Aspekte zu vergessen. Klassische Ansätze kommen an dieser Stelle ebenfalls zum Tragen. Anforderungen müssen erhoben, analysiert, spezifiziert und validiert werden.

Nach jeder Spezifiaktionsphase steht das Review der fertigen Spezifikation an. Für das Review wird ein Teilnehmerkreis, bestehend aus dem Fachbereich und einem dedizierten IT-Ansprechpartner, dazu eingeladen, Feedback zur Spezifikation abzugeben. Um technische Risiken und die Umsetzbarkeit zu prüfen, sollte eng mit dem IT Team zusammen gearbeitet werden. Zusätzlich nehmen Kollegen aus der IT einen anderen Betrachtungswinkel ein und decken so zum Beispiel häufig noch nicht betrachtete Randfälle auf. Am Ende eines definierten Zeitraums ist es die Aufgabe des Autors, das Feedback zu konsolidieren, zu sichten und in die Spezifikation einzuarbeiten.

Am Ende steht eine finale Version der Spezifikation (v1.0), die sowohl vom Fachbereich, als auch vom IT Team gleichermaßen mitgetragen wird. Prozessual wird die fertige Fachspezifikation im IT-Refinement vom Fachbereich an das IT Team übergeben, Letzte Zusammenhänge werden betrachtet und ein einheitliches Verständnis hergestellt. Anschließend werden aus der Spezifikation User Stories für das Product Backlog der Software Entwicklung abgeleitet, definiert, priorisiert und detailliert.

Tooling in einer kollaborativen & verteilten Arbeitswelt

Ein toller Prozess allein reicht nicht aus! Es sind Tools notwendig, die diesen kollaborativen Ansatz ermöglichen und unterstützen. Zumeist werden zwei Tools in Kombination, beispielthaft JIRA und Confluence aus der Atlassian Suite, eingesetzt, um diesen Prozess abbilden zu können.

In einem Ticketingtool (Abbildung: Requirements Board im Ticketingtool) wird ein Kanban Board erstellt. Dort werden sämtliche Prozessschritte abgebildet, um den Überblick über alle Themen im Prozess zu behalten. Die Tickets im Status „Ready for Specification“ stellen den bereits priorisierten Backlog dar, der aus dem Ideen-Backlog gespeist wird. Ideen, die keine Relevanz für das Produkt liefern, werden hier schon gar nicht mehr berücksichtigt. Themen, die sich momentan in der Bearbeitung befinden – sei es in der Erstellung der Spezifikation („In Specification„) oder im Review („In Review„) – werden per Drag-and-Drop in den entsprechenden Status gezogen. Durch die Verlinkung des Tickets zur Spezifikation besteht die Möglichkeit, in einem Klick vom Ticketingtool zum Kollaborationstool (Erklärung im nachfolgenden Absatz) zu springen. In die entgegengesetzte Richtung ist dies ebenso möglich. Auf diese Weise werden unnötige Tool- und Systembrüche vermieden und Arbeitsabläufe effizienter gestaltet. Aus Fachbereichssicht ist eine Spezifikation, nach dem das Review beendet wurde, mit der Übergabe an das IT Team („Handover to IT„) fertiggestellt. Um eine vollständige Dokumentation zu gewährleisten, ist es notwendig, dass diese um die umgesetzten Funktionserweiterungen ergänzt wird („Documentation done„). Erst jetzt ist der Zeitpunkt erreicht, an dem man guten Gewissens von einer umgesetzten Anforderung sprechen kann.

Requirements Board im Ticketingtool
Abbildung: Requirements Board im Ticketingtool

In einem Kollaborationstool findet die Dokumentation der Spezifikation und das Review statt. Zwischen den beiden Tools sind Verlinkungen der entsprechen Tickets und Spezifikationen möglich, um so direkt vom einen in den anderen Bereich springen zu können. Zusätzlich lassen sich Workshops ebenfalls im Kollaborationstool dokumentieren und als Entscheidungsprotokolle direkt in die Spezifikation verlinken. Durch zahlreiche Add-ons kann der Funktionsumfang eines Kollaborationstools sehr individuell auf die Bedürfnisse im Projekt und Prozess angepasst werden. So können beispielsweise Wireframes direkt im Kollaborationstool selbst erstellt und bearbeitet werden.

Der wohl größte Vorteil durch den Einsatz eines Kollaborationstools ergibt sich bei der Durchführung des Reviews einer Spezifikation. Vor dem Umzug in der Spezifikation in das Kollaborationstool wurde das Review anhand eines Word-Dokuments durchgeführt, wodurch je Review-Teilnehmer eine Version des Dokuments auf dem Fileserver abgelegt wurde. Die Aufgabe des Requirements Engineers bestand daraus, das Feedback zu konsolidieren und in die Spezifikation einzuarbeiten. Bei doppelten oder gar widersprüchlichen Kommentaren in den unterschiedlichen Review-Dokumenten führte das zu erhöhtem Abstimmungs- und Klärungsaufwand mit den entsprechenden Review-Teilnehmern. Durch den Umzug in das Kollaborationstool kann nun auf die vollen Funktionsumfänge zur Unterstützung und Verbesserung der Kollaboration unter den Review-Teilnehmern und des Requirements Engineers zurückgegriffen werden. Die Inline-Kommentarfunktion (Abbildung: Spezifikation und Review im Kollaborationstool) bietet die Möglichkeit, dass jeder Review-Teilnehmer durch Markieren einer Textstelle einen Kommentar platzieren kann, welcher für alle anderen Review-Teilnehmer sichtbar ist. Auf diese Weise werden Dopplungen vermieden, es entstehen Diskussionen, die neue Themen aufwerfen oder etwaige Rückfragen direkt klären. Für den Requirements Engineer verringert sich der Konsolidierungsaufwand des Review-Feedbacks signifikant, da nun mehr alle Kommentare in einem Dokument zu finden sind, Dopplungen und Widersprüche leichter zu identifizieren und aufzulösen sind.

Spezifikation und Review im Kollaborationstool

Abbildung: Spezifikation und Review im Kollaborationstool

Am Ende eines jeden Reviews sind alle Teilnehmer dazu aufgefordert, zu bestätigen, dass das Review beendet wurde und anzugeben, ob eine weitere Abstimmung mit dem Autor der Spezifikation gewünscht wird.

Review Log am Ende jeder Spezifikation

Abbildung: Review Log am Ende jeder Spezifikation

Mindset

Damit ein Projekt erfolgreich abgeschlossen werden kann, benötigt es mehr als funktionierende Prozesse und moderne Tools. Häufig wird ein wichtiges Kernelement übersehen: Das Mindset. Nur wenn die Menschen im Projekt kooperativ und auf das Projektziel ausgerichtet arbeiten, greifen die Prozesse und Tools effektiv ineinander. Heutzutage stoßen wir in Projekten jedoch häufig auf sogenannte Silos (z.B. bei verschiedenen Abteilungen innerhalb eines Konzerns), die das Zusammenarbeiten erschweren können. Silos verfolgen im schlechtesten Falle eigene Ziele, welche auf den ersten Blick nicht immer mit den Zielen des aktuellen Projekts übereinstimmen.

Georg Jocham, Coach für Projektmanager und Führungskräfte, greift in einem seiner Podcasts zum Thema „Silos“, auf eine im Jahre 2005 durchgeführte Studie zurück. Hier zeigte der Sozialpsychologe Mark Levin, welchen negativen Einfluss Silodenken auf das Kooperationsverhalten über die eigene Gruppe hinaus haben kann. Dazu werden Fußballfans von Manchester United zu Beginn des Versuchs Fragen im Themenumfeld rund um ihren Verein gestellt. Anschließend kann beobachtet werden, dass die Hilfsbereitschaft unter den Teilnehmern gegenüber anderen Manchester Fans um ein Vielfaches höher ist, als gegenüber Fans eines rivalisierenden Vereins. Beim zweiten Teil der Studie werden weitere Manchester United Fans eingeladen. Nun wird mit Hilfe einer anfänglichen Umfrage jedoch der Fokus nicht auf den Verein gelegt, sondern auf die gesamte englische Liga. Interessanterweise ist die im Anschluss beobachtete Hilfsbereitschaft gegenüber Menschen, die dem rivalisierenden Verein angehören massiv gestiegen ist. Sie erreicht dabei fast dasselbe Niveau wie die Kooperation den eigenen Vereinskollegen gegenüber.

Die Studie zeigt wie eklatant sich das Kooperationsverhalten unterscheidet: Je nachdem welcher Gruppe sich Menschen zum aktuellen Zeitpunkt zugehörig fühlen und ob deren Gegenüber ebenfalls Teil dieser Gruppe ist oder nicht. Die Studie zeigt neben den Gefahren die Silos bergen können, bereits eine mögliche Lösung, um aus dem Dilemma zu entkommen. Menschen, die in einem Projekt über verschiedene Abteilungen oder Firmen zusammenarbeiten, benötigen eine gemeinsame Projektidentität. Diese muss möglichst früh im Projekt etabliert werden, z. B. durch Vermittelung des gemeinsamen Projektziels im gemeinsamen Kick-off zu Beginn des Projekts.
Ist eine Projektidentität geschaffen muss sichergestellt werden, dass diese Bestand hat. Innerhalb dieses Projektteams haben sich zwei grundlegende Werte herausgeprägt die für den Zusammenhalt und eine funktionierende Zusammenarbeit innerhalb der Gruppe von großer Bedeutung sind: Wertschätzung und Vertrauen.

Ein wertschätzender Umgang im Projekt kann sich auf vielseitige Art und Weise äußern. So ist es zum Beispiel wertschätzend, andere nach Ihrer Meinung zu fragen oder sich für geleistete Arbeit zu bedanken. Eine hohe Wertschätzung im Projekt kann dazu führen, dass das Team eine höhere Loyalität dem Projekterfolg gegenüber zeigt.
Auch ein hohes Maß an Vertrauen spielt eine nicht unwesentliche Rolle, ob ein Team die gemeinsam etablierten Prozesse und Tools optimal nutzen kann. Dazu muss sichergestellt werden, dass jeder Beteiligte sich darauf verlassen kann, dass das gesamte Team auf den Projekterfolg ausgerichtet ist und somit auch das Ansprechen von Risiken, Fehlern und auch das Einbringen der eigenen Meinung als einen Beitrag zu diesem angesehen werden. In Projekten in denen ein hohes Maß an Vertrauen herrscht, steigt die Transparenz und die Berührungsängste in fachlichen Diskussionen und im schriftlichen Austausch nehmen stark ab. Es geht wieder mehr um die Sache. Insbesondere Transparenz ist in agilen Frameworks, wie zum Beispiel Scrum, eine wesentliche Grundvoraussetzung.

Wertschätzung und Vertrauen im Projekt

Abbildung: Wertschätzung und Vertrauen im Projekt

Fazit

Jedes der drei obigen Themen würde mehr als einen eigenen Vortrag füllen. Das hat sich unter anderem auch in der Agenda der diesjährigen ModernRE 2019 gezeigt. So wurden auf der Konferenz eigene Vorträge zum Einsatz einzelner Tools im Anforderungsprozess und zum Zusammenspiel von Ticketing- und Kollaborationstools gehalten. Auch auf das Thema Mindset wurde in einem spannenden Vortrag mit dem Titel „Wie Teams wirklich Stark werden“ eingegangen.
Auch wenn die Rahmenbedingungen in IT-Projekten sehr unterschiedlich sind, so lohnt es sich doch von Zeit zu Zeit den eigenen agilen Anforderungsprozess unter die Lupe zu nehmen und bei Bedarf zu Überarbeiten. Besonders leicht fällt das, wenn man mit Tools arbeitet, die hier die notwendige Flexibilität mitbringen.

Wovon mit Sicherheit alle Projekte profitieren, unabhängig der Rahmenbedingung, ist ein wertschätzender und vertrauensvoller Umgang innerhalb eines gemeinsamen Projektziels.

Co-Autor Findan Eisenhut

 


Weiterführende Links

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Kundenzufriedenheit durch Erfüllung von Anforderungen – das Kano-Modell

 

Mehr zur Anforderungsanalyse für Softwareprojekte gibt’s hier

 

Agile Mixperience – die prickelnde Alternative zu Scrum Cooking

Mit Cocktails vermitteln, wie Scrum funktioniert

Nach jahrelanger Erfahrung mit dem Erfolgskonzept „Scrum Cooking“ inklusive optimierter Rezepte, zahlreichen neuen Koch-Skills und Kunden, die leckere Menüs genießen durften, wird es Zeit für ein wenig Abwechslung. Also warum die Methodik Scrum nicht bei einer Agile Mixperience erlernen? Statt 3-Gänge-Menüs werden hier Cocktails gemixt.

Es gibt zahlreiche Zertifizierungen, die sich mit den theoretischen Grundlagen der Projektmanagement-Methode Scrum beschäftigen. Wirklich nachhaltig lernt man am besten mit Praxisbezug und Spaß. Mit dem Workshop „Agile Mixperience“ vermitteln unsere Agile Coaches wie auch bei „Scrum Cooking“ die spezifischen Rollen, Prozesse und Artefakte der Methodik. Der eintägige Workshop wird entweder beim Kunden vor Ort oder in einer Location aus unserem Netzwerk durchgeführt. Die Teilnehmer lernen spielerisch die Grundprinzipien kennen, werden selbst aktiv und erleben unmittelbar die Effekte agiler Arbeitsmethoden. Sie schildern aus eigener Erfahrung:

„Es geht nur mit Kooperation.“
Für die Bearbeitung unserer strategischen und organisatorischen Aufgaben haben wir im Management Team agile Methoden schätzen gelernt. Die „Agile Mixperience“ hat uns ganz schnell wieder vor Augen geführt, dass eine reibungslose Kooperation im Team das A und O für den Erfolg des agilen Ansatzes ist.

 

„Raus aus der Falle „definition of (almost) done“
Seit Monaten arbeiten wir Product Owner mit unserem Entwicklungsteam agil zusammen und freuen uns über jede erfolgreiche Zwischenlieferung. Mit der Agile Mixperience wollten wir das Team nach einem Wechsel in verschiedenen Rollen neu zusammenschweißen. Wir haben aber noch mehr gelernt. Denn richtig lecker ist ein Cocktail erst, wenn er auch wirklich fertig ist und alle ihn genießen können.

 

„Agiles Arbeiten kann auch abseits der Software-Entwicklung sinnvoll sein.“
Wir standen vor der Frage, ob eine agile Arbeitsweise auch in unserem Vertriebsteam anwendbar ist. Nach dem Workshop steht fest: Wir werden nur gewisse Elemente aus dem Scrum Framework umsetzen können, diese jedoch konsequent bei uns etablieren. Nach der praktischen Anwendung zwischen Stößel, Shaker und Cocktails werden unsere Mitarbeiter jedenfalls nie wieder vergessen, was ein Scrum Master und ein Product Owner machen.

So funktioniert die Agile Mixperience:

  • Theoretische Einführung in das Scrum Framework, um bei den Teilnehmern ein gemeinsames Verständnis zu schaffen.
  • Team-Building und Verteilung der Rollen des Scrum Masters, Product Owners und der Teammitglieder.
  • Vorbereitung der Produktvision und des Product Backlog. Ziel ist es, dem „Kunden“ ansprechend dekorierte leckere Cocktails anbieten zu können – je nach Wunsch vom Virgin Cocktail bis zum Classic Cocktail.
  • Praktische Durchführung von drei Iterationen inklusive Sprint Planning, Sprint Review und Sprint Retrospektive, um das Erlernte zu festigen.
  • Gemeinsame Reflexion und Übertragung des Erlebten in die eigene Arbeitswelt.

 

Zusätzliche Herausforderungen entstehen durch Aktionskarten und veranschaulichen immer wieder, dass eine gute Planung, Transparenz und klare Kommunikation das A und O bei einer agilen Vorgehensweise sind. Auch die Zeit wird anfangs häufig unterschätzt. „Eine halbe Stunde für einen Cocktail? Das ist doch keine Herausforderung!“ Und doch geraten die Teams zu Beginn in Hektik. Mit jedem Sprint wird die zuvor besprochene Theorie verständlicher und besser angewendet – das Team schwingt sich ein, es lernt dazu und arbeitet in der nächsten Iteration produktiver.

doubleSlash Agile Mixperience Cocktails
Abbildung 1: Hanami-Cocktail bei einer Agile Mixperience mit doubleSlash im September 2019 in München

Während des gesamten Tages werden die Teilnehmer durch erfahrene Agile Coaches begleitet, die alle selbst in unterschiedlichen Rollen in agilen Projekten arbeiten.

Fazit: Agile Mixperience – für jedes agile Level und individuell nutzbar

Agile Mixperience schafft ein gemeinsames Verständnis im Projektteam und ist ideal für:

  • den Kick-off von anlaufenden agilen Projekten.
  • neue Projektmitglieder, die in laufende agile Projekte integriert werden.
  • erfahrene Projektmitglieder, die einen frischen Blick auf Ihre Scrum-Praxis werfen möchten.
  • Unternehmen, die sich eine Einführung von agilen Arbeits- und Entwicklungsmethoden überlegen.

 

Mehr Agile Workshops gibt es hier

 

Gemeinsam mit verschiedenen Kunden haben wir den Workshop „Agile Mixperience“ bereits erfolgreich verprobt. In lockerer Atmosphäre holen wir die Teilnehmer mit unterschiedlichsten Wissensständen ab – von Scrum Anfängern bis zum erfahrenen Scrum Master. Unser Ziel ist es, die Methodik verständlich zu vermitteln, den Teilnehmern die Scheu vor der praktischen Anwendung zu nehmen und die Essenz für die eigene Arbeitswelt mitzugeben.

 

HIer kostenfrei unsere Magic Estimation Karten zur effizienten Scrum Aufwandsschätzung

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

 

Mal über den Tellerrand geschaut: Was können Softwareprojekte von sozialen Projekten lernen?

Am kommenden Samstag startet in Friedrichshafen wieder das Entenrennen auf dem Seehasenfest. Ein soziales Projekt, das auch von doubleSlash wieder als Hauptsponsor unterstützt wird und über das seit über zwölf Jahren jährlich 20.000 Euro Spendengelder für bedürftige Familien in der Region eingesammelt werden. Eine Erfolgsgeschichte, von der auch Softwareprojekte lernen können? Schauen wir uns die Erfolgsfaktoren einmal genauer an.

Die Projektvision

Das Projekt begann mit der irrwitzigen Idee, 5000 gelbe Gummienten auf einem See, also ohne Strömung, in ein Ziel schwimmen zu lassen. Durch den Verkauf von „Entenlosen“ wollte der Lions Club Friedrichshafen bedürftigen Familien in der Region helfen, die sonst durch die Raster des Sozialstaates fallen. Ein Ziel, dass den Seehasenfestausschuss, die freiwillige Feuerwehr, den THW, die Firmen und Einzelhändler der Region und die Bürger so sehr begeistert hat, dass bereits im ersten Jahr alle Lose verkauft und die volle Summe von 20.000 Euro ausgeschüttet werden konnte. Damit wären wir bei dem ersten Erfolgsfaktor, für ein soziales Projekt: Eine starke Projektvision.

Das erste Rennen – Noch klein, aber es funktioniert

Das Projekt fing natürlich nicht gleich perfekt an, sondern mit einem ersten MVP (Minimum Viable Product). Übersetzt heißt das: eine kleine Version des Rennens, die funktions- und überlebensfähig ist. Die technischen Hürden um Strömung zu erzeugen, die Reihenfolge der einschwimmenden Enten zu registrieren, die Informationen zum Rennen an die Zuschauer zu vermitteln. All das wollte noch mit hohem manuellem Aufwand gemeistert werden. Die Enten waren von einem anderen Club entliehen und wurden am Renntag per Hand aus ihren Säcken gewassert und nach dem Zieleinlauf mit Körben aus dem Wasser gefischt. Das Rennen fand pünktlich statt. Die Enten wurden korrekt registriert. Die Inhaber der Gewinnerlose konnten sich über ihre Preise freuen. Der zweite Erfolgsfaktor für das soziale Projekt ist gefunden: Eine erste Version (ein MVP), die den erhofften Nutzen bereits bringt.

Sukzessive Weiterentwicklung mit vielen engagierten Beteiligten

Nach dem Rennen ist vor dem Rennen. In einer Retrospektive wurde aus Fehlern gelernt und Verbesserungspotenzial zur Skalierung identifiziert. Bei aller Liebe zur Automatisierung bestimmter Abläufe war immer klar: Das darf die Ausschüttung an die Familien nicht schmälern. D.h. alles was Rennen für Rennen investiert werden musste,  brauchte einen Sponsor. Die Preise, eigene Enten für Friedrichshafen, Chips für die Enten zum automatischen Auslesen am Ziel, ein Zieleinlauffloß mit Registrierungssensoren und dieses Jahr erstmals ein Startfloß aus Pontons. All das wäre ohne die Sponsoren und freiwilligen Helfer nicht möglich gewesen, die es zu finden und zu motivieren galt. Der dritte Erfolgsfaktor heißt also: Intensives Stakeholdermanagement.

Alle machen mit

Ein soziales Projekt dieser Größenordnung lässt sich nur umsetzen, wenn alle an einem Strang ziehen. Dazu gehört der „Product Owner“, der die Idee ins Leben gerufen hat und seit zwölf Jahren weiterentwickelt. Ebenso wichtig ist das Kernprojektteam, das sich um Planung,  Akquise der Preise, Vorbereitung der Lose, Umsetzung organisatorischer und technischer Anpassungen, Verkauf der Lose, sowie die technisch organisatorische Umsetzung des Rennens und der Preisverteilung kümmert. Dazu kommen Seehasenfestausschuss, freiwillige Feuerwehr und THW, ohne die die Organisation unmöglich wäre. Die Sponsoren von Preisen und notwendigen Investitionen. Die ehrenamtlichen Helfer und Einzelhändler, die die Lose verkaufen. Und nicht zuletzt die vielen engagierten Bürger, die jedes Jahr ihre Lose kaufen. All diese Menschen zusammen machen den Erfolg des Sozialprojektes aus. Damit wären wir bei dem vierten und vielleicht wichtigsten Erfolgsfaktor für Projekte: ein starkes Commitment aller Beteiligten.

Erfolgsfaktoren für Softwareprojekte

In Softwareprojekten sind zunehmend agile Vorgehensweisen die Arbeitsmodelle der Wahl. Man verspricht sich durch ein iteratives Vorgehen eine Verringerung der Projektrisiken. Häufig wird Scrum mit seinem einfachen und gut durchstrukturierten Rahmenwerk aus Rollen, Meetings und Artefakten als Basis verwendet. Inzwischen gibt es viele Projektmanagement Tools auf dem Markt, die ein solches agiles Vorgehen unterstützen. Trotzdem – oder vielleicht gerade deswegen – beobachten wir immer wieder, dass gerade in großen Projekten ein paar wichtige Bausteine für erfolgreiche Softwareprojekte wieder mehr in den Hintergrund geraten:

  • Das Einschwören des Teams auf eine gemeinsame Produktvision.
  • Der unbedingte Wille aller Beteiligten, den Nutzen jeder Iteration zu erreichen.
  • Transparenz und intensives Einbeziehen der Stakeholder außerhalb des Kernteams.
  • Die Zentrierung auf die Interaktion der Menschen im Projekt.

Mein Fazit:

Es lohnt sich als Kunde, Projektmanager oder Sponsor eines Softwareprojektes mal über den Tellerrand zu schauen und sich wieder auf vernachlässigte Werte zu besinnen. Und wenn im Projekt alles so läuft wie es soll, muss man das nicht als selbstverständlich nehmen und darf den Erfolg auch mal feiern.

Mob Testing: Kollaboratives Testen und Wissenstransfer

Als Test Manager, der vor allem fachliche, manuelle Tests betreut, habe ich insbesondere ein Thema des diesjährigen German Testing Days in Frankfurt mitgenommen: Mob Testing aus einem Vortrag von Katharina Warak und Benedikt Wörner (beide Maiborn Wolff).

Beim Mob Testing handelt es sich um eine kollaborative explorative Testmethode. Kollaboratives Testen hat per se schon den Vorteil, dass mehrere Tester einfach mehr sehen. Dies ist jedoch nicht der einzige Vorteil, den Mob Testing zu bieten hat.


Doch zunächst einmal zur Vorgehensweise:

Beim Mob Testing gibt es folgende vier Rollen, die möglichst cross-funktional besetzt sein sollten (Projekt Manager, Fachbereich, Entwickler, Anwender, Tester, …):

  • Facilitator: beobachtet die Testsession, notiert die gefundenen Abweichungen (Findings) und achtet darauf, dass Regeln und Zeit eingehalten werden. Diese Rolle wird innerhalb einer Session als einzige nicht ausgewechselt.
  • Navigator: bestimmt die Vorgehensweise und gibt dem Driver Anweisungen.
  • Driver: führt die Anweisungen des Navigators aus, ohne sie infrage zu stellen oder mitzureden. Und das ist nicht so einfach, wie es klingt.
  • Mob: zwei bis fünf Personen im Mob beraten (auf Anfrage) den Navigator.

 

Mob Testing doubleSlash Christian Spohr
Bild: doubleSlash Christian Spohr

Nach einer fest definierten Zeit (meist zwischen 4 und 7 Minuten) werden die Rollen durchgewechselt, immer in der gleichen Reihenfolge. Je nach Größe des Teams wird also jeder mehrere Runden im Mob sein, aber immer nur einmal in Folge Navigator oder Driver.


Mob Testing bietet zahlreiche Vorteile:

  • Vier(oder mehr)-Augen-Prinzip: Mehr Tester entdecken mehr Fehler und kommen im explorativen Test auf mehr Ideen, auch abseits der Standardprozesse zu testen.
  • Vielfältige Perspektiven: Wenn die Besetzung des Test-Teams möglichst breit gefächert ist, führen die unterschiedlichen Blickwinkel nicht nur zu einer breiter gestreuten Durchführung des Tests, sondern helfen auch, andere Herangehensweisen bzw. Perspektiven als die eigenen kennenzulernen.
  • Wissenstransfer: Durch die unterschiedlichen Blickwinkel und Vorgehensweisen wird auch Wissen gestreut. Beispielsweise sieht ein Entwickler, wie der Fachbereich mit der Applikation umgeht und entwickelt ein Verständnis dafür und umgekehrt.
  • Interdisziplinär: Die Kommunikation zwischen den Teilnehmern und damit ihren Arbeitsbereichen wird gefördert.
  • Group Thinking: Aus dem gemeinsamen Erlebnis von Problemstellungen und daraus resultierenden Anforderungen zieht das Team an einem Strang und findet sich leichter in einer gemeinsamen Lösung wieder.
  • Rotation: Eher zurückhaltende Kollegen finden sich ohne großen Stress in einer Rolle wieder, in der sie Entscheidungen treffen (als Navigator). Andere, die sonst eher im Vordergrund stehen, müssen damit leben, nur auf Nachfrage zu beraten (in der Mob-Rolle) oder Dinge wider (vermeintlich) besseren Wissens durchzuführen (als Driver).
  • Nicht zuletzt: eine Mob Testing Session macht Spaß! Für viele Beteiligte ist das ein Raus-aus-der-Routine, etwas Neues kennenlernen – und der Zusammenhalt wird gestärkt.

 

Mob Testing bietet sich an:

 

  • als ganzheitlicher Prüfstand für ein Produkt.
  • als regelmäßiger Event, um allen im Projekt Beteiligten das Produkt, an dem sie arbeiten, greifbar zu machen und up to date zu bleiben. Das betrifft auch Bereiche, an denen sie in ihrer täglichen Arbeit selbst nicht tätig sind.
  • als Einführung für Kollegen, die neu in ein Projekt / Team kommen. So lernen sie das Produkt auf einfache Art und Weise praktisch kennen.

 

Ich bin sehr gespannt, wie sich Mob Testing in unterschiedlichen Projekten bewährt. Im Gespräch mit Entwickler-Kollegen hat sich übrigens herausgestellt, dass sie dieses Vorgehen in ihren Coding Dojo Sessions ebenfalls anwenden, um so Wissen im Bereich Softwareentwicklung zu verteilen.
Ich denke, diese vielversprechende Methode ist so vielseitig einsetzbar, dass es sich lohnt, sie als Option zu betrachten, wenn es um Tests oder Wissenstransfer in unterschiedlichen Bereichen geht.

Mehr zu Testmanagement erfahren

 

Agile Starthilfe für Konzern IT´s – Warum die agile Transformation im Unternehmen gar nicht so leicht ist

Agile Starthilfe für ProjekteStudien zur Verbreitung agiler Methoden[1] haben ergeben, dass sich agiles Projektmanagement in den Unternehmen immer mehr durchsetzt. Aus IT Abteilungen von Konzernen wird uns in letzter Zeit sogar berichtet, dass sie inzwischen alle IT-Projekte agil abwickeln müssen. Gleichzeitig tut sich die Konzern IT schwer, ihre Softwareprojekte flächendeckend auf agil umzustellen. Wir beobachten das mitunter daran, dass wir gerade jetzt vermehrt Anfragen nach „agilen Starterpaketen“ für Softwareprojekte erhalten. Warum ist das so?

 

Mehr