10 Tipps zum Skalieren

Wir werden immer wieder gefragt, wie man sinnvoll skaliert, also mit mehr als einem Team arbeitet. Soll man da gleich elektronische Taskboards nutzen, braucht es einen Chief Product Owner und vieles mehr. Hier zehn kleine Tipps - sie können euch dabei helfen, erfolgreicher mit vielen Teams zu arbeiten.

  1. Synchronisiert die Sprints. Wenn Teams zusammenarbeiten müssen, also voneinander abhängig sind, dann hat es sich bewährt, die Sprints zu synchronisieren. Teams, die nichts miteinander zu tun haben, brauchen bei dieser Synchronisation nicht mitzumachen.
  2. Infrastruktur. Wichtiger als alle Prozesse ist die entsprechende Infrastruktur. Zum Beispiel müsst ihr in der Lage sein, ständig zu integrieren. Stichwort "Continuous Delivery". Wenn ihr diese Infrastruktur noch nicht habt, dann wird das Ende des Sprints oder der Kadenz zum Integrationszeitpunkt. Mindestens einmal im Sprint muss alles zusammenlaufen.
  3. Defects First. Immer zuerst alle Defects lösen und wieder integrieren. Erst an neuen Features arbeiten, wenn die Defects gelöst sind. Am besten täglich dafür sorgen, dass Fehler behoben werden.
  4. Dann kümmert man sich um die Integrations-Themen - hier liegt die Stärke des Scrum of Scrums. Identifiziert täglich, wo es Probleme beim Zusammenbringen der Applikation gibt. Gebt euch nicht damit zufrieden, dass es möglicherweise später schon funktionieren wird. Löst jedes dieser Probleme sofort. Erst dann macht man weiter.
  5. Infrastruktur vor Features. Davon abgesehen, dass jedes Team immer ein neues Feature, eine neue User Story pro Sprint liefern sollte - entwickelt eure Instrastruktur zuerst weiter. Ständig. Updates der Server, der Test-Systeme, neue Interfaces nutzen, immer zuerst.
  6. Erst dann werden neue Funktionalitäten entwickelt. Also etwas Neues wird immer erst dann wieder in die Applikation eingebaut, wenn sie wirklich funktioniert und alle Bedingungen bereit sind.
  7. Visualisiert die Arbeit der Product Owner. Sie müssen sich auch einmal als Product Owner-Team vor einem Taskboard treffen und ihre Arbeit auf diese Weise transparent machen.
  8. Der Chief Product Owner entscheidet nur selten über die Reihenfolge: Seine Aufgabe ist es dafür zu sorgen, dass er die besten Product Owner in seinem Team hat. Er sorgt dafür, dass jeder ein Backlog hat, das zum Gesamtprodukt passt. Er identifiziert die notwendigen Skills und arbeitet ständig mit seinem Product Owner-Team daran, dass es immer möglichst viel Wert liefert.
  9. Entwickelt mit den Architekten oder Lead-Entwicklern ein Konzept, so dass die unterschiedlichen Teams möglichst entkoppelt voneinander arbeiten können. Die Architektur sollte vorgeben, wie zusammengearbeitet werden kann. Nicht umgekehrt.
  10. Delegation der Verantwortung dorthin wo die Information ist. Arbeitet hart daran, dass die Teams selbst Entscheidungen treffen und sie treffen können. Oft fehlt es tatsächlich an den entsprechenden Kenntnissen. Entwickelt erst die Kenntnisse und dann kommt die Selbstorganisation von selbst.

Diese Tipps haben uns in den letzten Jahren geholfen, in großen Teams erfolgreich zu sein. Sie dienen uns als Anhaltspunkt, worauf wir achten müssen. Lösen können die Regeln für sich allein nichts.Wer mehr über große verteilte Teams wissen will - wir bieten dazu ein Training an: Scrum International bringt viele neue Ideen und Arbeitsweisen.

Skalierung
bgloger-redakteur
September 4, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen