Agile 4 - Agile anwenden
Google Project Management Certificate · Kurs 5: Agiles Projektmanagement
Am Ende von Modul 3 konnte das Team Scrum im Alltag betreiben: ein Backlog aus User Stories, Schätzungen, die fünf Events, Velocity und Burndown-Charts. Das ist die Maschinerie. Dieses letzte Modul tritt einen Schritt von der Maschinerie zurück und fragt, wofür das alles eigentlich da ist und was passiert, wenn man sie in einer echten Organisation einsetzt, mit echten Menschen, wechselnden Plänen und einem Arbeitsmarkt, durch den man hindurch muss.
Der rote Faden ist Wert. Zuerst geht es darum, wie ein Team seine Aufmerksamkeit auf Wert statt auf Output richtet, und um die Roadmap-Artefakte, die das möglich machen. Dann kommt der unordentliche Teil: einen Plan ändern, ohne die Kontrolle darüber zu verlieren, Agile in eine Organisation einführen, die es vielleicht gar nicht will, ein Team durch die Veränderung coachen und die Warnzeichen erkennen, wenn etwas schiefläuft.
Das Modul schließt mit dem größeren Blick: wie sich Agile seit 2001 verbreitet und weiterentwickelt hat, welche Frameworks es über ein einzelnes Team hinaus strecken, und praktische Ratschläge für Vorstellungsgespräche für eine agile Rolle oder dafür, Agile in das eigene aktuelle Team zu bringen.
Wertorientierte Lieferung
Abschnitt betitelt „Wertorientierte Lieferung“Wert ist das, was das Endprodukt den Nutzenden tatsächlich gibt, und er unterscheidet sich von Kunde zu Kunde, je nachdem, was sie vom Produkt erwarten. Der Kurs nennt drei Beispiele: finanziellen Nutzen, Nutzerwachstum und Engagement sowie die Einhaltung von Compliance-Vorgaben.
Wertorientierte Lieferung heißt, dass die Aufmerksamkeit des Teams darauf liegt, ein Produkt mit hohem Wert herzustellen. Etwas auszuliefern ist nicht dasselbe, wie etwas Wertvolles auszuliefern. Genau das ist das ursprüngliche Problem, auf das Agile antwortete: Teams waren so von Prozessen eingenommen, dass niemand die Nützlichkeit beurteilte, bevor das Produkt schon übergeben war. Agile dreht den Fokus um, sodass das Produkt an erster Stelle steht und der Prozess dazu da ist, ihm zu dienen. Das führt direkt zurück zum ersten agilen Prinzip, die Kundschaft durch wertvolle Lieferung zufriedenzustellen (außerhalb der Tech-Welt ersetzt man Software durch Produkt oder Lösung).
Drei Schritte, um Wert zu liefern
Abschnitt betitelt „Drei Schritte, um Wert zu liefern“Die Begriffe bauen und betreiben stammen aus der Software, und für andere Projekte kann man sie als erstellen, herstellen oder liefern lesen.
| Schritt | Was er bedeutet | Beispiel Virtual Verde |
|---|---|---|
| Das Richtige bauen | Über die geäußerte Anfrage hinaus zum Ziel dahinter gehen. Eine Kundin, die nach einer Website fragt, will vielleicht eigentlich Markenbekanntheit oder mehr Kundschaft, also ein lösungsorientiertes Gespräch führen. Der Wert Individuen und Interaktionen vor Prozessen und Werkzeugen erreicht Kundschaft und Nutzende ebenso wie das Team | Aktuelle und potenzielle Kundschaft zu Pflanzenvorlieben und Homeoffice-Stilen befragen und dann die User Stories im Product Backlog aktualisieren |
| Die Sache richtig bauen | Bei angefragten oder genehmigten Features bleiben. Extras fügen Komplexität ohne Nutzerwert hinzu, verzögern oder schmälern den Wert bei der Lieferung und erhöhen das Risiko späterer Bugs | Einen vertrauenswürdigen Lieferanten für die richtigen Pflanzen sichern, mit Designern an Töpfen und Vasen in den bevorzugten Stilen arbeiten und das Marketing dazu bringen, sie auf der Website und im Katalog zu präsentieren |
| Sie richtig betreiben | Durchdenken, wie Nutzende nach der Lieferung mit dem Produkt umgehen: wie sie Support bekommen, wie das Produkt weiter Wert stiftet, wie neue Features bestehende Nutzende erreichen | Nachgelagerte Zufriedenheitsumfragen zu Angebot, Lieferzeiten und Pflanzenqualität, die in Lieferanten- und Marketingentscheidungen einfließen, dazu Extras wie Gießkannen, automatische Pflanzengesundheitssysteme oder kostenlose monatliche Gartentipps |
Eine Fallstudie lesen
Abschnitt betitelt „Eine Fallstudie lesen“Das Modul gibt eine Fallstudie zu Penta auf, einem Softwareunternehmen für die Baubranche, das eine agile Taskforce gründete, um Probleme mit Scrum Teams zu lösen. Die Fallstudie selbst liegt hinter einem Link und ist nicht in meiner Quelle, was ich habe, ist also die Lesemethode. Eine Fallstudie ist eine tiefgehende, datengestützte Analyse eines Unternehmens, einer Gemeinschaft oder einer Organisation, und es lohnt sich, sie auf das Problem, seine Wirkung auf die Organisation und die Vor- und Nachteile der Lösung hin zu lesen. Fragen, die man sich beim Lesen stellt:
- Worum geht es, und was ist das Ziel der Analyse?
- In welchem Kontext steht das Problem, und welche zentralen Fakten zählen?
- Welche Alternativen hat die Entscheiderin oder der Entscheider?
- Was würde ich empfehlen, und warum?
Speziell zu Penta lautete der Auftrag, darauf zu achten, wie wichtig die Rollen waren und wie Menschen aus der ganzen Organisation zusammenkamen, um Ideen zu entwickeln, zu testen und zu analysieren.
Ein Technical Program Manager über Flexibilität
Abschnitt betitelt „Ein Technical Program Manager über Flexibilität“Camron, ein Technical Program Manager bei Google (ein Program Manager mit genug technischem Hintergrund, um an technischen Gesprächen und Entscheidungen teilzunehmen), schätzt an Agile vor allem die Flexibilität. Die meisten Entscheidungen triffst du am Anfang, wenn du am wenigsten weißt, also werden einige falsch sein, und Agile baut Gelegenheiten ein, sie zu ändern, während du dazulernst.
Sein Kontrast zu Waterfall betrifft den Zeitpunkt, an dem Wert ankommt. Waterfall übergibt alles am Ende, also wartet die Kundschaft Tage, Monate oder Jahre, bevor sie irgendetwas davon hat. Das passt zu einem Haus oder einem Auto, wo ein Teilprodukt nutzlos oder unsicher ist. Bei Arbeit mit einem harten Schlussproblem heißt Agile, dass man nicht das ganze Projekt für das letzte Stück zurückhält: die 90 Prozent ausliefern, die funktionieren, die Leute sie nutzen lassen und die letzten 10 Prozent später veröffentlichen.
Die Value Roadmap
Abschnitt betitelt „Die Value Roadmap“Eine Value Roadmap ist eine agile Art, Zeitplan und Anforderungen der Produktentwicklung darzustellen, und sie ist in jeder Art von Unternehmen nutzbar. Sie dient als Wegweiser dafür, wohin du willst, wie du dorthin kommst und was du unterwegs erreichst, um den Wert zu maximieren. Während das Team ihr folgt, sammelt sie Input von Kundschaft und Stakeholdern und speist ihn in jede Iteration ein. Außerdem hilft sie, die Product Vision zu erklären und zentrale Meilensteine herauszustellen.
Ein Projekt hat meist mehrere Releases, bevor es als fertig gilt, und nur das erste Release-Datum sollte als fest behandelt werden. Alles danach beruht auf frühen Schätzungen und wird sich verschieben.
Ein Release Plan enthält:
- Ein Release-Ziel, das übergeordnete Geschäftsziel für die Features in diesem Release.
- Die für dieses Ziel nötigen Backlog-Einträge, etwa Epics, User Stories oder Features.
- Ein geschätztes Release-Datum.
- Alle weiteren Daten, die das Release beeinflussen, etwa eine Messe oder ein großer Feiertag.
Alle Release Plans gehören auf die Value Roadmap. Und das Ganze funktioniert nur, wenn das Team kooperativ ist und die Stakeholder regelmäßig mit ihm zusammenarbeiten.
Arten von Roadmaps, Vorteile und Fallstricke
Abschnitt betitelt „Arten von Roadmaps, Vorteile und Fallstricke“Unternehmen interpretieren Roadmaps unterschiedlich, daher begegnen dir Projekt-, Produkt-, Value-, Lean- und Agile-Roadmaps. Sie sind meist visuell, oft auf eine Seite gedrängt (etwa Balken über vier Quartale), damit Prüfende die ganze Zeitachse auf einen Blick sehen.
- Macht die Reihenfolge der Deliverables klar
- Zeigt Teams, wie ihr Einsatz mit der Nordstern-Vision zusammenhängt
- Zeigt Stakeholdern, dass Wert inkrementell ankommt und nicht als eine einzige Lieferung am Ende
- Gibt Stakeholdern ein grobes Bild der Arbeit hinter einem Deliverable
- Stakeholder sie als fest behandeln lassen, sodass sie Anpassung blockieren und Deadlines um jeden Preis durchdrücken
- Lieferdaten polieren, statt sie grob zu halten und zu schärfen, wenn sie näher rücken
- Mühe in die Roadmap stecken statt in die Deliverables
Best Practices: Halte sie gut sichtbar und beziehe dich oft auf sie, markiere die Einträge mit höchster Priorität und, wo möglich, die mit höchstem Wert, teile sie mit dem breiteren Stakeholder-Kreis für dessen eigene Planung und überprüfe sie regelmäßig mit Sponsoren, Stakeholdern und dem Team, um sicherzustellen, dass sie noch als Bauplan des Projekts taugt.
Tipps für eine wirksame Value Roadmap
Abschnitt betitelt „Tipps für eine wirksame Value Roadmap“-
Release-Daten auf der Product Roadmap grob halten. Sie liegen womöglich Monate oder Jahre in der Zukunft, und eine zu genaue Roadmap programmiert das Scheitern des Teams an Daten vor, die niemand garantieren kann.
-
Jeden Release Plan gemeinsam erstellen. Der Product Owner und der Projektmanager oder Scrum Master müssen die Roadmap mit der Kapazität und Velocity des Teams verbinden. Ein Plan, der ignoriert, was das Team tatsächlich leisten kann, ist unrealistisch und verletzt das Prinzip des nachhaltigen Tempos.
-
Harte Deadlines einplanen und kommunizieren. Für Virtual Verde ist eine Deko-Messe von Office Green im Oktober ein festes Launch-Datum für die erste Phase. Stimme die unverzichtbaren Features mit den Stakeholdern ab, damit das Team weiß, worauf es sich konzentrieren muss, falls das Datum in Gefahr gerät.
-
Den Release Plan als lebendes Artefakt behandeln. Einen zu haben widerspricht nicht dem Wert Reagieren auf Veränderung vor dem Befolgen eines Plans. Er ändert sich, wenn sich die Velocity des Teams ändert (Menschen kommen hinzu oder gehen, oder es gibt Effizienzgewinne), wenn der Product Owner eine Scope-Änderung genehmigt oder wenn das Team merkt, dass eine Story oder ein Epic schwerer oder leichter ist als gedacht.
-
Den Release Plan vor jedem Sprint Planning überprüfen. Der Scrum Master oder PM prüft, ob das Team auf Kurs ist. Wenn nicht, führen sie ein offenes Gespräch mit dem Product Owner und den Fachleuten aus dem Business darüber, was angepasst werden soll, und genau hier zählt Transparenz.
Reagieren auf Veränderung vor dem Befolgen eines Plans
Abschnitt betitelt „Reagieren auf Veränderung vor dem Befolgen eines Plans“Modul 1 hat das als einen der vier Werte eingeführt. Die Lektüre macht daraus ein Verfahren, um einen Release Plan zu ändern, in drei Stufen.
Stufe 1: eine nötige Änderung erkennen
Abschnitt betitelt „Stufe 1: eine nötige Änderung erkennen“Das magische Dreieck (Triple Constraint) aus früheren Kursen dient hier als Linse, in Agile genauso wie in traditionellen Projekten. Jede Person kann eine nötige Änderung erkennen: Product Owner, Projektmanager, Scrum Master oder das Development Team.
| Rahmenbedingung | In einem agilen Projekt umfasst sie | Beispielhafter Auslöser |
|---|---|---|
| Scope (das Was) | Inhalte der Product Roadmap, Product-Backlog-Einträge, geplante Deliverables, vorgesehene Nutzende oder Kundschaft | Kundenfeedback zu frühen Prototypen fügt einige Features hinzu und streicht andere |
| Zeit (das Wann) | Zeitachse der Roadmap, Release-Zeitplan, sogar die Sprint-Länge | Kritische Abhängigkeiten oder Liefertermine verschieben sich und erzwingen eine Änderung der Roadmap |
| Kosten oder Ressourcen (das Wie) | Zusammensetzung des Development Teams, PMs, Product Owner, weitere Fachleute aus dem Business, Ausstattung | Eine Sprint Retrospective deckt Unterbesetzung auf |
Stufe 2: entscheiden, die Änderung umzusetzen
Abschnitt betitelt „Stufe 2: entscheiden, die Änderung umzusetzen“Die meisten Entscheidungsmodelle teilen dieselben Grundschritte:
- Eine einzelne entscheidende Person benennen, meist den Product Owner oder einen hochrangigen Stakeholder, für Konsistenz und Verantwortlichkeit.
- Vereinbaren und teilen, welche Faktoren zählen, und die Daten sammeln, die die Entscheidung stützen.
- Nutzen und Kosten offen besprechen, Unsicherheiten benennen und Annahmen festhalten.
- Die Entscheidung dokumentieren.
Stufe 3: die Änderung umsetzen
Abschnitt betitelt „Stufe 3: die Änderung umsetzen“- Die Änderung und das Zustandekommen der Entscheidung dokumentieren: Besprechungsnotizen, Vor- und Nachteile, Annahmen, Daten.
- Jedes betroffene Artefakt aktualisieren (Roadmaps, Backlogs, Personalpläne, Integrationstermine) mit einem Verweis auf die Quelle der Änderung und einer Revisionskennzeichnung wie Version 1.2 oder einem Aktualisiert-am-Datum.
- Alle betroffenen Stakeholder informieren, über Meetings, Dokumentation und Notizen oder Ankündigungen per E-Mail.
- Die Änderung eine Weile beobachten, damit du weißt, dass das Team sie kennt und mitträgt.
Wird die Änderung abgelehnt, halte die Informationen und Begründungen trotzdem fest. Du kannst eine Änderung auch zurückstellen, bis mehr Informationen eine sicherere Entscheidung erlauben.
Aktivität: E-Mails zum Release Plan von Virtual Verde
Abschnitt betitelt „Aktivität: E-Mails zum Release Plan von Virtual Verde“Die Aktivität setzt mich auf den Platz des Scrum Masters, der drei E-Mails von Kolleginnen und Kollegen bei Office Green erhält. Für jede fragt die Vorlage drei Dinge: Erfordert das Update eine Handlung und welche Optionen gibt es, muss jemand konsultiert werden, und werden mehr Informationen gebraucht. Ist eine Änderung des Release Plans gerechtfertigt, entwerfe ich anschließend eine E-Mail an das Scrum Team (An, Von, Betreff, Text, Grußformel).
| Urteil der Musterlösung | Optionen, Personen und Informationen | |
|---|---|---|
| 25. März, Content-Managerin: saisonale Pflege-E-Mails für Juni früher fertig, Inhalte für Juli bis November in Arbeit | Keine Handlung. Die ersten saisonalen E-Mails gehen erst im Juni raus, der Release Plan bleibt also bestehen | Nichts nötig |
| 10. April, Lieferantenmanager: Die in einem früheren Sprint gebaute Lieferantendatenbank zeigt Bestände, die nicht zum Lager passen, und verliert Rechnungen | Jetzt handeln, aber keine größeren Auswirkungen auf das Release erwartet. Dem Team mailen und die Developer bitten, mit der IT zusammenzuarbeiten, verbunden mit dem Hinweis auf ein paar Tage Störung | Optionen: Die IT behebt es schnell, Rückkehr zur alten Software oder manuelle Nachverfolgung. Den Lieferantenmanager, die Developer und die IT sowie die Leitung des Lagerbetriebs konsultieren. Herausfinden, wie lange die Behebung dauert und wie viele Rechnungen fehlen |
| 9. Juni, Lieferantenmanager: Der Bonsai-Lieferant führt ab Monatsende keine Bonsai mehr, Wochen vor dem Juli-Release, in dem sie im Mittelpunkt stehen | Eine wahrscheinliche Änderung an Release 3. Dem Team mit den Optionen mailen, mit Zweifeln, ob rechtzeitig und im Budget ein neuer Lieferant zu finden ist, und mit dem Vorschlag, im Juli mit Gemüse und Gartenbedarf zu starten und Bonsai in einem späteren Release nachzuliefern | Optionen: einen anderen Bonsai-Lieferanten finden, eine Spezialpflanze als Ersatz nehmen oder ohne Bonsai starten. Den Product Owner (entscheidet final), den Lieferantenmanager und das Development Team konsultieren. Nach anderen Lieferanten, deren Kosten und Tempo, den Ersatzpflanzen und den nötigen Website-Änderungen fragen |
Die Lektion steckt im Kontrast: Nicht jedes Update ist eine Änderung, bei einer Scope-Änderung entscheidet der Product Owner, und die E-Mail an das Team legt Optionen vor einer Entscheidung dar, statt eine zu verkünden.
Agile in eine Organisation bringen
Abschnitt betitelt „Agile in eine Organisation bringen“Arbeitgeber sind entweder schon agil, mitten im Umstieg oder nicht agil, aber bereit dafür. Eine Einsteigerin im Projektmanagement wird kaum eine vollständige Transformation in einem großen Unternehmen leiten, sie aber gut unterstützen können, während ein kleineres Unternehmen dich womöglich genau dafür einstellt, sie zu leiten.
Zwei Gedanken wandern aus dem früheren Kurs zu Kultur und Veränderung herüber. Organisationskultur entsteht aus gemeinsamen Werten am Arbeitsplatz und zeigt sich in Verhalten, Aktivitäten, Kommunikation und darin, wie Menschen zusammenarbeiten. Eine Veränderung, die nicht zu dieser Kultur passt, ist viel schwerer, und Forschung zeigt, dass Unternehmen, die die kulturelle Seite von Agile ignorieren, eher scheitern. Veränderungsmanagement ist der Prozess, Menschen dazu zu bringen, etwas Neues anzunehmen, und bei Agile ist das ein ganzes Wertesystem. Sofern die Organisation nicht schon Jahre mit Agile hinter sich hat, rechne mit einem Kulturwandel, der Jahre dauern kann.
Ownership und Dringlichkeit
Abschnitt betitelt „Ownership und Dringlichkeit“Ein Gefühl von Ownership und Dringlichkeit steigert Interesse, Motivation und Engagement für das Ergebnis.
| Hebel | Wie man ihn erzeugt |
|---|---|
| Ownership | Einen Executive Sponsor finden, der die Veränderung ebenfalls als seine Sache empfindet. Die Veränderung an die erklärte Mission oder die Werte des Unternehmens knüpfen. Rückhalt an der Spitze verbessert die Chancen, und idealerweise wirbt der Sponsor für die Vorteile von Agile und stellt Unterstützung und Ressourcen bereit |
| Dringlichkeit | Team, Organisation und Stakeholder fragen, was funktioniert und was nicht, und jede Änderung mit diesen Antworten verknüpfen. Zum Beispiel: Was hindert uns daran, der Kundschaft das beste Produkt zu geben, was lässt die Konkurrenz uns in diesem Markt schlagen, wie können unsere Teams produktiver und besser unterstützt sein |
Die Fragen zur Dringlichkeit erfüllen einen doppelten Zweck: Sie helfen beim Priorisieren, und du kannst sie wiederverwenden, um während der Veränderung Feedback einzuholen und schrittweise Verbesserung zu zeigen, was dem Geist von Agile entspricht. Virtual Verde hatte beides. Die Dringlichkeit kam daher, dass die Homeoffice-Dekoration zu einem heißen Online-Trend wurde, den der CEO mitnehmen wollte, und die Ownership kam von einem Team, das im Projekt Plant Pals Erfahrung gesammelt hatte und motiviert war, einen neuen Ansatz auszuprobieren.
Das Influencer-Change-Framework
Abschnitt betitelt „Das Influencer-Change-Framework“Dieses Framework, das Influencer-Change-Framework (Veränderungsmodell nach Influencer), stammt aus dem Buch Influencer: The New Science of Leading Change von Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan und Al Switzler. Kurs 4 hat Einfluss ohne Weisungsbefugnis bereits allgemein behandelt (Notizen zur Führung); neu ist hier ein strukturiertes Modell, um Verhalten in einem Team oder einer Organisation zu verändern.
Ein Influencer zu sein heißt hier, Menschen dazu zu führen, ihr Verhalten, ihre Herzen und ihre Köpfe für bedeutsame, dauerhafte Ergebnisse zu verändern. Einfluss ist nicht Überredung: Überredung ist kurzfristig, Einfluss hält an, und er setzt voraus, dass Menschen dir vertrauen, dich als Autorität sehen und Zutrauen in deine Entscheidungen haben. Im organisatorischen Wandel ist Einfluss der Unterschied zwischen einer vorübergehenden Verhaltensänderung und einem tiefen Wandel von Kultur und Werten.
Die drei Schlüssel
Abschnitt betitelt „Die drei Schlüssel“-
Messbare Ergebnisse klären. Wisse, was du willst, warum und bis wann. Nutze SMART-Ziele (spezifisch, messbar, erreichbar, relevant, terminiert), prüfe das Warum und halte die Kennzahlen die ganze Zeit für das gesamte Team sichtbar.
-
Vitale Verhaltensweisen finden. Eine vitale Verhaltensweise ist das, was jemand in einem entscheidenden Moment für die Veränderung tut. Beispiel: Ein Developer, der sich mehr Beteiligung des Product Owners wünscht, stellt ein Feature-Mock-up fertig und schickt es, statt direkt weiterzumachen, dem Product Owner per E-Mail zum Feedback. Um sie zu finden, konsultiere Fachleute, sichte vielzitierte Forschung oder führe eine Kulturanalyse der Teamnormen durch, und untersuche die Menschen, die dort Erfolg haben, wo die meisten scheitern.
-
Alle sechs Einflussquellen nutzen. Sie zusammen einzusetzen erhöht die Chancen, und du kannst sie auf dein Publikum hin gewichten, denn manche reagieren auf Geld und andere auf gesellschaftliche Wirkung.
Die sechs Einflussquellen
Abschnitt betitelt „Die sechs Einflussquellen“Jede Quelle verbindet Motivation (wollen sie?) mit Fähigkeit (können sie?) auf drei Ebenen. Die Beispiele führen alle das Szenario zur Beteiligung des Product Owners fort.
- Wollen sie es selbst tun? Hilf ihnen, zu lieben, was sie hassen
- Beispiel: Der Product Owner gibt Feedback, das zeitnah, wertschätzend und nützlich ist
- Haben sie die Fähigkeiten und das Wissen? Hilf ihnen, zu tun, was sie nicht können
- Beispiel: Der Developer kann die Demo-Werkzeuge bedienen und ein kurzes Video des Features per E-Mail schicken
- Ermutigen oder entmutigen ihre Kontakte und Netzwerke das Verhalten?
- Beispiel: Die Developer erinnern sich im Daily Scrum gegenseitig daran, dem Product Owner vor dem Finalisieren zu mailen
- Gibt ihnen ihr Netzwerk die Ressourcen dafür?
- Beispiel: Ein Werkzeug, das jede während des Sprints an den Product Owner geschickte Demo nachverfolgt
- Gibt es Belohnungen oder Anreize für das Verhalten?
- Beispiel: Ein Sprint-Preis in Form eines Kaffee-Gutscheins, den der Product Owner überreicht
- Hilft oder behindert die Umgebung? Mache das falsche Verhalten schwerer als das richtige
- Beispiel: Das Content-System trägt den Product Owner automatisch als Reviewer ein
Dem Team helfen, besser zu werden: Agile Coaching
Abschnitt betitelt „Dem Team helfen, besser zu werden: Agile Coaching“Der Projektmanager oder Scrum Master ist der designierte Agile Coach des Teams und hilft ihm zu erkennen, wo es sich verbessern kann, und Lösungen umzusetzen. Der Kurs rahmt das wie das Coaching einer Sportmannschaft, in drei Schritten.
Die Spielzüge entwerfen. Das Playbook deckt ab, wie das Team einen Sprint Review durchführt, wie es im Alltag arbeitet und wie es Pläne an Stakeholder veröffentlicht. Beziehe das Team in jedes Update ein, geht neue Prozesse gemeinsam durch, berücksichtige jede Position im Team und stelle sicher, dass alle den Ablauf sehen. Das Beispiel des Kursleiters: ein Brainstorming dazu, welche Teile des Prozesses versagten, Haftnotizen, um Verbesserungsideen zu gruppieren, und dann die Priorisierung, welche davon umgesetzt werden.
Feedback geben. Gib es dem Team und den Stakeholdern so früh wie möglich, jeden Tag, wie Anweisungen von der Seitenlinie. Nimm außerdem den Blick ein, den ein Coach beim erneuten Anschauen des Spielvideos bekommt, und suche nach Mustern, die zu beheben sind, und nach Spielzügen, die so gut funktionierten, dass sie in jedem Spiel laufen sollten. Bei Feedback geht es ebenso darum, zu bewahren, was funktioniert, wie darum, zu reparieren, was kaputt ist.
Feiern und lernen. Gratuliere dem Team oft, für gute Arbeit, eine zufriedene Kundin oder einen großen Launch. Wenn das Team verliert, also eine Anforderung verfehlt hat, behandle das als entscheidende Daten für das nächste Mal und hilf ihm, positiv zu bleiben und eine Lerngelegenheit zu sehen. Der Kurs zitiert Edison damit, 10.000 Wege gefunden zu haben, die nicht funktionierten.
Coaching gegen Managen
Abschnitt betitelt „Coaching gegen Managen“Beides gehört ins Projektmanagement. Der Unterschied ist Kommunikation: Managen gibt Richtung vor, Coaching lehrt. Kurs 4 hat die Führung von Teams in einem traditionellen Umfeld betrachtet; die agile Wendung ist, dass Teams selbstmanagend sein sollen, mit der Autonomie, selbst zu entscheiden, wie sie ihre Arbeit erledigen, statt von oben gesteuert zu werden, und mit dem Selbstvertrauen, Probleme selbst zu lösen.
- Beaufsichtigt die Arbeit anderer: Onboarding, Meetings leiten, delegieren, Fortschritt überwachen, Entscheidungen auf hoher Ebene treffen
- Hält das Team organisiert und auf Kurs, strafft die Kommunikation
- Richtig bei einem Notfall, der sofortiges Handeln verlangt, einer verpassten Deadline oder einem Kunden, dessen spezifische Bedürfnisse du am besten kennst
- Nötig bei ergebnisgetriebener Arbeit mit wenig Spielraum für Fehler
- Entwickelt Fähigkeiten, Motivation und Urteilsvermögen, damit Menschen selbst zu Lösungen kommen
- Bietet Orientierung und tritt dann zurück, stellt Fragen, springt in einer Krise nicht ein
- Baut Vertrauen auf, was Zufriedenheit und Arbeitsqualität steigert
- Richtig für erfahrene Menschen, die neue Kompetenzen aufbauen oder etwas Neues ausprobieren
Drei Coaching-Prinzipien: motivieren (den Wert in der Arbeit einer Person aufzeigen und Stolz darauf aufbauen), unterstützen (eine erreichbare Anlaufstelle für Probleme und Ideen sein) sowie ermutigen und wertschätzen (eine hohe Arbeitslast anerkennen und Menschen versichern, dass sie sie bewältigen können). Coaching hilft, wenn jemand in eine karrierefördernde neue Technologie oder Disziplin wechselt, wenn das Verhalten einer Person unterschwellig der Teamdynamik schadet oder wenn sich ein Team von einem Rückschlag erholt.
Das durchgespielte Szenario: Ein Scrum Team verfehlt Sprint für Sprint die Bedürfnisse der Kundschaft, der Product Owner schickt immer wieder dieselben drei Features zur Nacharbeit zurück, und das Team ist niedergeschlagen und brennt aus. Führe eine Arbeitssitzung durch alle drei Prinzipien: Brainstorme positive Gründe, warum die Kundschaft dieses Feedback gibt (motivieren), halte Wege fest, die Feedbackschleife zu straffen, etwa einen Design Sprint mit anwesender Kundschaft (unterstützen), und veranstalte eine lockere, inklusive Feier dessen, was das Team bisher erreicht hat (ermutigen und wertschätzen).
Um einen Stil zu wählen, frage: Was ist das gewünschte Ergebnis, welches Fähigkeitsniveau hat die Person, die vor dem Problem steht, und was braucht die Situation gerade jetzt?
Herausforderungen während eines agilen Wandels
Abschnitt betitelt „Herausforderungen während eines agilen Wandels“Als Coach lohnt es sich, typische Probleme zu erkennen, bevor sie eintreten. Die erste Gruppe lässt sich drei der vier Prinzipien-Themen aus Modul 1 zuordnen: Wertlieferung, Zusammenarbeit mit dem Business sowie Teamdynamik und Kultur.
| Thema | Warnzeichen | Reaktionen |
|---|---|---|
| Wertlieferung | Verpasste Liefertermine und Aufgaben, die viel länger dauern; Burnout, lange Arbeitszeiten, Erschöpfung; zu viel Work in Progress, sodass wenig fertig wird | Mehr Demos entlang der Value Roadmap; in Retrospektiven fragen, was das Team ausbremst (Abhängigkeiten, Kommunikation); kurzer Abgleich, damit alle dasselbe unter fertig verstehen; nur wenige User Stories pro Sprint, damit die Einträge gemeinsam fertig werden |
| Zusammenarbeit mit dem Business | Team nach Reviews von kritischem Feedback oder Änderungswünschen überschwemmt; Menschen weichen Feedback aus oder murren über Anfragen des Product Owners; eine Wir-gegen-die-Stimmung gegenüber dem Management, etwa nach dem Motto, dem Vertrieb bloß nichts vorführen, die finden nur Fehler | Mehr Demos, damit Feedback in gleichmäßigem Tempo ankommt und das Verständnis von fertig geteilt wird; ein Solution Design Sprint, ein ganzer Sprint zum Lösungsdesign, in dem Team und Fachleute aus dem Business zusammensitzen; Backlog-Änderungen nur zwischen Sprints einführen |
| Teamdynamik und Kultur | Niedrige Moral, Missmut und Gereiztheit; viele ungelöste Konflikte, Groll und Nachtragen; und, überraschenderweise, zu wenig Konflikt, was darauf hindeutet, dass sich Menschen nicht sicher genug fühlen, zu widersprechen | Brainstormen, wie man besser zusammenarbeiten kann, zum Beispiel Geschichten vom besten und schlechtesten Team austauschen, in dem man je war, und daraus Do’s und Don’ts ableiten; Arbeitsabläufe ändern, indem man bei schwierigen Aufgaben paarweise arbeitet oder ein regelmäßiges Meeting umgestaltet; eine Schulung oder ein Video zur Teamdynamik zum Diskutieren; Retrospektiv-Techniken wie Six Hats Thinking, bei dem jede Person einen Hut mit einem anderen Ziel aufsetzt (Positives, Negatives, Emotionen), für eine rundere Diskussion |
Zwei Anekdoten bleiben hängen. Das Team des Kursleiters ist ständig versucht, Sprints zu überladen, aber wenige Backlog-Einträge pro Sprint geliefert schlagen viele Einträge, die sich über mehr Sprints verteilen. Und ein Engineering Director, der immer wieder an den Schreibtischen der Engineers vorbeikam und um schnelle Dashboards bat, zerstörte Fokus und Velocity, bis man ihn bat, seine Anfragen an den Scrum Master zu richten, damit sie eingeplant werden konnten.
Drei weitere Coaching-Herausforderungen
Abschnitt betitelt „Drei weitere Coaching-Herausforderungen“1. Eine instabile Product Roadmap. Roadmaps ändern sich immer, aber zu viel Veränderung destabilisiert sie. Es gibt zwei Ursachen.
- Die Produktleitung verspricht zu viel; ein Product Owner, der den Stakeholdern gefallen will, sagt zu schnell ja
- Beispiel: Der CEO will Virtual Verde in vier Monaten in Asien haben, und der Product Owner stimmt zu, bevor er das Team fragt
- Vorab vereinbaren, wie neue Chancen geprüft, geschätzt und zugesagt werden
- Roadmap-Reviews mit dem ganzen Team mindestens vierteljährlich abhalten
- Wissen in beide Richtungen zwischen Product Owner und Development Team teilen
- Unsicherheit erzwingt Annahmen, und zu viele davon gefährden den Erfolg
- Beispiel: welche Pflanzen sich verkaufen, welche unterschiedliche Klimazonen überleben, welche Lieferanten man nutzt
- Annahmen dokumentieren und transparent machen
- Als Team entscheiden, ob man sie als sicher akzeptiert oder überprüft
- Mit unvoreingenommener Nutzerforschung überprüfen: Umfragen, Fokusgruppen oder andere objektive Daten
2. Unvollständige Umsetzung von Scrum. Die Rollen, Artifacts und Events von Scrum sind als Satz entworfen, daher schmälert eine teilweise oder nicht unterstützte Einführung die Vorteile. Das zeigt sich auf drei Arten: verschwimmende Rollen (ein Developer, der zugleich Scrum Master ist, macht womöglich keins von beidem gut, also besetze jede Rolle mit einer bestimmten Person), ausgelassene oder zusammengelegte Events (ohne klare Grenzen zwischen Sprint Review, Retrospective und Planning leiden Transparenz, Überprüfung und Anpassung gleichermaßen) und fehlendes Coaching (was bedeutet, dass der Scrum Master seinen Job nicht macht). Die Lösung ist, Scrum vollständig umzusetzen: jede Aktivität mit den Werten verbinden (wenn sich Leute über Stand-ups beschweren, erinnere sie daran, dass der Zweck Feedback, das Beseitigen von Blockaden, das Bitten um Hilfe und der Fokus auf das Sprint-Ziel ist) und sicherstellen, dass alle ihre eigene Rolle, die Rollen ihrer Teammitglieder und deren Zusammenspiel kennen.
3. Mangelnde Teamstabilität. Häufiges Kommen und Gehen macht die Arbeit unvorhersehbar und unterbricht den Fluss. Reaktionen: ein schneller Onboarding-Prozess, Neue mit einer Kollegin oder einem Kollegen zusammenspannen, damit sie on the job lernen (was auch bedeutet, dass ein Partner die Arbeit übernehmen kann, wenn jemand geht), und kürzere Sprints, wenn ständig Leute gehen, damit sie vorher noch einen Sprint an Arbeit abschließen können.
Die Entwicklung und das Wachstum von Agile
Abschnitt betitelt „Die Entwicklung und das Wachstum von Agile“Die Beliebtheit von Agile ist seit 2001 rasant gewachsen. Der Kurs nennt zwei Zahlen: Ein Branchenbericht fand, dass 85 Prozent der Organisationen ein produktzentriertes Modell eingeführt haben, das mit Agile in Verbindung gebracht wird, und der State of Agile Report sagt, dass 30 Prozent davon eine Mischung von Methoden nutzen. Methoden zu kombinieren ist daher eine wirklich nützliche Fähigkeit für die Karriere. Der Treiber ist die VUCA-Welt aus Modul 1, in der Agile und seine Frameworks Organisationen helfen, zurechtzukommen.
Das Manifest als Mindset hat sich kaum verändert, aber die Frameworks, die es inspiriert hat, entwickeln sich mit den Geschäftsbedingungen ständig weiter.
| Richtung | Was der Kurs sagt |
|---|---|
| DevOps | Verbindet Softwareentwicklung und IT-Betrieb. Google Cloud definiert es als organisatorische und kulturelle Bewegung, um die Geschwindigkeit der Softwarelieferung zu erhöhen, die Zuverlässigkeit von Services zu verbessern und gemeinsame Ownership unter den Software-Stakeholdern aufzubauen. Es entstand aus dem Problem, Software für Milliarden Menschen rund um die Uhr zuverlässig zu betreiben, und es geht darum, Teams aufzubauen, die sichere, zuverlässige Großsysteme schnell wachsen lassen |
| Business Agility | Eine nächste Grenze: agile Prinzipien auf das Management als Ganzes anwenden, damit die Organisation bei hoher VUCA gedeiht. Das kann bedeuten, Finanzplanung, Governance und Reporting, Einstellung und HR und mehr neu zu denken. Große Organisationen nutzen hier womöglich Scrum of Scrums oder SAFe |
| Jenseits der Tech-Welt | Der Google-Vertrieb in Lateinamerika absolvierte agile Schulungen, um auf Marktverschiebungen zu reagieren, und schätzte das geringere Risiko über den ganzen Vertriebszyklus durch frühes Feedback und häufigen Austausch mit Teammitgliedern und Kundschaft. Bauprojekte nutzten laut einem PMI-Artikel Agile gegen Verzögerungen und Budgetüberschreitungen, indem sie das Manifest in Begriffe der Baubranche übertrugen, etwa Silos minimieren und enge Zusammenarbeit fördern |
| Privatleben | Ein Kanban-Board, um einen Umzug, das Ausmisten der Garage, ein Familientreffen oder ein Grillfest zu planen |
Es sind die Praktiker, die die Werte leben, die Agile voranbringen, und dazu gehören auch neue Projektmanager.
Agile skalieren
Abschnitt betitelt „Agile skalieren“Ein Scrum Team hat seine Obergrenze bei etwa neun Personen. Ist das Team oder das Produkt größer, braucht man einen Weg zu skalieren. Modul 1 hat das Spotify-Modell als Inspiration vorgestellt; diese Lektüre ordnet es unter fünf Ansätze ein und ergänzt einen schärferen Vorbehalt dazu.
| Framework | Kerngedanke | Zentrale Details |
|---|---|---|
| SAFe (Scaled Agile Framework) | Das beliebteste skalierte Framework. Lean-Agile, schöpft aus Kanban, Scrum, XP, DevOps und Design Thinking. Wert über allem: Sein erstes Prinzip lautet eine wirtschaftliche Sicht einnehmen | Organisiert Arbeit und Teams in Agile Release Trains, die um Wertströme wie den Vertrieb herum gebaut sind. Ausgereift, mit detaillierter Anleitung, wobei manche Teile wichtiger sind als andere, also gegen das Manifest zurückprüfen, um die Agilität zu wahren. Kernwerte: Ausrichtung, eingebaute Qualität, Transparenz, Programmausführung, Führung |
| Scrum of Scrums | Eine Technik, um mehrere kleine Scrum Teams an einem Produkt zu einem stimmigen Deliverable zu integrieren | Mindestens 12 Personen, aufgeteilt in Scrum Teams von fünf bis zehn. Scrum-of-Scrums-Meetings wöchentlich, zweimal wöchentlich oder täglich, im Format eines Daily Scrum, aber pro Team: was das Team getan hat, Probleme, die es betreffen, was es bis zum nächsten Meeting erreichen will, ob es blockiert ist. Jedes Team entsendet seinen Scrum Master oder einen Botschafter, und ein Scrum of Scrums Master kümmert sich teamübergreifend um den Prozess. Sprint Planning, Review und Retrospective finden weiterhin statt. Kein offizielles Framework darüber hinaus; Teams brauchen solides Scrum-Wissen und gestalten ihre Koordination selbst |
| LeSS (Large-Scale Scrum) | Die Fähigkeit von Scrum Teams maximieren, in größeren Organisationen Wert zu liefern und Verschwendung zu reduzieren. Entstand aus mehr als 600 Experimenten | Zwei Frameworks: Basic LeSS bis etwa 50 Personen, LeSS Huge für 50 bis 6000 oder mehr. Zehn Prinzipien, unten aufgeführt |
| DAD (Disciplined Agile Delivery) | Eine Mischung von Strategien aus Kanban, LeSS, Lean Development, XP, Agile Modeling und mehr. Es leitet die Prozessentscheidungen an, die SAFe und Scrum of Scrums offenlassen, und baut eine Skalierungsstrategie aus Kontext und gewünschten Ergebnissen auf | Vier Schichten: Foundations (Prinzipien, Leitlinien, Konzepte, Rollen, Teamstruktur, Way of Working); Disciplined DevOps (sichere, wirksame Lieferung mit Daten und Sicherheit an erster Stelle); Value Streams (Ausrichtung an der Geschäftsstrategie, Verknüpfung von Kundschaft, Vertrieb und Portfoliomanagement); Disciplined Agile Enterprise (Verknüpfung des Marktes mit Governance und weiteren Unternehmensaktivitäten) |
| Spotify-Modell | Kein echtes Framework und keine Standardanleitung: eine Beschreibung, wie Spotify skalierte, indem es sich auf Kultur, Autonomie, Kommunikation, Verantwortlichkeit und Qualität konzentrierte | Squads von 6 bis 12 mit einem Coach und einem Product Owner; Tribes von 40 bis 150 mit einem Tribe Lead; Chapters, die Spezialisten ausrichten und Standards setzen; Guilds als Interessengemeinschaften |
Die zehn LeSS-Prinzipien
Abschnitt betitelt „Die zehn LeSS-Prinzipien“Kurz gefasst: die Werte von Scrum auf die größere Gruppe anwenden; überprüfen, anpassen und aus Erfahrung lernen; das Projekt klar und zugänglich halten; nur die Prozesse, Rollen und Artifacts hinzufügen, die man wirklich braucht; jeden Teil dem ganzen Produkt dienen lassen; die Bedürfnisse der Kundschaft im Zentrum halten; Produkt und Prozess in jedem Sprint verbessern; das ganze System sehen, ohne in Details zu ertrinken; kontinuierlich verbessern und Menschen respektieren; und Fluss, Warteschlangenlänge und Multitasking steuern.
Best Practices für die Skalierung
Abschnitt betitelt „Best Practices für die Skalierung“- SAFe, Scrum of Scrums, LeSS und die anderen als allgemeine Frameworks behandeln, nicht als Bedienungsanleitungen.
- Frameworks kombinieren, wenn die Situation es verlangt, solange die Werte und Prinzipien des Manifests gewahrt bleiben.
- Nicht ohne vorherige agile Erfahrung skalieren. Direkt von Waterfall zu skaliertem Agile zu springen ist ohne kundige Begleitung riskant.
- Am wichtigsten: nicht skalieren, wenn es nicht sein muss. Skalierung bringt Komplexität und Verschwendung mit sich, also sicherstellen, dass das Team zuerst die agilen Prinzipien versteht.
Skalierung reicht davon, einfach zwei Scrum Teams in einem Scrum of Scrums zusammenzuspannen, bis dahin, Tausende Menschen in SAFe zu schulen.
Die Sicht eines Site Reliability Engineers
Abschnitt betitelt „Die Sicht eines Site Reliability Engineers“Jez ist SRE bei Google, und sein Job ist es, die Systeme von Google verfügbar und zuverlässig zu halten. Für ihn geht es bei Agile und DevOps im Kern darum, komplexe Probleme zu lösen: das große Problem in Stücke teilen, zuerst die Stücke liefern, aus denen man am meisten lernt, und iterieren. Man lernt dabei sowohl, wie man das Leben der Nutzenden besser macht, als auch, welcher Prozess dafür am besten funktioniert.
Die große Verschiebung, die er über etwa zehn Jahre beobachtet hat, ist, das Frontend (Planung) und das Backend (Release und Betrieb) ins Team zu holen und das alles konsequent nutzerzentriert zu machen, eine Transformation, die laut ihm noch längst nicht abgeschlossen ist. Sein anderer Punkt ist der, den alle aussprechen, aber nicht verinnerlichen: Du wirst sehr viele Fehler machen, besonders am Anfang, und ohne sie kannst du nicht lernen. Erwarte nicht, es beim ersten Mal richtig zu machen, oder überhaupt jemals.
Agile in Vorstellungsgesprächen und im eigenen Team
Abschnitt betitelt „Agile in Vorstellungsgesprächen und im eigenen Team“Jobbörsen führen diese Rollen als Agile Project Manager, Scrum Master, IT Agile Project Manager oder DevOps Project Manager. Wähle eine Rolle, die zu deinem Erfahrungsniveau passt, deine Branchenexpertise ergänzt und Wachstum bietet, mit einer Kultur, die zu dir passt, und einem Arbeitgeber, der deine Ziele und deine Entwicklung unterstützt.
Was eine Hiring Managerin bei Google fragt
Abschnitt betitelt „Was eine Hiring Managerin bei Google fragt“| Frage | Was die Antwort verrät |
|---|---|
| Was ist der Unterschied zwischen Agile und Waterfall? | Ob du weißt, dass Agile mehr ist als Scrum, Sprints und Stand-ups, und bis zu Grundwerten wie Zusammenarbeit mit der Kundschaft, Wertlieferung und selbstorganisierenden Teams reicht. Und ob du Waterfall als die schlechteste Option darstellst oder anerkennst, dass klare Anforderungen, Risikomanagement und Aufmerksamkeit für Stakeholder jedem Projekt helfen |
| Woran erkennst du, wann ein agiler Ansatz oder ein agiles Framework passt? | Ob du verstehst, welche konkreten Projektherausforderungen Agile oder Scrum lösen |
| Wenn dein Team sich gegen eine Scrum- oder agile Praxis sträubt, wie bringst du es dazu, sie auszuprobieren? | Deine Kommunikations- und Einflussfähigkeiten und ob du wirklich daran glaubst, dass Teams sich selbst organisieren können. Google-Teams wehren sich dagegen, gesagt zu bekommen, was sie tun sollen, weil das Innovation ersticken kann, also stellt die Managerin PMs ein, die mit dem Team arbeiten, statt ihm eine Methode aufzuzwingen |
Deine eigenen Fragen an die Interviewenden sind eine Chance, die Kultur zu prüfen, von der du jetzt weißt, dass sie für den Erfolg von Agile entscheidend ist. Vorgeschlagene Fragen: Wie sehr unterstützt das Management die Kombination von Projektmanagement-Ansätzen, was ist das Erste, das ich über die Kultur wissen sollte, wie oft werde ich von den Bedürfnissen der Nutzenden oder der Kundschaft hören, und wie würde ein typischer Tag in dieser Rolle aussehen?
Agile ins aktuelle Team bringen
Abschnitt betitelt „Agile ins aktuelle Team bringen“-
Klein anfangen. Deinem Team gefällt es vielleicht so, wie es ist, also führe Praktiken in mundgerechten Stücken ein, etwa ein Kanban-Board für einen einzelnen Arbeitsstrang oder eine Retrospektive nach einem großen Meilenstein.
-
Auf Feedback hören. Zuhören und das Team dort abholen, wo es steht, ist das stärkste Werkzeug eines PMs. Frage, wie die Änderungen laufen, sammle Ideen und arbeite sie ein, das verstärkt kleine Änderungen zu großen Ergebnissen.
-
Strategisch vorgehen. Richte Änderungen auf die größten Probleme von heute aus. Ein Team, das schlecht schätzt und im Dauerkrisenmodus lebt, könnte relative Schätzung ausprobieren; zu viele Stimmen dazu, was das Produkt sein soll, brauchen vielleicht einen einzelnen Product Owner, um die Priorisierung konsistent zu halten.
-
Verbündete finden. Baue ein Netzwerk von Agile-Unterstützern auf, für Rat bei Rückschlägen und um dir selbst bei den Werten treu zu bleiben. Google hat rund 60 ehrenamtliche Agile Coaches, die sich gegenseitig für Ideen stützen.
Wiederholungs-Zusammenfassung
Abschnitt betitelt „Wiederholungs-Zusammenfassung“Zurück zur Kursübersicht → - Kurs 5 endet hier; das Glossar zu Kurs 5 sammelt sein Vokabular.