Habt ihr auch das Webinar «Tips to overcome agile scepticism» von Scrum.org am 18.1.2023 gesehen? (Wenn nicht, hier findet Ihr die Aufnahme.)
Die Teilnehmer aus allen Ecken der Welt konnten abstimmen, welcher von 10 Gründen, Agile abzulehnen, ihnen am meisten unter den Nägeln brennt und deshalb besprochen werden soll. Gewonnen hat – mit reichlich Abstand und fast einem Viertel der Stimmen - «Work on multiple projects at the same time».
Wie sieht es bei euch aus? Ist das auch in eurem Alltag eine Herausforderung, die es zu bewältigen gilt?
Lasst uns das Thema mal genauer anschauen. In diesem Artikel betrachte wir als ersten Schritt die damit verbundenen Herausforderungen und welche Konstellationen ich in der Praxis bereits erlebt habe.
Scrum und viele Projekte – die offizielle Antwort
Im Webinar war die Antwort klar: Don’t do it this way!
Laut Scrum Guide soll das Scrum Team
- nicht an Projekten, sondern an Produkten arbeiten und deshalb Produkt-Teams formen
- immer nur an einem Produkt aufs Mal arbeiten (siehe Scrum Guide)
Ist das in der Realität umsetzbar?
Projekte beinhalten meist die (Weiter-) Entwicklung eines Produkts, das liesse sich also umdefinieren – aber der zweite Punkt? Was, wenn diese Empfehlungen in der Realität nicht oder nur mit grossem Aufwand umsetzbar sind?
Nehmen wir einmal an, wir könnten doch lauter kleine Scrum-Teams bilden, die sich jeweils um ein Produkt kümmern. Der Scrum Guide macht keine Angabe über die minimale Grösse eines Teams. Damit sollte das also auch bei sehr kleinen Produkten umsetzbar sein. Oder?
Die konkreten Herausforderungen bei sehr kleinen Teams
Sporadischer Entwicklungsbedarf
Bei sehr kleinen Produkten kann der Weiterentwicklungsbedarf auch sporadisch entstehen, eine kontinuierliche Weiterentwicklung findet aber nicht statt. Teilweise werden die Produkte auch gar nicht mehr weiterentwickelt, eine gewisse Wartung ist aber noch nötig.
Asynchrone Entwicklungsdauer der Produkte
Die Entwicklungsdauern der einzelnen Produkte einer Firma sind nicht synchron. Als Beispiel werden initial je die Hälfte der verfügbaren Leute auf zwei Scrum-Teams aufgeteilt, das eine Team arbeitet an Produkt x, das andere an Produkt z. Dann endet der Weiterentwicklungsbedarf bei Produkt x, Produkt z braucht noch 4 Sprints. Produkt y ist in der Pipeline, benötigt aber weniger Leute als Produkt x. Damit wird ein Wechsel des ersten Teams von Produkt x auf Produkt z nicht das ganze Team auslasten. Eine Team-Umbildung ist aber auch nicht sinnvoll, da die Entwicklung von Produkt z noch läuft.
Und überhaupt, von Team-Umbildungen, vor allem wenn sie häufiger stattfindet oder sogar Teil des gelebten Prozesses ist, wird allgemein eher abgeraten (siehe Tuckman). Um eine effiziente Zusammenarbeit möglich zu machen, wird empfohlen, ein Team über längere Zeit stabil zu halten (siehe auch diesen Blog Beitrag bei Scrum.org).
Und wie sieht es bei einem grösseren Team aus?
Gehen wir also nun von diesem stabilen, eingespielten Scrum-Team aus. Hier gibt es wiederrum andere Herausforderungen zu meistern.
Funktionsumfang der Produkte
Die einzelnen Produkte sind zu klein, um das ganze Scrum-Team auszulasten, besonders wenn sie kontinuierlich weiterentwickelt werden. Die kontinuierliche Entwicklung aber – im Gegensatz zur Umsetzung eines bestimmten Feature-Pakets - ist wiederum das agile Ideal.
Parallele Umsetzung nicht möglich
Bei kleinen Produkten könnte man sagen, dass dann halt das ganze Team nur einen oder zwei Sprints daran arbeitet und dann zum nächsten Produkt übergeht. Nur leider gibt es immer wieder Tätigkeiten, die sich nicht beliebig parallelisieren lassen (ihr wisst ja, neun Frauen kriegen eine Schwangerschaft auch nicht in einem Monat durch).
Und nun? Auf agile Ansätze und speziell Scrum verzichten? Oder gibt es doch einen Weg beides unter einen Hut zu bringen?
Scrum und viele Produkte – Lösungsansätze in der Praxis
Der Konstellation von einem Scrum-Team, das mehrere Produkte betreut, bin ich bereits in mehreren Arbeitsstellen und Mandaten begegnet. Es wurden jeweils unterschiedliche Ansätze verfolgt, um damit umzugehen. Zwei Varianten waren:
Ein Dev-Team – mehrere POs
An einer Stelle haben sich mehrere POs ein Scrum-Team geteilt. Als ich dorthin kam, ist das Backlog übergequollen mit kaum ausgearbeiteten, teils uralten Ideen zu den verschiedensten Produkten. Jeder PO hat auf Grund der eigenen Bedürfnisse Forderungen ans Scrum-Team gestellt – genauer gesagt, gleich direkt die Tickets im Backlog erstellt - und sich dann geärgert, dass er die benötigten Features nicht rechtzeitig geliefert bekommt. Das Team war ständig daran, die einzelnen Bedürfnisse auszubalancieren und wurde regelmässig durch hoch prioritäre Incidents bei einem Produkt von der planmässigen Arbeit am anderen Produkt abgehalten.
Ein Dev-Team – ein PO und viele Stakeholder
An einer anderen Stelle war die Situation für das Team insofern besser, als es nur einen PO als Ansprechpartner hatte. Nur war hier die Problematik einfach zum PO verschoben. Er war derjenige, der sich mit enttäuschten Forderungen der Stakeholder auseinandersetzen musste. Dabei hatte er selbst nicht die letzte Entscheidungskompetenz über Priorität oder Scope der Produkte, die ihm beide von aussen vorgegeben wurden. Das überquellende Backlog und der schlechte Ruf des Scrum-Teams als unzuverlässige Lieferanten waren hier genauso vorzufinden.
Scrum und viele Produkte – also ein NoGo?
Wenn man das so liest, scheint die Entwicklung und Pflege mehrerer Produkte mit nur einem Team mit Scrum als Vorgehensmodell tatsächlich nicht zusammen zu passen. Es gibt aber doch pragmatische Möglichkeiten, wie agile Prozesse mit der parallelen Entwicklung mehrerer Produkte vereinbar sein können. Es ist dann zwar kein Scrum nach Lehrbuch mehr, aber doch so nahe daran, dass zumindest ich das gut mit meinem Gewissen vereinbaren kann.
Bevor ich Euch in einem weiteren Artikel diese Möglichkeiten vorstelle, wüsste ich gerne von Euch, wie relevant dieses Szenario «Ein Scrum Team und viele Produkte» in Eurem Alltag ist und welche Erfahrungen Ihr bereits damit gemacht habt. Ich freue mich auf Eure Kommentare!
Abonniert am besten unseren Newsletter, um die Fortsetzung nicht zu verpassen.
Wenn Ihr nicht bis zum nächsten Artikel warten möchtet, könnt Ihr auch gerne direkt mit mir Kontakt aufnehmen: Agile - SwissQ Consulting AG.