APM 12 – Scaling Agile mit Bernd Schiffer

Die meisten Veröffentlichungen zu Scrum, Kanban und anderen agilen Methoden konzentrieren sich auf die Situation mit genau einem Team. Dabei ist der Übergang zu agilen Methoden mit mehreren Teams alles andere als trivial, gerade für den oder die Product Owner. In dieser Episode erklärt Bernd Schiffer, was man hierzu alles machen kann. Bitte beachtet die Shownotes für Links und weitere Informationen. Wenn genügend Wünsche eintrudeln, dass wir die wegen Audio-Breakdown übersprungenen weiteren unstrukturierten sowie ganz neuen Modelle auch noch besprechen, machen wir einfach eine weitere Episode.
avatar Toby Baier Paypal Icon Amazon Wishlist Icon Bitcoin Icon
avatar Bernd Schiffer
avatar Tagamemnon
avatar v0tti

Intro

00:00:00

Begrüßung

00:00:28

Heute als Gast: Bernd Schiffer — Während der Sendung findet ein Fussballspiel zwischen Deutschland und Australien statt — it-agile — Tobias Baier — Buzzword-Bingo.

Was heißt Agile?

00:06:29

Agile heißt felxible Planung — Scrum — Kanban.

Skalierung

00:13:33

In den Firmen in denen Tobias bisher arbeitete, gab es nicht nur ein Entwicklungsteam — Herausforderungen bei mehreren Scrum-Teams — Vorgeschlagene Teamgröße: 9 Personen — Auch Teams mit 15 Leuten waren schon erfolgreich — Bei größeren Teams ist eine Spaltung sinnvoll — "Wenn man ein Team spaltet, hat man hinterher Zwei" (Tobias) — Product Backlog — Product Owner ist ein sehr anspruchsvoller Job — Lernen zu delegieren ist das A und O als Product Owner — "Ist Big Corporate ein Buzzword?" (Bernd) — Bei vielen Teams hat man eine Teamlandschaft.

Übergang zum agilen Produktmanagement

00:32:07

Firmen die auf agile umschwenken — Agiler Pilot — Projektbasiert statt teambasiert — Ein ranghoher Manager (Sponsor) hält den Rücken frei — Als Agiler Pilot sollte man nicht das beste Team verwenden — Wasserfallmodell — Flächendeckendes Ausrollen ist eine weitere Methode.

Herausforderungen bei der Zusammenarbeit mehrerer Agilen Teams

00:42:02

Gemeinsamen Backlog — Oft gibt es Abhängigkeiten bei mehreren Teams ('Large Scale Scrum-Methode' - hierachische Product Owner Struktur)  — Bereichs Product Owner <> — Alternative PO Modelle — Gießkannenprinzip — Scrum Master.

Was ist Large Scale Scrum

01:09:44

Craig Larman — Bas Vodde — Scrum Alliance (Buch: LSS - more with less)  — Scaled Agile Framework (“SAFe”) — Spotify Approach — Marty Cagan.

Was ist SAFe?

01:18:02

Keine generelle Empfehlung von Bernd — Dean Leffingwell — RUP — SAFe Big Picture: Extreme Programming, Kanban, Scrum, ... (nichts für kleine Unternehmen: SAFe´s kleinste Einheit ist 50-150 Leute - Aglie Release Train)  — "Endlich mal was los in diesem Podcast!" (Tobias) — "DAD ist eigentlich sowas wie SAFe, nur hats nicht so einen coolen Namen" (Bernd) — Evidence Based Management — "Geldverdienen an sich ist ja auch nichts Unanständiges" (Tobias).

Weitere unstrukturierte Modelle

01:53:46

ScAleD (rekursives Akronym) (basiert auf Prinzipien anstatt auf Prozessvorgaben)  — Donald Reinertsen Buch: Product Development Flow (auch eine Ansammlung von Prinzipien)  — Foliensatz zum Thema.

Outro

02:05:17

2 Gedanken zu „APM 12 – Scaling Agile mit Bernd Schiffer

  1. Jan

    Ein sehr spannendes Thema :)

    Was meiner Meinung nach in dem Gespräch leider vermischt wurde und Agile-Interessierte verwirren wird, ist der Unterschied zwischen der Einführung von z. B. Scrum in einzelne Produkt- oder Feature Teams (das ist *nicht* “Scaling Agile”) und der Organisationsstruktur-übergreifenden Einbettung agiler Arbeitsweise (Scaling Agile).

    Ob man von z. B. 1 Scrum Team mit der Zeit in der Firma zu beispielsweise 5 Scrum Teams kommt, ist nicht was meistens gemeint ist wenn von Scaling Agile die Rede ist. Es geht nicht um die Betrachtung horizontaler Organisationsebenen.

    Scaling Agile ist eben keine reine Multiplikation von agilen Teams sondern eine vertikale Durchdringung über verschiedene Organisationsebenen hinweg.

    Die Probleme dabei bleiben aber die üblichen “Scrum Probleme”:
    – Unglaublich viele Meetings
    – Scrum Master die überhaupt keine Erfahrung mit Human-centered Design orientierter Softwareentwicklung haben
    – Schlechte Kommunikation zwischen in sich geschlossenen und eigenverantwortlichen Scrum Teams.

    Antworten
    1. Bernd Schiffer

      Danke für Deinen Kommentar. Mir ist keine Definiton bekannt, nach der Agiles Skalieren nur auf die Vertikale, nicht aber in die Horizontale zielt, oder das Agiles Skalieren sich nicht um die Transition von einem zu mehreren Teams kümmern würde. Auf welche Definition beziehst Du Dich hier?

      Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.