Sie kommen in Bezug auf Stakeholder-Engagement nicht weiter? Probieren Sie den Agile-Ansatz!
Stakeholder-Engagement wird bei komplexen Projekten immer wichtiger. Wenn Sie weiterhin enge Fehlermargen gegen potenziell große Ergebnisse abwägen, sollten Sie sicherstellen, dass die Stakeholder – jene Personen, die Ihren Erfolg entweder ausmachen oder zunichte machen können – richtig eingebunden werden. Gleichzeitig sollten Sie beim Thema Stakeholder-Engagement nicht übertreiben, damit Sie Ihrer eigentlichen Arbeit nicht im Wege stehen. Deswegen empfehlen wir den Agile-Ansatz, mit dem man Aufgaben auf einfache, konzentrierte und effektive Weise in Schach halten kann.
Grundlagen der Agile-Methode
Warum Agile?
Die Agile-Denkweise
Wie Agile funktioniert und warum Sie sich damit beschäftigen sollten
Grundlagen des Stakeholder-Engagements
Wer sind die Stakeholder?
Wie wählt man die richtigen Stakeholder aus?
Wie kann man Stakeholder kontinuierlich einbinden?
Was passiert, wenn man Stakeholder nicht einbindet?
Eine gemeinsame Vision des Produkts schaffen
Projektcharta
Kurzpräsentation des Projekts
Definition von „erledigt“
Modellbildung mit Agile
Wireframes
Personas
Stakeholder-Kommunikation
Persönliche Kommunikation
Wissensaustausch
1. Grundlagen der Agile-Methode
Warum Agile?
Der geschäftliche Schwerpunkt hat sich von der Herstellung von Waren hin zu Informationen und Daten verlagert. In den letzten Jahrzehnten haben Unternehmen ihren Schwerpunkt vermehrt von der Herstellung von Gütern auf Informationen und Daten gesetzt. Sie legen Wert auf den Besitz von Informationen und Daten und die Fähigkeit, diese zur Gestaltung/Optimierung von Waren und Dienstleistungen zu nutzen.
Die mit IT-Projekten verbundene Arbeit ist weniger eindeutig und klar definierbar als die Arbeit in herkömmlichen, industriellen Projekten. Aus diesem Grund führt die Anwendung traditioneller Managementtechniken und Planungen bei IT-Projekten häufiger zu Misserfolgen und Frustration.
Klassische Managementtechniken und Planungsmethoden lassen sich bei vielen IT-Projekten nicht zufriedenstellend umsetzen. Agile ist eine Sammlung jener Methoden und Strukturen, die beim Aufbau von IT-Produkten am effektivsten sind.
Die 4 Grundprinzipien von Agile
Mit Agile zu arbeiten funktioniert am besten mit einer agilen Herangehensweise, die Prioritäten neu ordnet:
Individuen und Interaktionen gehen vor Prozesse und Werkzeuge. Ja, wir brauchen Prozesse und Werkzeuge – sie sind logisch und vorhersehbar, und es ist schwer, ein Projekt ohne sie abzuschließen. Andererseits sind sie lediglich statisch und mehr für die Lösung alter und sich wiederholender Probleme und Aufgaben geeignet. Im Gegensatz dazu sind es die Menschen und ihre Interaktion, die neue Probleme lösen und in der Lage sind, innovativ zu sein und die Dinge voranzubringen.
Funktionierende Software geht vor umfassender Dokumentation. Software ohne angemessene Dokumentation ist schwer zu betreuen und zu warten. Aber eine umfassende Dokumentation ohne funktionierende Software ist nutzlos. Deshalb sollte die Dokumentation gerade rechtzeitig fertig und gerade umfassend genug sein, ohne dabei zum Hauptthema zu werden.
Zusammenarbeit mit dem Kunden geht vor Vertragsverhandlungen. Verwenden Sie einen flexiblen Vertrag, der eine vertiefte Zusammenarbeit mit dem Kunden ermöglicht. Das ist eine der besten Möglichkeiten, den Aufwand von Tätigkeiten mit geringem Wert (z.B. Besprechung, was zu tun ist, wenn sich der Projektumfang ändert) auf Ihre produktivste Arbeit zu verlagern.
Wir sind uns der traditionellen Change-Management-Prozesse bewusst, deren Vereinbarung viel Zeit und Mühe erfordert. Sie neigen eher dazu, Change-Suppression-Prozesse zu bewirken, was das Gegenteil von Agile ist. Daher empfehlen wir, nicht zu viel Zeit und Aufmerksamkeit in Change-Management-Klauseln zu investieren.
Auf Veränderungen zu reagieren geht vor Umsetzung nach Plan. Das bedeutet nicht, dass wir die Planung aufgeben sollten – wir brauchen immer noch Pläne, aber wir müssen akzeptieren, dass sie aufgestellt wurden, als wir am wenigsten über das Projekt wussten. Anstatt das Projekt wieder an den ursprünglichen Plan anzugleichen, sollten wir die Pläne öfter aktualisieren, damit wir uns an unvermeidliche Veränderungen anpassen können.
Flexible Denkweise: Invertiertes magisches Dreieck
Ein Projekt wird durch drei Hauptbedingungen definiert: Eigenschaften, Zeit und Kosten. Beim traditionellen Projektmanagement beschränken wir uns zunächst auf die Eigenschaften: Wir verbringen zu Beginn viel Zeit mit einer detaillierten Definition der Anforderungen und gehen davon aus, dass wir 100 % liefern werden.
Auf der Grundlage dieser Anforderungen schätzen wir den Zeit- und Kostenaufwand und fahren fort. Aber keine Schätzung ist 100 % perfekt, wenn man mit der Realität konfrontiert ist, daher müssten Zeit und Kosten flexibel sein, um 100 % der Projektfunktionalität zu liefern.
In Agile stellen wir die Einschränkungen auf den Kopf. Zu Beginn schränken wir die Zeit und die Kosten ein und akzeptieren, dass Umfang und Eigenschaften flexibel sind. Indem wir die Eigenschaften auf der Grundlage ihres Geschäftswerts priorisieren, ist die Zuweisung von Zeit und Kosten relevanter. Auch wenn sich die ursprüngliche Schätzung ändert, werden die wichtigsten Funktionen bereits geliefert – innerhalb der vereinbarten Zeit und zu den vereinbarten Kosten.
Wir sehen daher zwei Hauptvorteile von Agile gegenüber der traditionellen Planung:
- Die (Fix-)Kosten und der Zeitrahmen sind Ihnen bekannt.
- Sie können sich darauf konzentrieren, (etwa) 75 Prozent der Funktionalität zu liefern, die 95 Prozent des Geschäftswerts des Projekts abdecken.
Wie Agile funktioniert und warum Sie sich damit beschäftigen sollten
Das traditionelle Modell wird Wasserfallmodell genannt, weil es eben wie einer aussieht: Es ist eine lineare Abfolge von Schritten, die Sie zum großen, endgültigen Ergebnis führen.
Die festgelegten Arbeitsschritte sind:
- Anforderungen definieren
- technische Architektur entwerfen
- die eigentliche Entwicklung des Produkts abschließen
- das Produkt testen
- bereitstellen
Agile folgt mehr oder weniger den gleichen Schritten, aber in kleinerem Umfang und durch mehrere Iterationen, d.h. schrittweises Erreichen eines zufriedenstellenden Ergebnisses.
Weitere Vorteile ergeben sich aus den wiederholten, schrittweisen Lieferungen:
- mehr Geschäftswert
- weniger Risiko
- bessere Sichtbarkeit
- mehr Anpassungsfähigkeit
2. Grundlagen des Stakeholder-Engagements
- Wer sind die Stakeholder?
- Wie wählt man die richtigen Stakeholder aus?
- Wie kann man Stakeholder kontinuierlich einbinden?
- Was passiert, wenn man es nicht tut?
Wer sind die Stakeholder?
Die Stakeholder sind alle Personen oder Personengruppen, die vom Projekt betroffen sind oder einen Einfluss auf das Projekt haben werden. Dazu können gehören:
- Kunden
- Unternehmensberater
- Endbenutzer
- Führungskräfte
- Händler
- Lieferanten
Wie wählt man die richtigen Stakeholder aus?
Es ist entscheidend, die richtigen Stakeholder zu finden – und Sie sollten sich darum bemühen. Je mehr von diesen drei Eigenschaften in einem Stakeholder vertreten sind, desto besser:
- Der Stakeholder hat das richtige Wissen.
- Der Stakeholder kann Entscheidungen treffen.
- Der Stakeholder hat Autorität.
Hier finden Sie, wonach Sie suchen müssen: Wissen: Personen, die die Anforderungen, Merkmale, technischen Aspekte, bestimmte Regeln oder rechtliche Zwänge des Projekts abdecken.
Wissen: Personen, die die Anforderungen, Merkmale, technischen Aspekte, bestimmte Regeln oder rechtliche Zwänge des Projekts abdecken. Achten Sie darauf, dass sie auch effektiv erklären können – das wird dem Entwicklungsteam helfen, Ihren Kontext und Ihre Anforderungen schneller zu verstehen. Typische Personen: Endbenutzer, Unternehmensberater, Technologie-/Fachexperten.
Entscheidungsträger: Jemand, der die notwendigen Schritte unternehmen kann, um die Dinge voranzubringen. Sie sind entweder Vertreter einer Gruppe von Personen (d.h. sie können Entscheidungen in ihrem Namen treffen) oder sie können den Entscheidungsprozess erleichtern und diese Entscheidung dem Team mitteilen. Typische Rolle: Produktmanager.
Autorität: Jemand mit der entsprechenden Position und Macht, an den Sie Fragen für eine schnellere Lösung eskalieren können. Typische Rollen: Abteilungsleiter, Sponsor. Es wäre großartig, Personen mit all diesen Eigenschaften zu finden. Aber in der Praxis geschieht dies nicht, so dass wir eine Gruppe von Interessensvertretern brauchen. Denken Sie daran, dass die besten Leute auch die fleißigsten sind, was es noch schwieriger macht, sie ins Boot zu holen.
Es wäre großartig, Personen mit all diesen Eigenschaften zu finden. Aber in der Praxis geschieht dies nicht, so dass wir eine Gruppe von Interessensvertretern brauchen. Denken Sie daran, dass die besten Leute auch die fleißigsten sind, was es noch schwieriger macht, sie ins Boot zu holen.
Wie kann man Stakeholder kontinuierlich einbinden?
- Zeigen Sie ihnen, woran Sie arbeiten.
- Besprechen Sie Kalkulationen und Prognosen.
- Finden Sie deren persönliches Interesse heraus und bedienen Sie es.
- Hinweis: Seien Sie sich bewusst, dass manche Stakeholder zur Belastung werden können.
Für die Stakeholder ist Ihr Projekt vielleicht nicht der Hauptschwerpunkt, sondern nur eine Nebenaktivität unter (vielen) anderen. Erschwerend kommt hinzu, dass Stakeholder über verschiedene Organisationen verteilt sein und sich Ihrem unmittelbaren Einfluss entziehen können.
Die Stakeholder erwarten normalerweise, dass sie nur in der Planungsphase einbezogen werden – was es für Sie umso wichtiger macht, sie so lange wie möglich am Projekt zu beteiligen. Hier sind einige Hinweise, wie Sie dies tun können:
Zeigen Sie ihnen häufig, was im Zuge des Projekts bereits gebaut wurde, damit diese sehen können, wie die Dinge sich entwickeln und das Interesse nicht verlieren. Außerdem hilft es Ihnen, sich auf das Wesentliche zu konzentrieren und nicht zu viel Arbeit in das Bauen falscher Features zu investieren.
Zeigen Sie ihnen den tatsächlichen Fortschritt; besprechen Sie Kalkulationen und Prognosen. Die schlechte Nachricht: Manchmal entspricht das tatsächliche Fortschrittstempo nicht dem, was der Kunde/die Stakeholder erwarten. Die gute Nachricht: Transparente Informationen, die bei Verfügbarkeit sofort geliefert werden, sind unbezahlbar. Durch das Besprechen der gelieferten Features im Vergleich zu den übrigen Features können Ihr Team und der Kunde auf der Grundlage solider Daten Kompromissentscheidungen treffen.
Fügen Sie „Goodies“ hinzu, um die Stakeholder einzubeziehen:
- Stellen Sie sicher, dass deren Beteiligung sichtbar ist und begleitet wird; betonen Sie gegenüber den Stakeholdern die Vorteile ihres Engagements.
- Schenken Sie den Stakeholdern Anerkennung für ihr Engagement und belohnen Sie sie dafür, indem Sie z.B. gemeinsam den Projekterfolg feiern.
- Sprechen Sie mit den Vorgesetzen der Stakeholder darüber, wie deren Beiträge am besten gewürdigt werden können, z.B. indem diese Beiträge in deren Leistungsbewertungen miteinbezogen werden.
Was passiert, wenn die Stakeholder nicht eingebunden werden:
Kluft der Auswertung
Wenn die Stakeholder nicht eingebunden werden, wird das Projekt wahrscheinlich der „Kluft der Auswertung“ zum Opfer fallen und aufgrund der Widersprüche zwischen dem,
- was der Kunde braucht,
- wie der Kunde beschreibt, was er braucht,
- wie das Entwicklungsteam diese Beschreibung versteht,
- was das Team tatsächlich umsetzt, schlussendlich nicht erfolgreich sein.
So entstehen viele Diskrepanzen. Wenn diese zu lange unbeachtet bleiben, führen sie zu kostspieligen Nachbesserungen oder sogar zum Scheitern des Projekts. Versuchen Sie daher, statt mehrerer unterschiedlicher Bilder Ihres Produkts ein einziges Bild zu erstellen, das von allen Beteiligten gemeinsam genutzt wird: „die gemeinsame Vision des Produkts“.
3. Eine gemeinsame Vision des Produkts schaffen
Praktische Beispiele für die Schaffung einer gemeinsamen Vision:
- Projektcharta
- Kurzpräsentation des Projekts
- Definition von „erledigt“
- Modellbildung mit Agile
- Wireframes
- Personas
Die Projektcharta (W5H)
ist eines der ersten Dokumente, die im Rahmen eines Projekts erstellt werden. Sie enthält die Zustimmung des Geldgebers fortzufahren, sowie wichtige Bausteine wie:
- Worum es bei diesem Projekt geht: eine Metabeschreibung der Vision, des Auftrags, der Ziele und Vorgaben des Projekts.
- Warum das Projekt durchgeführt wird: der Geschäftszweck des Projekts.
- Wer die Beteiligten sind: eine Liste der Projektteilnehmer und beteiligten Stakeholder.
- Wann das Projekt beginnen und enden wird: angestrebte Start-/Endzeitpunkte und Zeitplan für partielle Releases.
- Wo das Projekt stattfinden wird: Informationen über die verschiedenen Arbeitsorte (z.B. wo die gemeinsamen Treffen stattfinden), Anforderungen an die Bereitstellung usw.
- Wie das Projekt durchgeführt wird: eine Beschreibung des Ansatzes, der Methoden und des zu verwendenden Rahmens. Dies kann auch als Mitteilung an die Stakeholder dienen, um ihre verstärkte Beteiligung am Agile-Projekt einzufordern.
Bitte beachten Sie: Wenn wir davon ausgehen, dass der Umfang des Projektes nicht absolut festgelegt ist, und dass einige Projektteile zu Beginn sogar unbekannt sein könnten, dann besteht keine Notwendigkeit, den Umfang vollständig zu spezifizieren.
Die Kurzpräsentation des Projekts
ist die konzentrierteste, glanzvollste Beschreibung eines Projekts. Stellen Sie sich vor, Sie befinden sich in einem Aufzug mit jemandem, der Ihr Projekt unterstützen/finanzieren kann: Sie haben höchstens 20-30 Sekunden Zeit, um es zu beschreiben, also muss es kurz und überzeugend sein und beim Adressaten „hängen bleiben“.
Im Folfenden schlagen wir eine mögliche Struktur (anhand eines erfundenen Beispiels) vor:
- Für | Zielkunden | Diana Travis ist eine Marketingspezialistin bei InnerWorks, die…
- Wer | Bedarf / Gelegenheit / Problem | …kann nicht mit der Erstellung aller benötigten Berichte fertig werden.
- Das Produkt / die Dienstleistung | AntwortASAP ist…
- Die Kategorie | …ein Berichtsgenerator-Werkzeug, das…
- Hauptvorteile | …hilft, jede marktrelevante Frage fast sofort zu beantworten.
- Im Gegensatz zu / konkurrierende Alternativen | Die Erstellung eines Berichts dauert jetzt 30 Minuten…
- Wir / Differentiator | …aber wir können den Bericht in 4 Minuten erstellen.
Definition von „erledigt“:
Erstaunlicherweise kann „erledigt“ für verschiedene Menschen unterschiedliche Dinge bedeuten. Wenn man eine Liste mit allem hat, was erledigt werden muss, werden alle Beteiligten dasselbe Verständnis haben:
- Codiert: Ist der gesamte Code geschrieben worden?
- Gestaltet: Entspricht die Gestaltung des Codes den vereinbarten technischen Standards?
- Getestet: Sind alle Tests abgeschlossen?
- Integriert: Funktioniert das Feature von Anfang bis Ende?
- Installiert: Wird die Anwendung auf den erwarteten Servern installiert?
- Überprüft: Haben Kunden das Feature überprüft und bestätigt, dass es ihren Erwartungen entspricht?
- Genehmigt: Haben die Kunden diese Funktionalität genehmigt?
- Repariert?
- Migriert?
- Vorschriftsgemäß?
Ohne eine gemeinsame Definition riskieren Sie häufige Diskrepanzen.
Das Entwicklungsteam konzentriert sich beispielsweise in der Regel auf die ersten Themen (Design, Codierung und Testen) und will sie erledigen, bevor es zur nächsten Sache übergeht. In einer separaten Darstellung betrachtet der Kunde einen anderen Satz von Kriterien, wie z.B. Integration, Genehmigung oder Konformität. Wie zu erwarten ist, wird das Zusammenfügen der beiden Kriterienkataloge ohne vorherige Abstimmung und gemeinsames Verständnis definitiv zu Problemen führen.
Agile Modellierung
kann mit Use-Case-Diagrammen, Datenmodellen und Screendesigns durchgeführt werden:
- Die Use-Case-Diagramme beziehen sich in der Regel auf Akteure und Handlungen (z.B. die Endnutzer und die Prozesse hinter ihren Handlungen).
- Datenmodelle beziehen sich auf Datenentitäten und ihre Verknüpfung untereinander.
- Screendesigns zeigen, wie das Produkt auf einer Webseite, einem Desktop oder einem mobilen Gerät aussehen soll.
Wireframes
sind vor allem bei der Erstellung von Mock-ups eines Produkts nützlich. Es handelt sich dabei um eine Reihe von Screendesigns, die einen Prototyp eines bestimmten Teils des Produkts oder eines bestimmten Arbeitsablaufs mit einem Minimum an benötigter Funktionalität darstellen (z.B. nur das Verschieben von einer Seite auf eine andere). Wireframes sind zu Beginn sehr nützlich, da sie eine schnelle und kostengünstige Möglichkeit darstellen, um Feedback zu einer vorgeschlagenen Funktionalität zu erhalten.
Personas
sind Kurzanleitungen und Erinnerungen an die Endbenutzer und ihre Anwendungsfälle. Sie sind ein weiteres Werkzeug für das Entwicklungsteam, um seine Arbeit zu priorisieren und sich auf das Wesentliche zu konzentrieren. Personas ersetzen die Anforderungen nicht, sondern erweitern sie vielmehr.
- Stellen Sie eine Beschreibung eines repräsentativen Benutzers zur Verfügung
- Verklieren Sie nicht den Zugang zur Realität
- Seien Sie zielorientiert und spezifisch
- Seien Sie fokussiert
4. Stakeholder-Kommunikation
Wenn die Erarbeitung einer gemeinsamen Vision der erste Schritt zur Vermeidung der „Kluft der Auswertung“ ist, dann ist der zweite Schritt die richtige Kommunikation mit den Beteiligten. Im Zusammenhang mit dem agilen Stakeholder-Engagement sind folgende Möglichkeiten zielführend:
- Persönliche Kommunikation
- Wissensaustausch
Die persönliche Kommunikation
kann entweder in einem Dispatching-Modell oder in einem Kooperationsmodell erfolgen.
Das Dispatching-Modell folgt normalerweise der hierarchischen Struktur einer Organisation, die von oben nach unten verläuft, vom Produktmanager zum Teamleiter und dann zu denjenigen, die die Arbeit tatsächlich ausführen: den Teammitgliedern. Dieser Befehls- und Steuerungsansatz mag für denjenigen, der den Arbeitsauftrag erteilt, einfacher sein, aber er ist in Softwareprojekten nicht effektiv.
Der kollaborative Weg (d.h. Zwei-Wege-Kommunikation) baut auf direkten Mitteilungen auf, gefolgt von Feedback und Validierung, wie z.B:
- Entwicklungsteam zum Kunden: „Hier ist das, was Sie unserer Meinung nach gefordert haben, und hier ist, was wir aufgebaut haben. Bitte bestätigen Sie uns, dass wir auf dem richtigen Weg sind“.
- Kunde an Entwicklungsteam: „Mir gefallen diese beiden Teile, aber Sie haben den dritten falsch verstanden. Oh, und das erinnert mich daran, dass wir etwas brauchen, für das wir eine neue Anfrage stellen müssen.“
Aus offensichtlichen Gründen ist der kollaborative Weg der effektivste und wird daher bei agilen Software-Projekten bevorzugt.
Wissensaustausch
Informationssender sind gut sichtbare Informationsanzeigen, wie z.B. große Diagramme, einfache Grafiken und Zusammenfassungen von Projektdaten. Die Informationen sollten in stark frequentierten Bürobereichen oder online in einfachen und schnellen Wiki-Seiten angezeigt werden. Dies steht im Gegensatz zu Informationsspeichern, in denen Projektinformationen in komplizierten Dokumenten, Berichten und KPI-Blättern aufbewahrt werden – was bedeutet, dass niemand weiß, was vor sich geht.
- Bidirektionale Informationsflüsse sind entscheidend.
- Von den Stakeholdern zum Entwicklungsteam: die gemeinsame Vision über das Projekt und die Ergebnisse.
- Vom Entwicklungsteam zu den Stakeholdern:
- Feature-Map
- Wer arbeitet woran (Kanban-Tafel)
- die aus der aktuellen Iteration ausgewählten Merkmale
- Geschwindigkeitsdiagramm
- Defektmetriken
- Liste der Risiken und Probleme
- Burn-Down-Diagramme
Die Feature-Map (auch Story-Mapping genannt) ist eine Möglichkeit, die Features so anzuordnen, dass eine bessere Übersicht darüber entsteht, wie sie sich in der gesamten Benutzererfahrung verhalten.
In diesem Beispiel einer Map mit den Features eines Webstores enthält die erste Zeile die grundlegenden Schritte dieser Reise , die das „Rückgrat“ der Map bilden.
Die rote Linie zeigt die Benutzerreise (wie der Benutzer das Produkt benutzen wird).
Die einzelnen Features werden entlang der Hauptphasen der Reise verteilt, mit schrittweisen Releases (R1, R2, R3).
Unten sehen Sie den Nachholbedarf, um die Features ohne klares Veröffentlichungsdatum einzubeziehen.
Die Vorteile einer Feature-Map:
- Sie zeigt das Gesamtbild der Nutzung des Produkts;
- Ist ein ausgezeichnetes Werkzeug zur Visualisierung der Prioritäten und des Zeitplans für die Freigabe von Funktionen.
Die Kanban-Tafel erhielt ihren Namen vom japanischen Wort „Kanban“, was wörtlich übersetzt „eine Tafel mit Zeichen darauf“ bedeutet.
Die Spalten zeigen die Phasen eines Prozesses, während die einzelnen Karten Arbeitsaufträge/Aufgaben darstellen. Der Fortschritt wird visualisiert, indem die Karten von links nach rechts verschoben werden, was die Teamkoordination vereinfacht. Bei Bedarf kann die Tafel weiter in separate Zeilen aufgeteilt werden, um verschiedene Arbeitsbereiche oder verschiedene Teams anzuzeigen.
Sie können die verbleibenden Tage für bestimmte Aufgaben zählen, um Rückstände zu erkennen und mögliche Probleme hervorzuheben.
Kanban-Tafeln sind in verschiedenen Softwarepaketen enthalten – aber eine physische weiße Tafel, auf die Sie zeichnen und Notizen kleben können, lässt Sie besser vorausplanen und die Aufgaben strets vor Augen haben.
Auch wenn die Stakeholder hier nicht die eigentliche Arbeit verrichten, ist es für sie dennoch nützlich, durch das Kanban zu sehen, wie sich die Dinge entwickeln. Wenn sie zum Beispiel die Implementierung bestimmter Funktionen verfolgen wollen, zeigt das Brett an, wer daran arbeitet.
Das Geschwindigkeitsdiagramm zeigt die Geschichte der abgeschlossenen Projekte im Vergleich zur geschätzen Dauer.
Idealerweise sollte der graue Balken mit dem grünen Balken übereinstimmen. In der Praxis wird das in der Regel nicht der Fall sein – und wenn es keine größeren Probleme gibt, ist das auch in Ordnung.
Ein Szenario ist, dass der graue Balken ständig vor dem grünen Balken liegt (d.h. geschätzt > abgeschlossen): Das bedeutet, dass das Team seine Kapazität überschätzt, d.h. es glaubt, dass es mehr tun kann, als es tatsächlich tut.
Umgekehrt, wenn der graue Balken ständig unter dem grünen Balken liegt (d.h. geschätzt < abgeschlossen), unterschätzt das Entwicklungsteam seine Kapazität, möglicherweise weil es nicht zu viel versprechen will.
Wie dem auch sei, dies ist eine wertvolle Information bei der Planung: Sie hilft bei der Einschätzung/Entscheidung, wie viel Arbeit in einem bestimmten Zeitrahmen zu leisten ist.
Das Burn-Down-Diagramm ist ein weiteres Hilfsmittel, um den Fortschritt Ihrer aktuellen Iteration zu visualisieren und schnell zu verstehen, ob ein Team im Zeitplan ist oder nicht.
5. Kollaboratives Arbeiten
Wenn Sie die gemeinsame Vision einmal festgelegt und kommuniziert haben, können Sie sie auf gemeinschaftliche Art und Weise aufbauen durch:
- Workshops und Brainstorming-Sitzungen
- Spiele zur Zusammenarbeit
- Spiele zur Entscheidungsfindung
Wissensaustausch
kann man auf zweierlei Arten durchführen: über Workshops und bei Brainstormings. Die Workshops sind am effektivsten, wenn ein paar einfache Regeln befolgt werden:
- Beginnen Sie mit einer Kick-off-Aktivität, die alle Beteiligten innerhalb der ersten 5 Minuten anspricht (z.B. die Teilnehmenden sollen sich selbst und/oder ihre Erwartungen vorstellen).
- Legen Sie ein klares Ziel fest, mit einem Zeitplan und Regeln, die für alle sichtbar sind.
- Fördern Sie die Vielfalt: Indem Sie eine vielfältige Gruppe von Personen statt nur einige wenige Experten einbeziehen, werden Sie von einer breiteren Palette von Optionen, neuen Ideen und Lösungen profitieren.
Beziehen Sie alle Teilnehmer ein: Beiträge werden von allen erwartet und gefördert. Verhindern Sie, dass dominante Einzelpersonen und Extrovertierte die Diskussion monopolisieren. Hier einige praktische Hinweise zur Durchführung der Diskussion:
- Nehmen Sie sich Zeit zum stillen Schreiben: Reservieren Sie 5 bis 10 Minuten, um eine Liste individueller Ideen zu erstellen, um den Einfluss stärkerer Einzelpersonen in der Gruppe zu minimieren.
- Ringversuch: Reichen Sie einen Spielstein in der Gruppe herum; nur der Spielsteinhalter spricht, so dass die Ideen aufeinander aufbauen können.
- Free for All (d.h. Menschen, die ihre Ideen spontan aussprechen), funktioniert nur in einer unterstützenden Umgebung, in der die Menschen miteinander vertraut sind und sich wohl fühlen, wenn sie ihre Meinung sagen.
Spiele zur Zusammenarbeit:
- den Produktbaum formen
- das Segelboot
Die Gestaltung des Produktbaums (/ progressive Ausarbeitung)beginnt mit der Zeichnung eines Baumes auf einem Whiteboard. Nein, der Baum muss nicht schön sein, auch wenn er für das Produkt steht:
- Der Stamm und die Hauptzweige repräsentieren das, was wir am Anfang wissen, d.h. die Hauptideen darüber, was das Produkt tun soll.
- Die äußeren Zweige zeigen neue oder verfeinerte Funktionalitäten, die noch zu entwerfen und zu implementieren sind.
Bitten Sie die Teilnehmer, die gewünschten Produktmerkmale auf individuellen Post-its festzuhalten, die auf dem Baum platziert werden sollen. Wie wir die Post-its platzieren, ist sehr wichtig:
- die verwandten Features sollten auf demselben Zweig gruppiert werden;
- die unterstützenden Features müssen näher am Stamm platziert werden als die unterstützten Features.
Wenn man sieht, wie die Features zueinander in Beziehung stehen, ist es einfacher, den Prozess der Prioritätensetzung und der Definition von Entwicklungssequenzen zu verstehen. Genau deshalb ist die progressive Ausarbeitung ein Schlüsselkonzept in agilen Projekten.
Achten Sie darauf, diesen Baum regelmäßig zu überprüfen: einige neue Äste oder neue Blätter könnten hinzugefügt werden, während andere entfernt werden könnten.
Das Segelboot ist eine weitere Whiteboard-Zeichnung. Sie muss auch nicht unbedingt schön sein, solange sie vier Hauptschwerpunkte in Bezug auf Ihr Produkt enthält:
- Wo Sie hin wollen: „das Ziel“, z.B. die Funktionen, die für die kommende Version benötigt werden.
- Was kann Sie dorthin bringen: Fakten und Maßnahmen, die beim Aufbau des Projekts helfen (z.B. „Hilfe für das Team“; direkter Zugang des Entwicklungsteams zu einem wichtigen Stakeholder; klares Feedback von einem Endbenutzer usw.)
- Was Sie verlangsamt: „Verzögerungsgründe“ (z.B. die Staging-Server verlangsamen die automatisierten Tests; aus Ihrem letzten Review-Meeting kamen keine klaren Schlussfolgerungen und es muss wiederholt werden usw.)
- Die Risiken: alles, was das Produkt/Projekt stören könnte (z.B. Mutterschaftsurlaub, der früher als erwartet beginnt; ein wichtiges Feature, das nicht ausreichend beschrieben ist usw.)
Das Segelboot beschleunigt Ihre Suche nach Chancen und Risiken, nach positiven und negativen Tatsachen, die sich auf Ihr Projekt auswirken. Es hilft Ihrem Team auch dabei, Bedenken zu äußern und offene Fragen zu klären – solange das Team bereit ist, die Probleme anzugehen.
Entscheidungsspiele / Partizipative Entscheidungsfindung
Es ist sehr selten (und nicht realistisch zu erwarten), dass eine Gruppe von Menschen bei allen Diskussionen und Entscheidungen völlige Übereinstimmung erzielt. Deshalb brauchen wir eine Möglichkeit, harte Entscheidungen zu treffen und gleichzeitig alle motiviert und engagiert in das Projekt einzubinden.
Hier ist, was wir regelmäßig anwenden:
Einfache Ja/Nein-Abstimmung: Sie ist schnell, aber manchmal ist eine weitere Verfeinerung des Ergebnisses erforderlich.
Daumen hoch/runter/seitwärts: ebenso schnell, mit einer zusätzlichen Chance, andere Optionen auszuloten. Wenn man die „Seitwärts-Daumen“-Abstimmenden nach ihren Bedenken befragt, kann man bisher nicht gesehene Problemfelder aufdecken, die es wert sind, untersucht zu werden.
Fünfer-Faust: auch schnell, visualisiert den Grad der Zustimmung der Menschen.
Entscheidungsspektrum: Jeder gibt ein Spektrum an, das von „Dafür“ bis „Veto“ reicht. Es ist langsamer als alle vorherigen Optionen, aber es erlaubt den Menschen, über ihre Bedenken zu sprechen. Neben der Entscheidungsfindung erhalten Sie auch ein gutes Bild davon, was Ihre Leute darüber denken.
＿
Wie eingangs angedeutet, gleicht das agile Stakeholder-Engagement Einfachheit und Effektivität aus. Solange Sie ergebnisorientiert denken und die Grundlagen richtig verstehen (eine gemeinsame Vision entwickeln, regelmäßig kommunizieren und zusammenarbeiten), werden Ihre Stakeholder einen wichtigen Beitrag für den Erfolg Ihres Projekts leisten.
＿
Wie gehen Sie an das Thema Stakeholder-Engagement heran? Gibt es Erfahrungen, die Sie teilen möchten? Lassen Sie es uns wissen!