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

/1/ Jan Fischbach: Koordination von vielen Teams am Beispiel vom Scaled Agile Framework (SAFe) und Scrum, Teamworkblog, erschienen am 04. Februar 2013, abrufbar unter http://www.teamworkblog.de/2013/02/koordination-von-vielen-teams-am.html

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.

Wenn Leisten Leistung kostet

Immer. Immer "on". Immer mehr. Immer schneller. Und natürlich: Immer besser. Das ist die Welt, in der wir heute leben. Eine Welt der Dauerleistung. Und die hat ihren Preis: Wir werden schwächer. Sofern wir nicht die Grundlagen guten (Selbst-)Managements beherzigen und Pausen machen. Also zur richten Zeit das wirklich Wichtige tun.

Klartext statt Konsens - wie Meetings wieder was bewirken

Bessere Kommunikation ist Lippenstift fürs Protokoll. Kennst Du das: Das Meeting läuft, Energie ist da, der Knoten platzt - und jemand sagt: "Wir müssen besser kommunizieren!" Alle nicken. Jemand schreibt's auf. Und was passiert damit? Nichts . Warum? Weil "besser kommunizieren" keine Handlung ist. Genauso wenig wie: "mehr Verantwortung übernehmen", "offener Feedback geben", "konstruktiver diskutieren", "proaktiver sein", "mehr miteinander reden", "transparenter werden", "Verständnis füreinander zeigen". Alles klingt gut. Aber ohne Klartext bleibt’s ein Vorschlag - nett im Protokoll, aber ohne Effekt auf den nächsten Arbeitstag. Kein konkreter Schritt, keine sichtbare Veränderung. Keiner der's macht. Es ist eine gute Absicht ohne Konsequenz. Wir haben kein Problem Verbesserungen zu identifizieren. Die wahre Herausforderung ist selten das Finden von Verbesserungen. Es ist das Konkretisie...

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.

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

Dateien teilen in Teams - arbeiten in gemeinsamen Dateien

Arbeitest du mit Kolleginnen und Kollegen an gemeinsamen Dateien, die in Teams, aus OneDrive oder SharePoint liegen? Hast du dabei vielleicht kein ganz gutes Gefühl, weil du dir nicht so ganz sicher bist, was mit der Datei tatsächlich passiert? Wer darauf Zugriff hat und wie du das sehen kannst? Dann lies weiter, hier stelle ich dir die wichtigsten Fakten und Einstellungen kurz und knapp vor.

From False Starts to Precision Landing: The Evolution of Requirements Management

Requirements management originated in U.S. rocket programs between 1945 and 1970. A small management trick contributed to the success of the Apollo program.

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.

Wie baut man einen Aktenplan auf?

Ein Aktenplan beschreibt, an welcher Stelle genau ein Team seine Dokumente und Nachrichten ablegt. Aber wie baut man den genau auf?

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.

Das Teamwork-Blog

Dieses Blog durchsuchen