Viele Produkte, ein Team – Stiefkind der Skalierung

Wenn sich ein Unternehmen mit dem Thema Scrum auseinandersetzt, kommt früher oder später die Frage auf, wie es denn mit der Skalierung aussieht. Häufig wird jedoch recht undifferenziert von Skalierung gesprochen und nur wenige wissen genau, was sie eigentlich meinen. Es gibt aber eine einfache Übersicht, die Christoph auch in einem unserer letzten Meetups zum Thema „SKALIERUNG! SKALIERUNG! SKALIERUNG!“ gezeigt hat. Diese macht klar, in welchem Kontext man sich bewegt und was sinnvollerweise zu tun ist.

Skalierung

(c) Christoph Schmiedinger, Matthias Wolf-Dietrich

Für die Übersicht ziehe ich einen Graphen mit zwei Achsen auf. Die vertikale Achse zeigt die Anzahl der Produkte in einem Unternehmen oder einer Abteilung, auf die horizontale Achse trage ich Anzahl der Teams auf, die zur Verfügung stehen bzw. welche die Arbeit erledigen. Für den 1. Quadranten gilt es, ein Hochleistungsteam zu formen, dass liefert und regelmäßig reflektiert – zum Beispiel mit Scrum. In den Quadranten 2 und 4 müssen sich viele Teams um ein oder mehrere Produkte kümmern. Diese Situationen haben die meisten Menschen im Kopf, wenn sie über Skalierung sprechen. Ich konzentriere mich hier nun auf den linken oberen Quadraten 3: viele Produkte – ein Team. Das ist eine Situation, die bei der Skalierung gerne vergessen wird und dementsprechend bekommen solche Teams wenig Aufmerksamkeit von Führungskräften und/oder Coaches.

Das Problem des fehlenden Fokus

Eine typische Ausprägung davon sind Entwicklungsteams, die neue Varianten bestehender Produkte entwickeln. Auch in etablierten Produktbereichen mit relativ langlebigen Produkten, die sich um Seriensupport kümmern oder Verantwortung für das Lifecycle Management haben, ist diese Situation ganz alltäglich. Meist sind auch die berüchtigten „Cash Cows“ betroffen. Aber mit welchen Schwierigkeiten muss ein Team in dieser Konstellation kämpfen? Das größte Problem ist der fehlende Fokus und die damit verbundenen langen Bearbeitungszeiten. Ein großer Effizienzkiller ist, dass die Aufmerksamkeit häufig von einem Produkt zum anderen wechselt und die Wahrscheinlichkeit höher ist, unterbrochen oder gestört zu werden. Das zwingt die Teammitglieder dazu, sich immer und immer wieder neu in die unterschiedlichen Themen reinzudenken. Kaum hat es sich in eine Aufgabe eingefunden, muss sich das Teammitglied aus verschiedenen Gründen auf das nächste Thema stürzen.
Sicher kennen Sie auch die schier erdrückende Last einer langen und stetig wachsenden To-Do-Liste. Wie gelähmt sitzt man vor der Menge an Aufgaben und weiß gar nicht, wo man anfangen soll. Das Resultat: Das Team ist überlastet, die Wahrscheinlichkeit von Fehlern steigt und die Bearbeitungszeiten steigen noch weiter an. Ein häufiges Symptom ist das ständige Arbeiten im Feuerwehrmodus. Kaum hat das Team ein Feuer gelöscht, flammt gleich das nächste Glutnest auf. Was soll man hier tun? Die folgenden fünf Schritte verhelfen zu mehr Klarheit.

  1. Priorisierung nach der Cost of Delay. Der mögliche Durchsatz des Teams, also die Menge der möglichen Lieferungen, ist die einschränkende Größe. Da es üblicherweise deutlich mehr Opportunitäten als vorhandene freie Zeit gibt, gilt es hier mehr noch als sonst, nur an den wichtigsten, sprich wirtschaftlich wertvollsten Themen zu arbeiten. Die Bewertung kann nach den Verzögerungskosten oder „Cost of Delay“ erfolgen: Wie hoch sind die Kosten bzw. der entgangene Gewinn, wenn ein Thema später – oder gar nicht – durchgeführt wird. Je höher diese Verzögerungskosten sind, desto eher sollte das Team an diesem Produkt arbeiten. Eine weitere Bewertungsmöglichkeit ist der Return on Investment, bei dem aber häufig die zeitliche Komponente ignoriert wird.
  2. Nein sagen. Da der Durchsatz des Teams durch den Engpass im Team bestimmt wird, muss dieser identifiziert und möglichst gut ausgenutzt werden, gleichzeitig aber auch möglichst gut beschützt werden. Er soll also nicht von anderen Teammitgliedern, anderen Teams oder Abteilungen mit neuen Aufgaben verstopft werden (https://www.borisgloger.com/blog//2017/01/19/the-malicious-behavior-of-non-constraints/). Um sicherzustellen, dass das Team möglichst zielgerichtet am wertvollsten arbeiten kann, müssen Kontextwechsel so gut es geht vermieden werden. Für den Product Owner heißt das: Nein sagen. Konsequent und immer wieder. Ideen für neue tolle Produkte, die unbedingt JETZT umgesetzt werden müssen, gibt es wie Sand am Meer. Die Herausforderung ist, keine Produkte oder Aufgaben mit geringerem Wert zuzulassen.
  3. Fehler sofort beheben. Es ist extrem wichtig, keine halbfertigen Produkte oder Aufgaben zuzulassen. Der fast schon fanatische Fokus auf Qualität stellt sicher, dass einen die Fehler später nicht einholen. Das erschwert das Jonglieren mit vielen Themen oder macht es sogar unmöglich. Das Schlimmste was passieren kann: Ein Thema, das eigentlich schon erledigt war, kommt wieder und muss gelöst werden. Schnell ertrinkt man in Nacharbeit und Fehlerbehebungen. Wenn man ohnehin schon Dutzende Themen in der Luft halten muss, ist das nicht angenehm und bricht einem Team schnell das Genick.
  4. Definition of Done. In diesem Umfeld bietet es sich an, mit sehr kurzen Sprints oder flussbasierten Systemen wie Kanban zu arbeiten. Um die Qualität möglichst hoch zu halten, braucht es eine gemeinsame Definition of Done (DoD), die auch durch das gesamte Team eingehalten und eingefordert wird. Das beinhaltet auch den ScrumMaster und den Product Owner. Regelmäßige Refinements und grundsätzlich moderne Arbeitspraktiken wie Mob Working unterstützen hier noch weiter.
  5. Portfoliomanagement. Um sicherzustellen, dass die zahlreichen Themen nicht das Team überschwemmen, ist eine Form von Portfoliomanagement sinnvoll. Der einfachste Weg ist es, das Portfolio zu visualisieren und damit zum regelmäßigen Gegenstand der Gespräche von Product Owner, Entwicklungsteam und der anderen Stakeholder zu machen. Wichtig ist weiter, dass regelmäßig und zeitnah Entscheidungen getroffen werden.

In den nächsten Artikeln dieser kurzen Serie werde ich die restlichen Quadranten und das empfohlene Vorgehen beschreiben.

Foto: CC0 Creative Commons – pixabay, pexels

Geschrieben von

Matthias Wolf-Dietrich Matthias Wolf-Dietrich

TEILE DIESEN BEITRAG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.