Ein gesundes Entwicklerteam arbeitet selbstorganisiert. Es gibt klare Rollen und Verantwortlichkeiten und das Team verfolgt einen durchdachten Plan für die Projektabwicklung.
Letztes Jahr haben wir ein neues Team namens Micros Scale gegründet, das sich auf die Entwicklung unserer Developer Experience Platform konzentriert, der internen Platform as a Service (PaaS) von Atlassian. Da unsere Arbeit inhaltlich und zeitlich klar abgesteckt ist, haben wir ein größeres Augenmerk darauf gelegt, inkrementelle Aufgaben abzuschließen und fokussierter, zielorientierter und proaktiver vorzugehen.
Zuvor hatte unser Team eine Menge Ad-hoc- und Betriebsarbeit zu erledigen, was der ordentlichen Planung von Sprints im Wege stand. Mindestens 55 Prozent der Teamkapazität wurden für Keep-The-Light-On-Aufgaben (KTLO) eingeteilt, also um den Laden am Laufen zu halten. Dadurch war Kanban in dieser Zeit die geeignetste Methode für uns.
Zudem befand sich das Micros Scale-Team gemäß dem Tuckman-Modell damals noch in der Gründungsphase und es gab einige verbesserungswürdige Bereiche, z. B. Kapazitätsplanung, Sprintplanung, Zielsetzung, Teamreflexion, Story-Vorbereitung und -Ausarbeitung, Prognose und Projektaufschlüsselung.
Welche agile Methode war die richtige für uns?
Micros Scale hat zwei große, hochkomplexe Projekte, deren Liefertermine den Kunden jeweils öffentlich bekannt gegeben wurden. Eine schnelle Lieferung ist demnach sehr wichtig. Wir mussten auf unseren Bereitstellungsansatz vertrauen und wollten wie ein Agile-Profi an unserer Planung arbeiten. Unser Team sollte selbstorganisiert und empirisch arbeiten und gemeinsame Ziele erreichen.
Wir führten eine Neubewertung unseres agilen Ansatzes durch, indem wir uns die folgenden Fragen stellten:
- Können wir uns für jede Iteration vornehmen, eine Zielvorgabe mit einem individuellen Thema zu erfüllen?
- Können wir uns auf den Umfang der Ergebnisse für ein oder zwei Wochen festlegen?
- Können wir die Anforderungen, an denen wir arbeiten müssen, ausarbeiten und festlegen?
- Ist die Häufigkeit von Ad-hoc-Anfragen zur Änderung der Aufgabenpriorität gering und sind eher keine umfassenden Änderungen zu erwarten?
- Ist unser Team neu und sind unsere agilen Prozesse noch nicht so ausgereift?
Da wir diese Fragen mit Ja beantworten konnten, wurde uns bewusst, dass Scrum die beste Agile-Methode für unser Team ist. Hier sind weitere Informationen, die wir als Grundlage für unsere Entscheidung verwendet haben:
| | | | |
|---|---|---|---|
| Agile-Methode | Worum geht es? | Hilft uns das? | Warum? |
| Scrum | Bei Scrum stehen eine klare Roadmap und priorisierte Arbeitsabschnitte im Vordergrund, während es bei Kanban um die Visualisierung von Aufgaben geht, die dem Team ad hoc vorgesetzt werden. | Ja | Wir haben ein klares, vordefiniertes Backlog, das verfeinert und priorisiert werden muss. Unsere Arbeit ist vorhersehbar, anders als vor einem Jahr, als das Team viele kurzfristige Aufgaben und Anfragen mit hoher Priorität bearbeiten musste. |
| Storys sollten nicht mitten im Sprint geändert werden. | Ja | Wir können einen flexibleren Ansatz wählen, in diesem Fall Scrumban (eine Mischung aus Scrum und Kanban). | |
| Scrum ist für agile Teams, die noch nicht viel Erfahrung mit Feature-Leading haben, einfacher umzusetzen. Scrum bietet Unterstützung in Form von Ritualen und Zeitvorgaben und ist dadurch präskriptiver. | Ja | Wir haben ein neues Team mit neuen Mitgliedern, das sich noch in der Forming-Storming-Phase befindet. Scrum hilft uns, unseren Reifegrad auszubauen. Mehr dazu im Tuckman-Modell. | |
| Kanban | Begrenzung der laufenden Arbeit und Konzentration auf die Verkürzung der Projektdurchlaufzeit. Anwendungsfall: kein Zeitlimit und kein fester Zeitplan für die Arbeit. Die Anfrage geht an das Team und wird so schnell wie möglich bearbeitet (ähnlich dem Service Level Agreement (SLA) von Servicedesk-Teams). | Nein | Andere Teams sind von uns abhängig. Wir benötigen geschätzte Zeitpläne, damit andere Teams entsprechend planen können. Einige unserer Verpflichtungen werden Atlassian-Kunden öffentlich bekannt gegeben. Das müssen wir bei der Planung berücksichtigen. Wir haben nicht viele kurzfristige Anfragen wie Servicedesks. |
| Hervorragend geeignet für Teams, die viele Betriebsanfragen mit unterschiedlichen Prioritäten und Umfängen erhalten. | Ja | Wir haben keine hohe KTLO-Last und der Workstream wird immer abwechselnd von einer Person im Team verwaltet. Für diese Rolle können wir bei Bedarf auf Kanban setzen. |
Wir setzen auf Scrum
Als Engineering Manager ist es Teil meiner Aufgabe, wie ein Dirigent zu agieren. Außerdem muss ich Mittler, Kompass und Coach sein. Deshalb musste ich meine Kompetenzen auch in dieser Hinsicht ausbauen. So habe ich dieses Ziel erreicht:
Mehr Agile lernen
Mithilfe der internen Lernressourcen von Atlassian konnte ich meine Kenntnisse agiler Praktiken verbessern. Ich nahm an umfangreichen Agile-Kursen teil und ließ mich von einem Agile-Coach beraten. Ich führte Gespräche mit anderen Engineering Managern, um mich über ihre Erfahrungen in anderen Organisationen und Teams zu informieren.
DACI-Framework nutzen
Wir verwendeten das DACI-Framework zur Entscheidungsfindung – DACI steht für „Driver, Approver, Contributor, Informed“ –, um effektive und effiziente Gruppenentscheidungen zu treffen. Ich führte mein Team durch den DACI-Änderungsvorschlag, um ihre Kommentare, ihre Zustimmung und ihre Unterstützung zu erhalten.
Eine Sprint-Vorlage verwenden
Ich entwickelte einen Prozess für die Verwaltung unserer Sprints und erstellte eine Sprint-Vorlage, um unsere Planung zu verbessern. Die Vorlage beinhaltet Folgendes:
- Wie der letzte Sprint besprochen werden sollte, um sicherzustellen, dass wir uns unsere Leistungen vor Augen führen und diese zelebrieren.
- Wie wir den letzten Sprint rückblickend betrachten und unsere Erkenntnisse auf den nächsten Sprint anwenden können.
- Was sind Rhythmus, Name, Ziele und Vorgaben des Sprints?
- Zu wie vielen Storys verpflichten wir uns? Was ist der Sprint-Umfang?
- Wie bei der Kapazitätsplanung die Verfügbarkeit der Teammitglieder berücksichtigt werden sollte.
- Welche Aktivitäten muss ein Sprint umfassen, damit wir umfassend auf den nächsten Sprint vorbereitet sind?
- Wie Storys verfasst, Anforderungen ausgeführt und eine Lösung vorgestellt werden sollten.
- Wie wir den Stand einer definierten Story beobachten können und was mit unvollendeten Storys zu tun ist.
Hier findest du ein großartiges Tutorial zur Durchführung von Sprints in Jira Software.
Der Wechsel zu Scrum hat sich gelohnt
Durch die Umstellung auf Scrum konnten wir folgende Verbesserungen erzielen:
Verbesserung der Velocity
Die Produktivität eines Agile-Teams wird unter anderem anhand der Velocity gemessen. Dies ist die durchschnittliche Arbeitsmenge, die ein Scrum-Team im Laufe eines Sprints bewältigt. Wir verwenden ein Velocity-Diagramm, um nachzuvollziehen, was unser Team erreichen wollte und was tatsächlich geliefert wurde. Im unten abgebildeten Velocity-Diagramm steht die graue Spalte für die Anzahl der Story Points, zu denen sich das Team auf der Grundlage seiner Kapazität verpflichtet hat. Wir vergleichen sie mit der blauen Spalte, die die Anzahl der Story Points darstellt, die tatsächlich geliefert wurden. Die Vergleichswerte können verwendet werden, um Prognosen für zukünftige Sprints anzupassen.
Risiken frühzeitig erkannt
Der Schlüssel für erfolgreiche Projekte besteht darin, Risiken frühzeitig zu erkennen und einen Lösungsvorschlag zu entwickeln.
Durch die Definition der Ziele und Sprint-Themes haben wir zusammenhängende Storys ausgewählt, um unsere Ziele zu erreichen. Während der Sprint-Sitzungen hat unser Team Storys vorbereitet, verfeinert und ausgearbeitet. Bei der Ausarbeitung haben wir uns folgende Fragen gestellt:
- Was muss getan werden?
- Warum machen wir diese Arbeit?
- Welchen geschäftlichen Mehrwert würde das Ergebnis bieten?
Dies half unseren Entwicklern, Abhängigkeiten zu erkennen und Tickets mit größeren Auswirkungen zu priorisieren, um Hindernisse zu beseitigen. Außerdem hat es uns dazu gebracht, unsere Arbeitsweise zu ändern und den projektbezogenen Fokus des Teams zu verbessern.
Erfolgreicher Projektabschluss
Kapazitätsplanung und Zielsetzung haben uns sehr motiviert und uns vor die Herausforderung gestellt, transparent mit unseren Verpflichtungen umzugehen. Wir haben eine wichtige Phase des Atlassian PaaS-Konto-Sharding erfolgreich abgeschlossen. Außerdem stehen wir kurz vor dem Abschluss der ersten Phase unseres Datenresidenz-Projekts, um mehr AWS-Regionen in puncto Zuverlässigkeit, Stabilität und Compliance abzudecken.
Übergang von Forming zu Norming
Wie bereits erwähnt, ist das Micros Scale-Team relativ neu und befindet sich nach dem Tuckman-Modell tendenziell noch in der Forming-Phase.
Die Definition eines einheitlichen Ziels für das Team hat alle zu gegenseitiger Abstimmung und Unterstützung inspiriert, um die gemeinsamen Ziele zu erreichen, und die Teammotivation gesteigert. Wir haben Fehler gemacht, haben daraus gelernt und sind dadurch besser geworden. Nach dreieinhalb Monaten haben wir neue Mitarbeiter eingestellt, um die Größe des Micros Scale-Teams um 50 Prozent zu vergrößern, und ich sehe uns immer noch voller Stolz als Norming-Team.
Verbesserte Kommunikation
Dank Planung und Engagement für jeden Sprint konnten wir die Sichtbarkeit unserer Aufgaben für das gesamte Team erhöhen und an einem Strang ziehen. Engineering Managern und Beteiligten fällt es jetzt viel leichter, Projekthindernisse und -fortschritte zu verfolgen.
Die richtige Agile-Methode wählen
- Du solltest nicht davor zurückscheuen, deine Prozesse zu überprüfen, wenn du ein Problem erkennst. Denke agil: Menschen, Prozesse und Tools.
- Bewerte dein Teamprojekt und deine Zuständigkeiten, um die besten agilen Methoden für dein Team zu finden. Auf unserer Seite Kanban vs. Scrum findest du weitere Informationen zu diesen Methoden.
- Wenn du dich für den Wechsel zu Scrum entscheidest, solltest du ein Jira Scrum Board verwenden oder eine Vorlage in Confluence oder dem Tool deiner Wahl erstellen.
Erstelle für jeden Sprint eine Sprint-Planungsseite, auf der du den letzten Sprint noch einmal durchgehen und auf der Grundlage der Kapazität und des Sprint-Ziels deines Teams den nächsten Sprint planen kannst. Hier ist meine persönliche Confluence-Vorlage:
Hier ist meine Vorlage für die Kapazitätsplanung, die Teil meiner allgemeinen Scrum-Vorlage ist:
Außerdem ist hier noch meine Vorlage für Sprint-Ziele und -Umfang:
Es ist hilfreich, eine weitere Seite zu erstellen, auf der du während des Sprints festhalten kannst, wie das Team in der vergangenen Woche abgeschnitten hat, welche Storys in den nächsten Sprint übertragen werden müssen (Grooming) – abhängig vom aktuellen Stand des Sprints –, und aus dem Grooming entstandene Storys auszuarbeiten (Story-Optimierung). Hier ist meine Vorlage für das Grooming und die Optimierung des Backlogs während des Sprints:
Jedes Team ist anders. Was für uns funktioniert hat, funktioniert möglicherweise nicht für andere Teams. Scrum, Kanban oder eine Kombination wie Scrumban und Kanplan könnten besser geeignet sein. Um die richtige Methode zu finden, solltest du die Anforderungen und Bedürfnisse deines Teams bewerten.
