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!

 

Mehr agiles Projektmanagement gibt es hier

 

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?

 

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

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

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!

 

Mehr agiles Projektmanagement bekommst du hier

 

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?

 

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

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

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!

 

Mehr agiles Projektmanagement bekommst du hier

 

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?

 

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

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

Welche Schlüsselrolle ein Systemintegrator bei der Einführung eines Subscription Management Systems hat

Dem Traum von plug and play: „Sie kaufen ein geeignetes System, integrieren es dann einfach und müssen nie wieder etwas tun“ müssen wir leider platzen lassen. Denn genau an dieser Stelle sagen wir als Systemintegrator aus der Erfahrung aus vielen Kundenprojekten heraus: Genauer hingeschaut oder da war noch was! Denn die unternehmensinterne System- und Prozesslandschaft ist häufig komplex aufgebaut und noch auf das „alte“, transaktionsbasierte, Geschäftsmodell ausgelegt – man spricht häufig von „historisch gewachsen.“ Das Subscription Management System einfach an die bestehende Landschaft anzukoppeln ist in der Praxis unmöglich – auch im SaaS-Modell. Wir reden hier von einer Herausforderung, denn bei Subscription Management Systemen handelt es sich um über Jahre gewachsene Systeme. Und gerade wenn der Druck für eine schnellstmögliche Umsetzung sehr hoch ist, hat sich die Zusammenarbeit mit einem Systemintegrator bewährt: Der eine ist der Profi für das Systemprodukt, der Integrationspartner adaptiert das System an die speziellen Anforderungen des Kunden und sorgt für eine erfolgreiche Integration in die bestehende System- und Prozesslandschaft.

Step by step mithilfe eines Systemintegrators in Richtung Zielgerade funktionierendes Subscription Management System

1/5: Anforderungsmanagement

Der Umstieg auf einen digitalen Service wird die bestehenden Geschäfts- und die dazugehörigen Abrechnungsprozesse in einem Unternehmen vollkommen verändern. Früher wurde ein Produkt angeboten, von einem Kunden erworben, gegebenenfalls noch gewartet oder ein neues nachgekauft und damit endete die Geschäftsbeziehung vorerst. Heute liegt der Fokus mehr und mehr auf einer langfristigen Kundenbeziehung die aktiv gestaltet werden muss. Als Systemintegrator müssen wir mit dem Unternehmen gemeinsam ermitteln, welche Anforderungen und Funktionen im individuellen Kontext des Kunden tatsächlich benötigt werden.

2/5: Business und IT-Integration

Sind einmal die Anforderungen definiert, werden mit allen Stakeholdern die Anpassungsbedarfe an die bestehenden Business- und IT-Prozesse sowie den IT-Systemen ermittelt. Alle relevanten Schnittstellen sind hierbei zu beachten – auch zu externen Providern. Diese bieten diverse Dienste an, beispielsweise die regelmäßige Prüfung der Gültigkeit der Kreditkarte eines Abonnenten. Als erfahrene Systemintegratoren wissen wir außerdem um den hohen Stellenwert des IT-Designs. Es ist von essentieller Bedeutung für die Entwickler, wird jedoch häufig unterschätzt. Das Design gleicht einem ausgearbeiteten Entwurf eines Architekten. Ohne diesen wüssten die ausführenden Fachkräfte nicht, dass das Gebäude nicht nur vier Außenwände und ein Dach, sondern auch Fenster und Innenwände haben soll. Es wird also bis ins kleinste Detail geplant, wie das Gebäude am Ende aussehen soll. Wenn nun kein eindeutiges IT-Design besteht, könnte die Entwicklung in eine falsche Richtung gehen. Die Folge wäre sowohl ein extrem erhöhter Zeitaufwand, als auch zusätzlich anfallende Kosten. Es ist von enormer Wichtigkeit die Entwickler abzuholen und genaue Vorgaben zu entwickeln, die auch auf Detailfragen eingehen. An dieser Stelle ist dann ein Systemintegrator mit einem guten Know-how unabdingbar, da er weiß worauf ein Augenmerk gelegt werden muss.

3/5: Umsetzung im agilen Modell

