Schlagwort-Archive: Planung

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

Allgemein, Management, News, Planning, Scale, , ,

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Ansätze, um hinweg über viele Teams zu skalieren (Scaling Agile) fehlen häufig und werden für größere Unternehmen die auf Agilität setzen möchten immer wichtiger. Häufig scheitern Implementierungen von Scrum jedoch an dem fehlenden übergeordneten Koordinierungsbedarf, da der Fokus in den meisten Fällen zu sehr auf die Entwicklungs-Teams und weniger auf die Unternehmens- oder Portfolioebene gelegt wird. Besonder viele Reibungsverluste gibt es bei der Integration von agilen Organisationsteilen (z.B.: Entwicklung von neuen Systemen) und weiterhin eher traditionell organisierten Organisationsteilen (z.B.: Vertriebsorganisation, Abteilungen mit Fokus auf Wartung, Zulieferer).

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht neu. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Scaled Agile @ Spotify im Detail

Einen sehr interessanten Ansatz für die Skalierung von agilen Teams verfolgt Spotify. Hier wurde auf über 30 Teams („Squads“) skaliert. Teams die in einem Kontext arbeiten, werden in sogenannten „Tribes“ gruppiert.  Der Kontextübergreifende Austausch geschieht durch die Etablierung von so genannten “Chapters”.

Diese Begrifflichkeiten mögen für einige gewöhnungsbedürftig sein aber sind sicherlich für viele Agilisten attraktiv, da diese häufig den klassischen Methodenwerken schon alleine wegen der vielfach missbrauchten Begrifflichkeiten ablehnend gegenüber stehen.

Liefereinheiten

Squad

Entspricht in etwa den üblichen agilen Teams, wobei kein spezifisches Vorgehen oder Framework wie beispielsweise Scrum oder Kanban vorgeschrieben ist. Es gibt einen Product Owner, der die Themen vorgibt und jemanden, der sich um das Team und die Einhaltung von Regeln kümmert (“Agile Coach”). Der “Agile Coach” gehört nicht ausschließlich zu einem Squad er muss aber für „seine“ Mitarbeiter verfügbar sein.

Scaling Agile @ Spotify
Scaling Agile @ Spotify

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters weiterlesen →

Commitment Product Owner

Product Owner, ,

Stefan Roock schreibt über das Commitment des Product Owners, dass dieser sich ebenfalls auf die Sprint-Planung verpflichtet. Der PO darf – wie das Entwicklungsteam auch – deshalb das Ergebnis der Sprint-Planung nur dann akzeptieren, wenn er es für sinnvoll hält.

Ziele der Sprint Planung

Zunächst ist das Planning ein Instrument, um die kommenden 1-4 Wochen (je nach Länge der Sprints) zu planen. Im Rahmen der Planungssitzung einigen sich Entwicklungsteam und Product Owner auf die zu erreichenden Ziele und die hierfür zu erledigenden Stories. Es ist entscheidend, dass eine Übereinkunft erzielt wird, dass die vereinbarten Ziele und Sprint-Elemente sinnvoll sind und umgesetzt werden können. Nur Planungssitzungen die mit einer Übereinkunft hinsichtlich Umfang, Zielsetzung und Sinnhaftigkeit enden sind zielführend. Plannings, die nur „pro forma“ durchgeführt werden und deren Ergebnisse im Sprint-Verlauf ignoriert werden (Priorität, „ach da kommt was Neues!“, „machen wir doch nicht“) sind nicht hilfreich sondern schädlich.

Probleme bei der Planung von Sprints

Typische Probleme von Product Ownern im Rahmen der (Sprint)Planung sind:

  • Die Planung wurde nicht vorbereitet, das Team sieht die Stories im Planning zum ersten Mal. Unsicherheit erhöht den geschätzten Aufwand. Im Planning die Unsicherheiten zu reduzieren kann zeitaufwändig und nervenaufreibend sein.
  • Trotz Vorbereitung durch Backlog Groomings und Weitergabe von Informationen an das Team kann es vorkommen, dass erst in der Planungssitzung oder erst im Planning 2 Abhängigkeiten aufgedeckt werden, die eine (wirtschaftlich) sinnvolle Planung des Sprints sehr schwer machen.
  • Aus Sicht des Product Owners wird zu viel Aufwand in Grundlage wie Infrastruktur und Entwicklungsumgebung investiert. Das Vorhaben erscheint nicht mehr wirtschaftlich umsetzbar. Der geschätzte Aufwand für die besprochenen Stories ist so hoch, dass eine wirtschaftliche Umsetzung zweifelhaft erscheint. Dies wird jedoch erst im laufenden Projekt erkannt.

Iterationen erzwingen Entscheidungen

Allgemein, For a good read

Führt man kurze Iterationen mit definiertem Inhalt ein, so stößt man relativ häufig auf Widerstand oder erlebt, dass die versprochenen Inhalte nur als „fast fertig“ geliefert werden oder das der Product Owner sich bereits in der Planungssitzung nicht festlegen möchte, was genau geliefert werden soll.

Stefan Roock hat in seinem Artikel „Understanding Sprints and Timeboxes“ meiner Meinung nach sehr gut zusammengefasst weshalb kurze Iterationen mit einem definierten Inhalt so wichtig sind:

Es müssen Entscheidungen zu konkreten Fragestellungen und zu Prioritäten getroffen und eingehalten werden.

Iterationen erzwingen Entscheidungen weiterlesen →