Gegeben: Ein Unternehmen, das das Scaled Agile Framework (SAFe) verwendet, um die agile Entwicklung im gesamten Unternehmen zu skalieren. 10 Entwicklungsteams zu einem großen Team zusammengefasst (Agile Release Train gemäß SAFe-Terminologie), um ein gemeinsames Produkt zu liefern; die Notwendigkeit einer zweitägigen vierteljährlichen Planung (PI Planning) zur Festlegung des Arbeitsplans der IT-Teams für die nächsten 3 Monate *; drei Entwicklungsbüros mit einem Abstand zwischen den entferntesten Büros von mehr als 6.000 Kilometern und einem entsprechenden Arbeitszeitunterschied von 5 Stunden; Vorherige Planungserfahrung, die die Verwendung von analogen Tafeln / Whiteboards / Textmarkern / Haftnotizen und die jeweilige physische Präsenz aller wichtigen Mitarbeiter im selben Raum implizierte.
* Dieses Schwergewichtskonstrukt „Der Arbeitsplan der IT-Teams für die nächsten 3 Monate“ droht die Größe des Textes erheblich zu erhöhen. Im Folgenden werde ich ihn daher durch „die Verpflichtung“ ersetzen. Dementsprechend bedeutet die Ausarbeitung und Annahme eines Arbeitsplans „sich verpflichten“.
Warum brauchen wir das?
1) Ermüdung mit analogen Arbeitsmethoden. Während Raumschiffe den Raum pflügen und Elon Musk seine Tunnel langweilt, haben wir, die IT-Leute, beharrlich mit Textmarkern auf Haftnotizen geschrieben, die sie auf die Bretter kleben - das ist wirklich eine Art Dissonanz, nicht wahr? ? So sah unser Engagement vor einiger Zeit aus:
Ja, dies ist ein Blatt Papier mit einer Größe von etwa 2 x 5 Metern, wobei jede Haftnotiz nach der Planung in eine JIRA-Aufgabe umgewandelt werden soll ...
2) Müdigkeit unserer nomadischen Kollegen. Trotz der Tatsache, dass sich unser Hauptsitz in einem recht angenehmen und warmen Land befindet, war ich überrascht, als ich letztes Jahr herausfand, dass sie weit davon entfernt sind, sich über all die Reisen hin und her zu freuen. Meine Argumente „Na ja, Sie können einfach Spaß daran haben, in der Sonne am Meer zu entspannen“ wurden nicht sehr herzlich aufgenommen. Da sich herausstellte, dass nicht jeder zu häufigen Geschäftsreisen bereit ist, die von seinen Familien oft nicht begrüßt werden, konnten einige Kollegen angesichts der Entfernungen zwischen den Büros und der Häufigkeit der Besprechungen einfach nicht die ganze Zeit in der Luft aushalten.
3) Einbeziehung weiterer IT-Kollegen in den Planungsprozess. Wie aus dem obigen Absatz hervorgeht, konnten wir es uns kaum leisten, dass alle IT-Mitarbeiter aus den drei Büros zur Planung kamen. Daher wurden nur die Auserwählten ausgewählt, wodurch die anderen vom Prozess ausgeschlossen wurden. Dies war für den Teamgeist im Allgemeinen kaum von Vorteil.
4) Kostenoptimierung. Ja, dies ist ein heikler Moment - es gibt ziemlich viele Schlüsselpersonen, und es ist keineswegs billig, wenn sie viermal im Jahr hin und her fliegen.
Teil Null: Arbeiten mit Portfolio Backlog
Alles beginnt viel früher als die eigentliche Planung. Um während der Planung produktiv an der Verpflichtung arbeiten zu können, müssen Sie etwas haben, für das Sie sich verpflichten können. Um dies sicherzustellen, muss ich Geschäftsinhaber so früh wie möglich mit der Arbeit an wahrscheinlichen Initiativen (oder, in der SAFe-Terminologie, Epics, aber im Folgenden werde ich unseren üblichen Begriff verwenden) „beladen“. Idealerweise sollte dieser Prozess vollständig von der iterativen Natur der vierteljährlichen Planung getrennt sein und seinen eigenen Kanban-Weg gehen. Wir haben SAFe Portfolio Kanban als Grundlage genommen:
Wir haben ein separates JIRA-Projekt mit drei Problemtypen: Epics, Business Initiatives und Architectural Initiatives; sowie das entsprechende Kanban Board. Der Algorithmus für den Geschäftsinhaber der Initiative ist einfach: Er fügt diesem Projekt ein Problem hinzu und geht standardmäßig zu Backlog. Dies ist der erste Status unseres Kanban-Flusses -
Trichter:
Hier werden die noch nicht überprüfbaren Initiativen gespeichert. Der Geschäftsinhaber arbeitet am Inhalt der Initiative, bis er sich für den nächsten Schritt bereit fühlt. In dieser Phase müssen mindestens die Felder Problemstellung, Gewünschtes Ergebnis und Erfolgsmaß ausgefüllt sowie eine etwas detailliertere, aber einfachere und klarere Darstellung vorhanden sein. In dieser Phase ist es wichtig, technische Lösungen beiseite zu lassen und sich auf Geschäftsparameter zu konzentrieren. Wenn alle Daten erfasst sind, versetzt der Geschäftsinhaber die Aufgabe in den nächsten Status -
Überprüfen.Wir führen wöchentlich Überprüfungen für Geschäfts- und Architekturinitiativen durch. Im Idealfall handelt es sich um eine fünfminütige Präsentation mit anschließenden Fragen und Antworten. Als Ergebnis der Überprüfung wird entschieden, was als nächstes mit der Initiative geschieht. Es kann:
- zur Überarbeitung an Funnel zurückgeschickt werden,
- ohne Chance auf weiteres Leben abgeschafft werden (in diesem Fall verwende ich einen speziellen Status " Veraltet", der im Kanban-Board versteckt ist),
- genehmigt werden und zur nächsten Stufe übergehen - Analysieren.
Zu diesem Zeitpunkt haben wir - Yippee !!! - kann endlich IT-Leute einbeziehen: Analysten, Architekten, Leads, jeden. Mit „wir“ meine ich mich als Release Train Engineer. Idealerweise sollten es aber auch Geschäftsinhaber sein, die bereits Erfahrung und Autonomie gesammelt haben, um die richtigen Teams zu engagieren und Analysen unabhängig voneinander zu starten. Auch hier schreibe ich über den Idealfall. Tatsächlich schwankt der Grad der Selbstorganisation unserer Kollegen, und in einigen Fällen bitten sie einen speziell ernannten Moderator um Hilfe, aber ich versuche, mich von dieser Praxis zurückzuziehen.
Der Zweck dieser Phase ist die vorläufige Analyse oder, wie wir es nennen, die Vorentdeckung. Als Ergebnis sollten wir ein Minimum erhalten, das es uns ermöglicht, uns zu verpflichten: vorgeschlagene Lösungen, Risiken und Abhängigkeiten, nicht funktionale und Infrastrukturanforderungen, Benutzerkarten, Architekturschemata. Darüber hinaus bitten wir die Teams, eine vorläufige Bewertung der Story-Punkte auf Feature-Ebene vorzunehmen. Auf diese Weise können wir die Prioritäten am Ende des Quartals festlegen.
Zu diesem Zeitpunkt wird für jede Initiative ein persönliches Kanban-Board erstellt, in dem Features und Storys zu sehen sind, mit einem vorläufigen Link zu einer bestimmten Iteration, die von einem separaten JIRA-Workflow bereitgestellt wird. Durch Ändern des Status können wir das Problem einer Iteration zuordnen. Swimlanes in Kanban Boards werden von Entwicklungsteams konfiguriert. Da unser JIRA-Ökosystem ziemlich kompliziert ist, erstellen wir während der Vorentdeckung und Ermittlung Aufgaben in separaten Projekten, um die Rückstände der Teams nicht zu verunreinigen:
Auch in der Phase vor der Entdeckung beziehen wir Architekten oder, wie es in letzter Zeit oft praktiziert wurde, ihre vertrauenswürdigen Mitarbeiter ein - „EA Ambassadors“. Ihre Aufgabe ist es, allen Teilnehmern die Vision der Architekturabteilung zu vermitteln, bei der Suche nach der besten Lösung zu helfen und diese Lösung schließlich mit dem Leiter der Unternehmensarchitektur des Unternehmens zu genehmigen.
Wenn alle Beteiligten der Ansicht sind, dass die Initiative ausreichend analysiert wurde und für den nächsten Schritt bereit ist, wird sie in den nächsten Status
verschoben -
Portfolio Backlog.In dieser Phase ist es wichtig, eine WSJF-Priorisierung durchzuführen (
Weighted Shortest Job First ). Zu diesem Zweck haben wir 3 Wochen vor der Planung ein großes Treffen, das leider bisher immer viele Stunden gedauert hat. Während dieses Treffens bewerten Mitglieder des Vorstands den Geschäftswert, die Zeitkritikalität, die Risikominderung und die Chancenförderung mithilfe von Fibonacci-ausgerichtetem Planungspoker:
Um die Geschichte der Initiativen verfolgen zu können, füge ich für jede ein Label in JIRA mit Quartalsdaten hinzu: 2018Q4, 2019Q1 usw.
Lassen Sie mich mit Blick auf die Zukunft alle möglichen Status beschreiben. Nach der endgültigen Verpflichtung bei PI Planning werden erfolgreich aufgenommene Initiativen in den
Implementierungsstatus versetzt , während diejenigen, die nicht angepasst sind, den Status "
Geparkt " erhalten und möglicherweise für die nächsten Quartale in Betracht gezogen werden. Gelieferte Initiativen werden in den Status "
Fertig " versetzt.
Als Ergebnis haben wir das folgende Bild auf dem Kanban Board:
Natürlich sind wir noch nicht einmal in der Mitte unseres Weges, aber im Moment kann ich das dank der Implementierung des Portfolio Backlog bereits feststellen
- Unternehmer haben begonnen, ihre Initiativen im Detail durchzuarbeiten und sich gründlich auf die Überprüfung vorzubereiten.
- Die Bewertungen sind auf gute Weise akribischer geworden.
- Die Teams haben mehr Zeit für die Vorentdeckung.
- Ich verliere keine alten Initiativen - ich kann jederzeit zu den geparkten, nicht gelieferten oder vergessenen Initiativen zurückkehren und weiter daran arbeiten.
In dieser Phase verwendete Werkzeuge:
- Atlassian Jira Software Server
- Plugin-Farben für Jira - zur Hervorhebung von Geschäfts- und Architekturinitiativen
- Das Plugin 'Struktur - Projektmanagement im Maßstab' - zur Visualisierung der Struktur von Initiativen und zugehörigen Funktionen sowie deren WSJF-Priorisierung
- Atlassian Confluence - Quelle der internen Dokumentation
- Lucidchart und seine Plugins für Jira und Confluence - zum Zeichnen von Diagrammen
Teil I. Vorbereitung für die PI-Planung
Einen Monat vor PI Planning kommt die geschäftigste Zeit. Zu viele Dinge müssen berücksichtigt werden, und um nichts auszulassen, muss ich ein mehrseitiges "logistisches" Google-Formular erstellen. Lassen Sie mich die wichtigsten Registerkarten aus diesem Formular und die damit verbundenen Aktivitäten beschreiben.
Feedback Einige Tage nach jeder PI-Planung führen wir eine Retrospektive durch, die uns hilft, nicht zu vergessen, zu welchen Schlussfolgerungen wir gekommen sind und wie wir den Kurs anpassen müssen. Dies ist ein wichtiger Teil für die kontinuierliche Verbesserung.
Technische Vorbereitung. Mit dem Übergang zur Fernplanung sind spezifische Anforderungen aufgetreten, z. B. die Qualität der Internetverbindung (Priorisierung und Optimierung der Routen für JIRA und Confluence) sowie die Video- und Audiopräsenz (wir verwenden die Logitec Group-Kits, Jabbra-Mikrofone und persönlichen Kopfhörer in verschiedenen Kombinationen , Webcams, Zoom-Software für Videokonferenzen).
Moderatoren. Es ist eine Liste der Mitarbeiter, die für die Moderation in jeder Arbeitsgruppe verantwortlich sind, mit Angabe ihres Standorts und einem Link zum permanenten Zoom-Kanal der Arbeitsgruppe.
Publikum Die vollständige Liste aller eingeladenen Personen.
Checkliste Die vollständige Liste wichtiger Aufgaben mit Fristen und Verantwortlichen. Um Ihnen im Folgenden einen Einblick zu geben, finden Sie einige Beispiele für die typischsten und wichtigsten Aufgaben, die für jede PI-Planung relevant sind: Schulung der Moderatoren (ein Schulungshandbuch wurde mit allen erforderlichen Schritten erstellt, z. B. Organisation eines Arbeitsteams, Zeitplanung der Besprechungen und Zerlegung der Initiative in eine Liste von Merkmalen); Aktualisierung der Standortpläne der Arbeitsgruppen für jedes Büro; Kontrolle des Velocity-Updates für alle Entwicklungsteams; Mahlzeiten bestellen; Erstellen von Berichten aus früheren Quartalen; Ausdrucke von Initiativlisten und Zeitplänen.
Teil II. PI-Planung und der Prozess des Engagements
Nach all den vorbereitenden Vorbereitungen kommt endlich dieser Moment - der Beginn der PI-Planung. In zwei Tagen müssen wir alle Initiativen entdecken, sicherstellen, dass die Informationen ausreichend sind, und uns verpflichten. Nach ein paar aufmunternden Gesprächen gehen die Arbeitsgruppen zu ihren Plätzen und machen sich an die Arbeit. Derzeit wird die Anzahl der Gruppen als 4x4x2 auf die drei Büros verteilt, und Remotebenutzer werden über einen dedizierten Zoomkanal mit der erforderlichen Gruppe verbunden.
Nach Abschluss der Ermittlung für jede dieser Initiativen stellt der Moderator sicher, dass alle erforderlichen Daten wie Akzeptanzkriterien, technische Lösung, Risiken, Abhängigkeiten und die Notwendigkeit einer neuen Infrastruktur verfügbar sind, und kennzeichnet die Initiative mit der IT Kontrollkästchen "Sitzung beendet" zur einfachen Verfolgung des Fortschritts. Danach kann die Arbeitsgruppe mit der nächsten Initiative fortfahren.
Nach einem Dutzend PI-Planungen ist das Gefühl, unter ständigem Stress und Zeitdruck zu stehen, das von Anfang an bei uns war, deutlich verblasst, und jetzt ist alles mehr wie gewohnt. Am Nachmittag des ersten und zweiten Tages der Planung ist es an der Zeit, sich nach Prioritäten zu beeilen. Um eine Verpflichtung zu erfüllen, habe ich mehrere separate Strukturen. Die erste ist eine Struktur, die eine Liste von Funktionen und Geschichten enthält, die für das Engagement geplant sind:
Leider enthält diese Struktur auf dem Screenshot nur Aufgaben, die nicht in das Engagement des aktuellen Quartals passten, sodass die Stichprobe nicht repräsentativ ist. In jedem Fall kann ich im Suchfeld die erforderliche Initiative in der Reihenfolge ihrer Priorität nach Nummer auswählen, die für jedes Feature und jede Story in einem separaten Feld angezeigt wird. Ändern Sie den Status der Probleme von "Geplant" in "Festgeschrieben" und setzen Sie sie auf die gewünschte Iteration und damit für sie verpflichten:
Infolgedessen wird das Problem aus dieser Struktur verschwinden und in einer neuen Struktur erscheinen, die das wachsende Engagement widerspiegelt:
Wie Sie auf dem Screenshot sehen können, fallen die Storys in dieser Struktur in den Ordner des Entwicklungsteams, zu dem sie gehören, und werden nach Iteration gruppiert. Hier sehe ich die Gesamtgeschwindigkeit des Teams im Ordnernamen. Außerdem wird in der Spalte "Commitment" die Überbindung automatisch für jedes Team mithilfe einer benutzerdefinierten Formel ermittelt und hervorgehoben.
Wenn die Initiativen mit der ersten und höchsten Priorität größtenteils leicht in eine Verpflichtung einbezogen werden können, sobald einige Teams ihre Rückstände bis zum Ende füllen, kann es nach bestimmten Argumenten und Diskussionen zu entsprechenden Problemen mit einigen der Initiativen kommen infolgedessen verschoben (geparkt).
Am Ende dieses recht unkomplizierten Prozesses schwören die Teams, ihr Engagement auf der Firmenflagge zu zeigen (ok, nicht wirklich) und sich zu ihren Häusern zu beeilen (nun ja, nicht wirklich, meistens fliehen sie in eine Bar, um zu feiern).
In dieser Phase verwendete Werkzeuge:
- Atlassian Jira Software Server
- Das Plugin 'Struktur - Projektmanagement im Maßstab' - zur Überwachung des Ermittlungsprozesses und während der Ausführung der Verpflichtung.
Teil III. Klonen von Problemen in das funktionierende JIRA-Ökosystem des Unternehmens
Während alle trinken, arbeitet die RTE daran, Verpflichtungen in der Form zu schaffen, in der sie an die Rückstände der Entwicklungsteams verteilt und während des gesamten Quartals überwacht werden können. Zu diesem Zweck verwende ich das Plugin "Bulk Clone Professional für Jira". Es fügt dem Menü "Massenänderung" ein Element hinzu, das das kollektive Klonen ausführt, und verfügt über die erforderlichen Funktionen wie das Klonen von Links, das Aktualisieren von Links zwischen neu erstellten Klonen, das Aktualisieren von epischen Links und das Hinzufügen einer Zusammenfassung Präfix und automatische Kennzeichnung:
Ich füge Status als Präfix hinzu, da die Status in der Planungsphase die geplante Iteration der Fertigstellung widerspiegeln. Infolgedessen kann ich in der Zusammenfassung sofort sehen, wann wir das Feature oder die Story fertigstellen möchten.
Zuerst klone ich absolut alle Probleme in ein separates Global Backlog-Projekt, da wir Epen darin behalten und ich bei neu geklonten Aufgaben tatsächliche Verbindungen zu epischen Geschichten haben muss. Und schon als zweiten Schritt stelle ich JQL-Anfragen für jedes Entwicklungsteam separat und verschiebe die Geschichten in die Arbeitsprojekte der Teams.
Als Ergebnis erstelle ich eine Struktur, die das aktuelle Engagement widerspiegelt und aus endgültigen Geschichten besteht, die ich dann zur Überwachung verwende:
Im Allgemeinen sind die Vorteile dieses Ansatzes die folgenden:
- Für einen IT-Mitarbeiter ist es einfacher, neue Funktionen und Storys einzugeben, als sie mit einem Textmarker auf eine Haftnotiz zu schreiben.
- Viele Dinge, wie z. B. verbleibende Kapazität und WSJF-Aktualisierung in Abhängigkeit von den Schätzungen der Storys, werden automatisch mithilfe benutzerdefinierter Formeln berechnet.
- Dank des Klonens bleibt das ursprüngliche Engagement für die Geschichte erhalten und wir können jederzeit darauf zurückkommen.
- Das spart uns Zeit und Energie bei der Planungsvorbereitung - Papierhandhabung kostet Energie.
- Natürlich ist es großartig, dass wir JIRA keine Probleme mehr hinzufügen müssen, indem wir Haftnotizen eingeben.
In dieser Phase verwendete Werkzeuge:
- Atlassian Jira Software Server
- Das Plugin 'Bulk Clone Professional für Jira' - zum Klonen von Funktionen und Storys in funktionierende JIRA-Projekte.
- Das Plugin 'Struktur - Projektmanagement im Maßstab' - zur Erstellung der endgültigen Commitment-Struktur.
Nachwort
Liebe Freunde, ich verstehe natürlich, dass die obige Übersicht eher oberflächlich ist und viele Dinge detaillierter enthüllt werden könnten - Überwachung der Kapazitätsverteilung zwischen Geschäfts- und Architekturinitiativen und operativen Aufgaben, Berechnung kundenspezifischer Formeln in Strukturen, Management von Risiken und vieles mehr. Aber ich weiß immer noch nicht, ob dieses Thema für das Publikum interessant ist und wenn ja, was genau. Wenn ich Interesse sehe, teile ich gerne meine Erkenntnisse zu den relevanten Themen mit.
Und noch etwas - es ist schwer zu glauben, dass es möglich sein würde, aber dennoch möchte ich in den Kommentaren wirklich Butthurt vermeiden, der mit Agile, Frameworks, effektiven und „effektiven“ Managern zusammenhängt. Bitte denken Sie daran, dass ich den technischen Teil des gesamten Prozesses beschrieben habe, um das Interesse der Menschen zu wecken, die dem Thema nahe stehen, und freue mich auf relevante Diskussionen.
Wir sehen uns in den Kommentaren!