Die Umsetzung erfolgt im agilen Entwicklungsmodell. Dabei widersprechen sich der agile Ansatz und ein detailliertes IT-Design aus unserer Sicht nicht. Wir haben aus unserem umfangreichen Erfahrungsschatz in Kundenprojekten eine intelligente Kombination aus beiden Welten herausgearbeitet und standardisiert. Dieser Lösungsansatz ermöglicht eine schnelle Reaktionsmöglichkeit, beispielsweise bei sich verändernden Anforderungen. Der Integrator steht während des Prozesses in engem Austausch mit dem Kunden sowie dem Produktanbieter.

4/5: Absicherung

Vom Modultest bis zur End-2-End-Absicherung – ein guter Systemintegrator setzt auf ein automatisiertes Testen, damit sich die Absicherung zeitsparender umsetzten lässt; vor allem wenn es um Regressionstests geht.

5/5: Marktrollout

Es ist wichtig, dass die Lösungen an die Gegebenheiten des Marktes angepasst werden. Vier Aspekte müssen hierbei beleuchtet werden:

  1. Der technische Aspekt: die lokale IT-Infrastruktur
  2. Die rechtlichen Aspekte im Markt
  3. Kulturelle Aspekte: z.B. welche Zahlungsvorlieben herrschen im Markt
  4. Die Berücksichtigung organisatorischer Aspekte (was für den einen Standort funktioniert, ist nicht zwingendermaßen auch an einem anderen möglich)

 

Das könnte Dich auch interessieren: „Welchen Einfluss hat das Subscription Management auf das Kundenerlebnis?“

Fazit

Der Vorteil bei einem erfahrenen Integrator ist, dass er weiß worauf er achten muss und worauf es ankommt. Er kennt nicht nur die typischen IST-Prozesse und Hürden bis zu der erfolgreichen Anbindung eines Subscription Management Systems. Die Wahl eines unerfahrenen Integrators kann fatale Folgen nach sich ziehen. Wichtigster Faktor ist der zeitliche Aspekt. Wenn ein Systemintegrator bei der Einführung erst selbst noch mitten im Lernprozess steckt und nicht bereits umfangreiche Erfahrung gesammelt hat, kann dies zu zeitlichen Verzögerungen und damit zu erhöhten Kosten führen. Die Auswahl eines unerfahrenen Systemintegrators könnte weiterhin dazu führen, dass die Lösung nicht den Kundenvorstellungen entspricht. Dies rührt daher, dass der Integrator den Kunden im Prozess nicht frühzeitig auf Probleme oder suboptimale Lösungsansätze hingewiesen hat, die er aus eigener Erfahrung einschätzen kann.

Ein guter Systemintegrator sollte also Erfahrung mitbringen und ein breites Spektrum an Branchenwissen vorweisen. Dadurch ist das Verständnis für die Bedürfnisse der Kunden in der jeweiligen Branche gegeben. Aus technologischer Hinsicht sollte er ebenfalls ein absoluter Profi sein.

 

Was gilt es bei der Auswahl eines Subscription Management Systems zu beachten?

Hier kostenloses Whitepaper herunterladen

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!

 

Mehr agiles Projektmanagement bekommst du hier

 

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?

 

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

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

Behavior-Driven Development – Problemlos einsetzbar in agilen Bestandsprojekten?

Im Jahr 2012 wurde das Expenditionary Combat Support System der US Air Force nach sieben Jahren und mit Entwicklungskosten von über einer Milliarde Dollar abgeschafft. Als Grund wird angegeben, dass das System trotz siebenjähriger Entwicklungszeit keine nennenswerten, militärischen Fähigkeiten erbracht hat [1]. Und dieses Projekt stellt kein Einzelfall dar. Rund die Hälfte aller Softwareprojekte liefert keine wesentlichen Ergebnisse [2]. Hinzu kommt, dass viele Projekte abgebrochen oder nicht rechtzeitig fertig werden. Gründe hierfür gibt es mehrere. Zum einen kann es vorkommen, dass die Software nicht fehlerfrei funktioniert. Zum anderen wird oft nicht das umgesetzt, was ursprünglich von Kunden angefragt wurde. Mehr

Oerlikon Hackathon powered by doubleSlash Experten

