Direkt zum Hauptbereich

Koordination von vielen Teams am Beispiel von Scrum @ Scale (der Scrum Inc.)

Viele Praktiker stoßen immer wieder auf das gleiche Problem: Man coacht ein Team und es wird richtig produktiv. Dann stellt sich sofort das nächste Problem: Wie kann ich den Zufluss von Projekten begrenzen und die Arbeit sinnvoll auf mehrere Teams verteilen? Es gibt eine Reihe von Ideen am Markt. Nun bringt Scrum Inc. - die Beratungsfirma von dem Scrum-Miterfinder Jeff Sutherland - ein eigenes Framework auf den Markt. Brauchen wir jetzt ein weiteres? Ja, denn Scrum @ Scale schafft es, sich auf das Wesentliche zu begrenzen, ohne bestehende andere Modelle verdrängen zu wollen. Grund genug, sich dieses Framework genauer anzusehen.


Am Mittwoch fand in München der erste Scrum-@-Scale-Kurs weltweit statt. Er wurde von Scrum Inc. und Scrum Events organisiert. (Wie Jürgen es immer schafft, eine angemessene Location in München zu vernünftigen Preisen zu organisieren.)

Abb. 1: Die Teilnehmer des ersten S@S-Kurses am 10.12.2014 in München (Foto: Jürgen Dittmar)
In gut acht Stunden hat Alex Brown von Scrum Inc. uns einen Überblick über deren Ansatz gegeben, die Arbeit über viele Teams hinweg zu organisieren. Im Blog von Scrum Inc. gibt es ein gut 20minütiges Video dazu: http://www.scruminc.com/scrum-scale-case-modularity/

Wir haben uns schon mit anderen Modellen wie SAFe (/1/), LeSS und DAD sowie Governance und Strategiemodellen aus anderen Bereichen beschäftigt. Überall gibt es gute Ideen. Was mir Scrum @ Scale gefällt ist, ist dass es viel übersichtlicher und modularer ist. Es besteht aus zwei Kreisläufen:
  • Der Product-Owner-Cycle startet bei der strategischen Vision, priorisiert und zerlegt die Anforderungen. Die Teams bauen das Produkt, integrieren es und liefern es aus. Dann wird das Feedback eingesammelt. Das Feedback beeinflusst wieder die Vision und die Backlogs.
  • Der Scrum-Master-Cycle verbindet ebenfalls die strategische Vision mit der Arbeit auf Teamebene. Allerdings geht es hier um kontinuierliche Verbesserung und teamübergreifende Zusammenarbeit.
So wird schon schnell deutlich, wer sich um was zu kümmern hat. Bei SAFe und PRINCE2 gibt es sehr viele Rollen. Aus Expertensicht sind die Rollen klar und sinnvoll. Aber wenn man neue Arbeitsweisen einführt, kann man nicht zu viel gleichzeitig ändern. Damit richtet man als Berater mehr Schaden an als Nutzen zu stiften.

Dem Team um Alex ist es gelungen, die verschiedenen Teile des Frameworks zu modularisieren. Das bedeutet, man kann sich einzelne Module schnappen und eins nach dem anderen umsetzen. So kann man schneller starten, und zwar mit den Modulen, die im Moment den größten Nutzen stiften. Dazu muss man eben auch den Kontext berücksichtigen.

Das Scrum @ Scale zu verschiedenen Kontexten passt, wurde im Kurs anhand von drei sehr unterschiedlichen Firmen gezeigt, einem Lieferanten des US-amerikanischen Verteidigungsministeriums, Autodesk und Spotify. Ein Reiz des Kurses bestand auch darin, die Geschichten aus diesen Firmen zu hören. Jede dieser Firmen hatte die einzelnen Module anders umgesetzt. Das zeigt, dass es immer wieder mehrere Wege gibt, die Ziele eines Moduls zu erreichen.

Wie die Arbeit über mehrere Teams hinweg verteilt und koordiniert wird, ist bei Scrum @ Scale auf 10 Module verteilt:
  • Strategic vision
  • Backlog prioritization
  • Backlog decomposition and refinement
  • Release planning
  • Team level process
  • Release management
  • Product & release feedback
  • Cross-team coordination
  • Continuous improvement and impediment removal
  • Metrics & transparency
Auf die einzelnen Module will ich jetzt nicht weiter eingehen. Wer mehr wissen möchte, sieht sich das Video an (oder fragt mich direkt). Wichtig ist: Egal, ob Sie Scrum oder etwas anderes für die Teamarbeit nutzen, Sie brauchen diese Module in jeder Organisation. Jede Firma muss sich Ziele setzen und irgendwie liefern. Jede Firma müssen einen Weg finden, um von den groben Zielen zu konkreten Wochenaufgaben zu kommen. Jede Firma muss das Feedback vom Markt einfangen und verarbeiten. Jede Firma muss sich kontinuierlich verbessern. Scrum @ Scale ist hierfür eine gute Checkliste.

Der nächste Kurs findet übrigens am 12. März 2015 in Stuttgart statt. Anmeldung bei Scrum Events (http://scrum-events.de/zertifizierungen/scrumscale/index.html).

Anmerkungen


Kommentare

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Teamleitungen gesucht

Was macht Teams erfolgreich? Kann man das lernen? Ab Herbst starten unsere Kurse für aktuelle und künftige Teamleitungen. Jetzt gibt es die Gelegenheit, den Kurs zu testen.

Wie überprüft man den aktuellen Stand einer neuen gemeinsamen Ablage?

Ihr habt in eurem Team die individuellen, unordentlichen Ablagen auf eine gemeinsame Ablage, die nach Vorgängen und Prozessen geordnet ist, umgestellt. Woher wisst ihr, ob das wirklich funktioniert? In diesem Beitrag gibt es 10 Auditfragen.

Nachschau zum Lean Coffee-Spezial "Agil einfach machen" (Interaktive Buchvorstellung)

Bei unserem Lean Coffee-Spezial Ende Mai waren wir von Lean Coffee Karlsruhe/Frankfurt Zeugen einer Buchvorstellung, doch nicht nur das – natürlich gab es auch einen nicht unbeträchtlichen Anteil an eigener Aktion, denn bei unseren Spezialterminen ist traditionell „Teilgabe“ angesagt. Das Autorenduo Christian Baron und Janick Oswald zeigte uns, was es mit „Agil einfach machen“ auf sich hat.  

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.

A simple project filing structure

Are there too many documents? But which ones are important? Project teams are drowning in information. There's no shortage of tools: emails, Slack channels, JIRA, Microsoft Teams, and Trello boards. But who can keep track of them all? A few simple rules can get a project team on track. I'll present the simplest project filing system here.