Am Wochenende des 08.11.2019 bis 10.11.2019 hat doubleSlash eine tolle Veranstaltung als Experten begleiten dürfen: Den ersten Hackathon der Oerlikon Group in toller Atmosphäre des Oerlikon Digital Hub. Neben Workshop Räumen und sogar einem Kino ist das technische Setup exzellent und erleichterte allen Teilnehmern die Arbeit.

Hackathon? Pures Wissen in agiler Lösungskompetenz

Pragmatisch und agil in einem: Ziel ist es, innerhalb der Dauer einer Hackathon Veranstaltung gemeinsam nützliche, kreative oder unterhaltsame IT – oder Software Produkte oder –Anwendungen herzustellen und so Lösungen für bestehende Probleme zu finden.

Ein breiter Mix an talentierten Personen

Die Zielgruppe des Events war ein sehr breiter Mix an talentierten Personen: von Softwareentwicklern über Data Scientists bis hin zu Spezialisten der Industrie. Die rund 80 Teilnehmer setzten sich zusammen aus Studenten, Softwareentwicklern bis hin zu Data Scientists und Oerlikon Mitarbeiter.

Die Challenges waren in 4 Kategorien aufgeteilt: IoT, Computer Vision, Data Science und Waste Reduction – wobei die letzte Kategorie sich wohl auch in die Data Science Aufgaben einsortieren lässt. Unter diesen Kategorien gab es je bis zu zwei Challenges – in Summe 7 Challenges. Für jede Challenge konnten sich nur eine definierte Zahl Teams anmelden, um sicher zu stellen, dass alle Challenges angegangen wurden.

Fünf doubleSlash IoT und KI Experten vor Ort

Auf Anfrage von Oerlikon beschloss doubleSlash das Event als Sponsor in Form von fünf Experten zur Unterstützung der Teilnehmer zu stärken: Vincenzo Crimi, Nico Mutter, Andreas Nuber, Timo Demler und Ralf Richter. Wir gaben Hilfestellung in den Bereichen Consulting, Coding, Architektur, technischer Spezialisierung mit PTC und Microsoft Azure, aber auch im Bereich Organisation und Strukturierung. Unsere Experten standen den Teams zur Seite, indem sie sie berieten und bei der Entwicklung weiterhalfen, ohne dabei Einfluss auf den Lösungsweg zu nehmen.

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Gemeinsam mit unserem Partner PTC beschlossen wir bereits zu Beginn des Hackathons, unsere gewohnte enge Zusammenarbeit für den Support an den Teams zu leisten. Neben dem Mentoring für die Teams lieferten wir zwei tolle Workshops in den Bereichen Ideation und Pitch Training. Beide Workshops wurden ein toller Erfolg und leisteten einen wertvollen Beitrag für das Gelingen des Hackathon.

 

 

 

 

 

Fazit

Das Engagement unserer Experten für die Teams war beachtlich und ging über die Grenzen eines normalen Arbeitstages hinaus. Alle Teilnehmerteams schätzten diesen Support  spürbar, auch während der Pitches kam positives Feedback. Wir haben auch in anderen Formaten sehr positive Erfahrungen mit diesem agilen Veranstaltungsformat gemacht und sehen hier den deutlichen Mehrwert: Schwarmintelligenz in agiler Atmosphäre schafft gemeinsam innovative Lösungen zu konkreten Problemen.
Besonders stolz sind wir darauf, dass alle Teams, die von der doubleSlash Hilfe aktiv Gebrauch machten, in die Finals kamen. Besonders freuen wir uns über den Erfolg unseres doubleSlash-Studenten-Teams: Sie haben von 17 Teams einen sehr guten Platz 4 erarbeitet. Wir freuen uns auf kommende Events, die wir als doubleSlash begleiten können oder sogar selbst ausrichten werden.

 


Mehr zur KI und IoT Kompetenz von doubleSlash

Mehr zum Oerlikon Digital Hub

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

 

 

Die Feature Progression Map: Reporting-Vorlage in agilen Projekten

Gute Kommunikation ist alles – das gilt im Besonderen für große Softwareprojekte. Während die agilen Methoden sehr viel für die Kommunikation innerhalb des Teams tun, sind Stakeholder, die nicht Teil des Teams sind, meistens außen vor. Sie haben häufig keine Zeit, um an Reviews teilzunehmen oder sich mit den User-Stories zu beschäftigen.Mehr