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://blog.borisgloger.com/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

borisgloger Meetup: Skalierung! Skalierung! Skalierung!

Mitte Juni hatte ich die tolle Gelegenheit, einen Abend unserer Meetup-Reihe in München zu gestalten. Mein Kollege Matthias Wolf-Dietrich hatte als Veranstalter die letzten Meetups bereits genutzt, um nicht nur nach Feedback, sondern auch nach Themenwünschen der Teilnehmer zu fragen. Platz 1 konnte dabei einem Thema niemand streitig machen: Skalierung! Diesen eindeutigen Wunsch konnten wir nicht ignorieren, daher habe ich mir die Zeit genommen, einen neuen Vortrag zu konzipieren, der auf unseren aktuellen Erfahrungen, der Arbeit in der Community mit anderen Agile Coaches und natürlich den Ideen von Boris aufbaut. Herausgekommen sind ein 50-minütiger Lightning Talk und eine spannende Diskussion mit reger Beteiligung des Publikums. Den Vortrag und das entsprechende Slide-Deck wollen wir euch natürlich nicht vorenthalten!
Wenn ihr auch zu einem der nächsten Meetups kommen wollt, meldet euch gerne über die borisgloger Agile Experience Camp Seite auf Meetup.com an. Dort seht ihr auch eine Übersicht aller Standorte und Termine.

Skalierte agile Organisation: Das übergreifende Arbeitsmodell als Führungsinstrument

Im klassischen Führungsparadigma soll eine Führungskraft vermitteln, was wie zu tun ist, um ein definiertes Ziel zu erreichen. Damit verbunden ist die Kontrolle: Erledigen meine Mitarbeiter die vorgegebenen Aufgaben? Demgegenüber liegt dem agilen Führungsverständnis die Annahme zugrunde, dass sich die Organisation automatisch in die „richtige“ Richtung bewegen wird, wenn das Management durch den Sinn – die Vision, das „Warum“ – eine grobe Richtung vermittelt und die Rahmenbedingungen (die Constraints) vorgibt.
Obwohl die Forderung nach einer Vision banal klingt, haben Unternehmenslenker große Mühe, sich auf dieses neue Führungsverständnis einzulassen. Bereits die Definition einer Vision ist eine Herausforderung. Die Frage, weshalb das „Warum“ so wichtig ist (allen voran Simon Sinek) und wie eine Vision entsteht („Geheimnisse einer wirklich guten Vision“) wurde in den entsprechenden Diskussionen hinlänglich bearbeitet. Anders sieht es beim Setzen der Rahmenbedingungen aus: Wie gelingt es dem Management, einen Rahmen vorzugeben, innerhalb dessen die Organisation die Lieferfähigkeit erhöhen und gleichzeitig ein hohes Maß an Transparenz schaffen kann?
Die erste Hürde ist, sich von einem nach wie vor weit verbreiteten Irrglauben zu verabschieden: Agilität bedeutet nicht, Teams ohne Kontrolle und Vorgaben einfach machen zu lassen, in der Hoffnung, es werde schon etwas Gutes dabei herauskommen (Video: Agilität – das Managen von Unsicherheiten). Sicherlich gibt es hoch performante agile Teams, bei denen es genügt, eine Vision zu kommunizieren. Gerade beim Change in einer klassischen Organisation ist es jedoch umso wichtiger, neben einer griffigen Vision auch klare Rahmenbedingungen zu definieren. Demnach bedeutet Agilität nicht, die Freiheit zu haben alles zu tun, sondern vielmehr, die Freiheit zu haben, sich innerhalb der gesetzten Rahmenbedingungen in Bezug auf die Vision selbst zu organisieren.
Der Entwurf eines Arbeitsmodells ist ein bewährtes Mittel, um Teams in die Selbstorganisation zu führen.

Was ist ein Arbeitsmodell?

Ein Arbeitsmodell an sich ist nicht mehr als die Beschreibung der in einem Unternehmen gelebten Scrum-Rollen, -Meetings und -Artefakte. Scrum selbst gibt diese zwar vor, jedes Unternehmen lebt die Rollen, deren Skalierung, die Meetings und Artefakte allerdings anders. Meetings finden in unterschiedlichen Taktungen mit unterschiedlichen Teilnehmerkreisen und Formaten statt. Während in dem einen Unternehmen als Artefakt lediglich ein Taskboard existiert, schwören andere Unternehmen auf einen Releaseplan und ein übergreifendes Unternehmensbacklog, während andere pflichtbewusst alle Artefakte anwenden, die Scrum definiert.
Ein übergreifendes Arbeitsmodell ist die Sammlung und Konsolidierung der bestehenden Rollen, Meetings und Artefakte, um daraus Best Practices abzuleiten. Das Arbeitsmodell ist ein lebendes und somit lernendes Artefakt, das veränder- und anpassbar ist und auf neue Erkenntnisse im Sinne einer verbesserten Zusammenarbeit reagiert und diese abbildet.
Unsere Erfahrung ist, dass idealerweise ein Scrum-of-ScrumMaster die Verantwortung für die Erstellung des Arbeitsmodells übernimmt. Er erhält durch die Arbeitsmodelle der einzelnen Teams, die von seinen ScrumMastern erstellt werden, einen Einblick in die Arbeitsweise der Teams und ist somit in der Lage, daraus ein übergeordnetes Arbeitsmodell zu erstellen.

Wozu dient das Arbeitsmodell?

Das Arbeitsmodell unterstützt dabei, Transparenz, Einheitlichkeit und eine Meetingkultur zu schaffen sowie den Prozessframework kontinuierlich zu optimieren.

Gleichzeitig ist das Arbeitsmodell ein lebendes Dokument, das auf Veränderungen und neue Erkenntnisse in der Arbeitsorganisation reagieren kann und diese abbildet. Es dient den ScrumMastern zur Reflexion und ist somit selbst Gegenstand der kontinuierlichen Verbesserung.
Das Arbeitsmodell kann also zu einem wichtigen Instrument des Change werden, indem es Orientierung gibt und die übergreifende Zusammenarbeit der ScrumMaster fördert. Es bietet eine Alternative zu Hierarchien, da es dem Unternehmen eine Arbeitsorganisation auf Teamebene anbietet, die nicht auf der Ableitung von Führungsebenen beruht.
Im Idealfall erzeugt ein Arbeitsmodell einen Rhythmus, der das iterative Arbeiten unterstützt und eine Art Taktung für das Unternehmen erzeugt.

Foto: CC0 Creative Commons – pixabay, Michael Gaida

Interview mit Boris Gloger: „Die großen agilen Transitionen haben immer nur dann funktioniert, wenn das Management verzweifelt war.“

Vor Kurzem hat mich die Wirtschaftspsychologiestudentin Laura Hitti zum Thema Change-Prozesse in klassischen Organisationen interviewt. Das Gespräch möchte ich euch nicht vorenthalten. Hier die gekürzte Fassung.
Laura Hitti: Herr Gloger, welche Aspekte aus Ihrer Praxis erachten Sie als besonders wichtig für Skalierungsvorhaben?
Boris Gloger: Das läuft immer auf dasselbe hinaus. Die Grundaussage ist: Man muss anfangen, Agilität einzuführen und dafür sorgen, dass der Change auch erfolgreich ist. Dadurch entsteht oft ein großer Druck bei uns – im Unternehmen entsteht dieser aber schon früher. Eigentlich ist dieser Druck fundamental. Es ist Fakt: Die großen agilen Transitionen haben nur dann funktioniert, wenn das Management verzweifelt war und gesagt hat: „Wir machen alles, was notwendig ist, damit es irgendwie funktioniert!“ Im Sinne von Kotter: Es gab einen „Sense of Urgency“.
Laura Hitti: Agilität soll also einerseits als Methode eingeführt werden und sich andererseits sofort als erfolgreich und richtig beweisen. Dabei muss das Management vorher den Druck erkennen, der aus der Umwelt resultiert. Richtig?
Boris Gloger: Genau! Das ist das Problem bei großen agilen Projekten in nicht-agilen Organisationen. Wenn Sie heute mit 300 Leuten etwas machen, ist das überhaupt kein Problem. Da ist das schon Standard! Die haben diesen Need häufig nicht. In einer klassischen Organisation gibt es verschiedenste Baustellen. Und die heftigste Baustelle ist, dass Sie genau jene Manager brauchen, die sich erst absichern müssen, damit sie etwas ändern dürfen.
Laura Hitti: Stichwort „Empowerment“?
Boris Gloger: Nein, Empowerment ist etwas anderes. Hier geht es darum, dass die Organisation zulässt, dass Sie Prozesse einreißen, die es schon immer gab. Dass Sie die klassischen Prozesse nicht einhalten müssen. Dass Sie die Erlaubnis bekommen, zum Einkauf zu gehen und zu sagen: „Ich brauch das Zeug jetzt trotzdem! Und nicht erst in sechs Wochen!“
Laura Hitti: Gibt es konkrete Indikatoren, die zeigen, dass das Management verstanden hat und das nötige Rückgrat besitzt, um den Change durchzusetzen?
Boris Gloger: Indikatoren im Vorfeld gibt es meiner Meinung nach nicht. Es gibt nur Manager, die im Laufe der Transition erkennen, worauf es ankommt. Nämlich dass sie aus ihrer Linienfunktion heraus die Probleme wegarbeiten müssen. In jeder agilen Transition – oder in jedem großen agilen Projekt – stoßen Sie immer auf Schwierigkeiten in der Organisation. Das ist normal. Wenn das nicht so wäre, würde die Organisation ja tadellos funktionieren. Sie brauchen deshalb Menschen in der Organisation, die entscheiden können und sagen: „Okay, dann tun wir jetzt etwas!“
Laura Hitti: Hat das aus Ihrer Sicht auch mit einer Veränderung der Managementrolle zu tun?
Boris Gloger: Ja und nein. Theoretisch könnten die Manager in ihrer klassischen Linienfunktion den Change einleiten. Sie haben die Rechte! Jetzt ist es aber in der Regel so, dass das Management die Entscheidung nach oben abgibt. Also der Teamleiter gibt an den Gruppenleiter ab, der Gruppenleiter wiederum gibt an den Abteilungsleiter ab, und dieser gibt an ein Steering-Committee oder Gremium ab. Weil der Manager – also derjenige auf dem Level, der entscheiden müsste – denkt, nicht entscheiden zu können, oder er darf es tatsächlich nicht. Eventuell hat er nicht die Budgetkompetenz oder muss nochmal jemanden fragen. So oder so: Verantwortung wird in klassisch geführten Unternehmen häufig nach oben delegiert – vor allem wenn es um Anforderungen geht, die sich so noch nie gestellt haben. Die letztendliche Konsequenz hat Laloux in „Reinventing Organizations“ beschrieben. Er schreibt, dass die ganze Agilität immer dann zusammenbrechen wird, wenn es der CEO nicht will. Und wenn es der CEO will, aber das Board nicht, dann wird es auch zusammenbrechen. Bei großen Geschichten brauchen Sie ein Management, das ein Backup gibt und die Probleme wirklich aus dem Weg schafft.
Und der zweite Faktor ist: Erfahrung erzeugen. Was meine ich damit? Sie führen irgendein Framework ein, zum Beispiel Scrum, und dann sagt das Management in der Regel: „Ja, macht halt Scrum!“ So, na gut! Aber die Manager selbst arbeiten nicht mit Scrum und sind viel zu weit weg vom Geschehen.
Laura Hitti: Das gemeinsame Sitzen an einem Ort, auf einem Stockwerk. Ist das also ein weiterer Erfolgsfaktor?
Boris Gloger: Das ist einer der Beschleuniger, ja. Der wirkliche Erfolgsfaktor ist, dass sich die Manager tatsächlich selbst der Agilität aussetzen. Am besten machen sie es selbst. Das Zweitbeste ist, dass sie mitkriegen, wie die anderen arbeiten – also wirklich mitkriegen. Das heißt hinfahren, sich die Meetings anschauen – einfach dabei sein. Sie müssen dann zulassen, dass die Menschen es anders machen.
Der dritte Erfolgsfaktor, und das ist meiner Meinung nach der wichtigste: Sie brauchen ScrumMaster, die das durchsetzen. Ohne Führung funktioniert es nicht! Wenn der ScrumMaster oder der Agile Coach nicht als Führungskraft gesehen wird, wenn er sich nicht als Change Agent etablieren kann oder nicht den Mut hat, Dinge zu verändern, dann funktioniert es gar nicht. Dann haben Sie zwar wunderschöne, herrlich gemachte Task Boards und Scrum Boards und Meetings, aber das Team liefert trotzdem nicht.
Der vierte Erfolgsfaktor heißt aus meiner Sicht: tatsächlich liefern! Sie können LeSS oder auch SAFe benutzen und das Framework da reinschrauben. Wenn Sie nicht alle zwei Wochen oder alle vier Wochen fix und fertiges Zeug liefern, dann haben Sie die schönsten Frameworks der Welt benutzt und es funktioniert trotzdem nicht.
Laura Hitti: Das heißt: So weit liefern, dass der Kunde sich hinsetzen kann und seine Begeisterung ihm aus allen Poren strahlt?
Boris Gloger: Das ist zwar nett, aber das braucht es gar nicht. Am Anfang würde es reichen, dass die Manager, also die, die es letztendlich ja bezahlen, sehen: Die Teams kommen voran. Das erzeugt einen positiven Schneeballeffekt: Sie sehen, dass etwas vorangeht, durch das Vorankommen entsteht Vertrauen – die Teams dürfen mehr! Dadurch, dass die Manager es schaffen, den Teams die Probleme aus dem Weg zu räumen, bekommen die Teams und die Mitarbeiter wiederum Vertrauen in das Management. Und das ist ein positiver, sich selbst verstärkender Prozess, bis die gesamte Organisation merkt: Es funktioniert! Umgekehrt kann es genauso negativ verstärkt werden: Wenn die Teams merken, dass das Management sie nicht ernst nimmt.

Skalierte Hardware-Entwicklung – Interview mit Matthias Wolf

 
Foto_Matthias_WolfMatthias ist einer unserer Hardware-Spezialisten und unterstützt Unternehmen bei großen internationalen Projekten zum agilen Arbeiten. Besonders wichtig ist ihm dabei, dass Entwickler viel Zeit mit dem Produkt verbringen dürfen und durch häufiges Prototyping wieder mehr Freude an ihrer Arbeit haben.
 
BG: Matthias, inwiefern sind Hardwareprojekte anders als Softwareprojekte? Worauf musst du als Coach besonders achten?
Matthias: Zunächst einmal gibt es mehr mentale Hürden zu überwinden. Oft werden wir mit der Ansicht konfrontiert, dass “das hier nicht geht” und Scrum überhaupt nur in der Software-Entwicklung funktioniere. Dabei waren die meisten frühen agilen Projekte vor allem Hardware-Entwicklungen: Kameras, Kopierer, sogar Autos. Wichtig ist, nicht zu versuchen, die bekannten Praktiken und Vorgehen aus der Software-Entwicklung eins zu eins auf die Hardware-Entwicklung zu übertragen, sondern vielmehr die dahinter stehenden Prinzipien zu beachten. Im Kern geht es doch darum, dass ein Team Ergebnisse liefert und sich und die eigene Arbeit ständig hinterfragt. Das ist in der Hardware genauso sinnvoll und wichtig.
Eine andere Besonderheit ist, dass das “Bauen” tendenziell immer noch länger dauert als bei Software – da ist es oft ja nur mehr ein Knopfdruck. Und auch wenn mit Werkzeugen, wie 3D-Druckern, Laser Cuttern und CNC-Fräsen, die Bauzeiten immer weiter reduziert werden können, ist man von “Sekunden” noch ein Stück entfernt. Feedback dauert dadurch einfach länger. Aus diesem Grund ist es umso wichtiger, dass man sich auf die aktuell wichtigsten Themen fokussiert und offene Fragen möglichst schnell durch kleine, schnelle Prototypen und die damit gewonnenen Daten beantwortet. Oft reicht dafür aber auch eine Skizze, eine Simulation, ein CAD-Modell oder ein Aufbau aus LEGO oder Styropor.
Die Entwickler müssen viele der Möglichkeiten auch erst kennenlernen, da die meisten Tools gerade erst entwickelt werden. Continuous Deployment war in der Software-Entwicklung vor einigen Jahren völlig undenkbar, heute ist das ganz normal – auch wenn es noch nicht jeder nutzt. Ähnlich wird es in der Hardware-Entwicklung sein. Ein Beispiel: Ein Werkzeug, das ich auch nutze, ist https://iotify.io/ Mit virtuellen Sensoren und Netzwerken kann man jetzt schon Internet of Things-Produkte in kürzester Zeit entwickeln und dann schnell Realität werden lassen. Da tut sich in den nächsten Jahren noch einiges.
 
BG: Wie siehst du das: Wie hilfreich ist Scrum auch bei großen Projekten und weshalb? Welche Vorteile hast du mit Scrum gesehen?
Matthias: Gemeinsame Planungen und Reviews über das gesamte Projekt rufen bei Entwicklern immer viel Begeisterung hervor. Endlich haben sie einen Gesamtüberblick und sehen, was die anderen Teams machen. Und sie erkennen, warum sie tun, was sie tun. Leider erkenne ich auch die Tendenz, dass Manager diese gemeinsamen Termine als Zeitverschwendung betrachten.
Gerade zu Beginn wird das Projektziel hinterfragt: Warum machen wir das Projekt? Was wollen wir erreichen? Warum tun wir das überhaupt? Eine Frage, die ich immer wieder stelle: Muss das Projekt überhaupt so groß sein? Kann man sich nicht auf bestimmte Funktionalitäten oder Märkte konzentrieren und so einiges an Komplexität aus dem Projekt nehmen? Leider ist es oft noch so, dass man immer alles will und alles gleichzeitig. Damit macht man sich und den Entwicklern das Leben aber unnötig schwer. Große Projekte benötigen mehr Menschen und das erhöht den Kommunikationsbedarf. Strukturierte Kommunikation über das gesamte Projekt hinweg wird umso wichtiger. Meistens scheitern Projekte nicht an technischen Problemen, sondern an mangelnder Kommunikation oder der Erkenntnis, dass der Kunde das Produkt gar nicht braucht. Gerade da sind Scrum oder Vorgehen wie Lean Startup besonders hilfreich.
 
BG: Du bist in der Lean Startup Community aktiv. Was macht diese Community aus? Welche Ideen heckt ihr da so aus?
Matthias: Generell ist die Bereitschaft, Risiken einzugehen und Fehler zu machen, deutlich höher. Ein Fehler ist keine Schande, sondern eine wertvolle Erfahrung auf dem Weg zu einem erfolgreichen Produkt. Gleichzeitig versucht man aber auch, durch kluges Vorgehen das Risiko zu reduzieren. Oft kann man nämlich Annahmen schon im Vorfeld sehr einfach überprüfen und verhindern, dass man Zeit in sinnlose Entwicklungen steckt. Es ist spannend zu sehen, mit wie viel Energie und Einfallsreichtum die Leute an teilweise verrückte Ideen rangehen. Genauso schnell sehen sie aber auch ein, wenn etwas nicht funktioniert und ein Projekt eingestellt werden muss. Diese Bereitschaft, auch mal zu sagen “Das war jetzt nix!”, ohne gleich einen Schuldigen zu suchen, wünsche ich mir auch in etablierten Unternehmen.
 
BG: Gibt es eine Besonderheit, die man bei agilen Hardware-Projekten im skalierten Umfeld beachten muss?
Matthias: Interdisziplinäre Teams, die sich häufig am Gesamtprodukt treffen, sind besonders wichtig; die Idee ist aber auch schwerer zu vermitteln. Die Distanz zwischen einem Konstrukteur und einem Firmware-Entwickler, vor allem in der Geisteshaltung, ist oft größer als zwischen einem Frontend- und einem Backend-Entwickler. Deshalb ist räumliche Nähe durch gemeinsame Projekträume und Büros sehr hilfreich.
Die Modularisierung des Produkts und die Standardisierung von Komponenten hilft, schnelle Iterationen zu ermöglichen. Dafür ist es auch notwendig, Schnittstellen abzustimmen, gegen die entwickelt werden kann. So kann in einem Sprint ein Modul weiterentwickelt werden, ohne das Gesamtprodukt neu erfinden zu müssen. Oder mehrere Teams können unabhängig an mehreren Modulen arbeiten. Nach wie vor sind Änderungen an der Hardware immer noch teuerer als an Software. Wenn man dem Produktteam jedoch verständlich machen kann, dass Änderungen nicht schlecht sind und man sie am besten von Anfang an vorsieht, steht einem erfolgreichen Produkt wenig im Weg.
 
BG: Lieber Matthias, ich danke dir für unser Gespräch. Ich wünsche dir weiterhin viel Erfolg für deine Projekte.
 
Buchcover Scrum-Think bigWer mehr über das Skalieren erfahren möchte, dem empfehle ich mein neues Buch: “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”.
 
 

Scrum Think b!g – skalierte Hardware Projekte

 
 
Wer über skalierte Produktentwicklung, Scaled Agile, SAFe, Nexus usw. schreiben will, der kommt nicht umhin, sich damit auseinanderzusetzen, dass die wirklich interessanten Skalierungs-Projekte die sind, die sich mit Hardware befassen. Während des Schreibens von “Scrum Think b!g – Scrum für große Projekte, viele Teams und viele Kulturen” wurde mir klar, wie schwer es ist, in einem Buch alles abzudecken – also nicht nur das Skalieren großer Softwareentwicklungsprojekte, sondern eben auch jenes von Hardware-Projekten.
Unsere ersten Erfahrungen mit wirklich großen skalierten Hardware-Projekten haben wir in der Entwicklung von medizintechnischen Geräten gemacht. Dabei mussten viele unterschiedliche Disziplinen gemeinsam liefern. Wir hatten es hier nicht mit dem Problem zu tun, dass einige Dutzend oder Hunderte von Softwareentwicklern miteinander arbeiten mussten. Es war viel komplexer: Ein Elektroingenieur ist nun mal kein Biologe und spricht eine andere Sprache als dieser. Das beteiligte Marketing versteht oft nur Bahnhof von dem, was die Wissenschaftler in ihren Labors wirklich tun und diese wiederum verstehen nicht (oder wollen nicht verstehen), dass sie sich an die zeitlichen Vorgaben der Investoren halten müssen … sonst geht das Geld irgendwann zur Neige. Aber neben diesen kulturellen Aspekten der Skalierung gibt es bei großen und verteilten Projekten noch ganz praktische Probleme: Da gibt es unzählige Abhängigkeiten zu Lieferanten und das Problem, dass die Planung für die Hardware gemacht wurde, als die Wissenschaftler noch gar nicht wussten, was sie wirklich brauchen. Klar sind das nur Prototypen, doch auch die kosten Geld, und sie umzubauen ist nicht wirklich einfach.
Wie kann da Scrum oder eine agile Vorgehensweise helfen? Zunächst: Der Framework zwingt alle Beteiligten dazu, transparent zu werden. Die Kommunikation zwischen den einzelnen Silos kommt durch die Forderung “nach einer Iteration muss etwas Lieferbares da sein” in die Gänge. Häufig kommt es am Ende der einen oder anderen Iteration dazu, dass das geforderte Ergebnis doch nicht eingetreten ist. Das ist dann zwar oft für das Management sehr betrüblich, denn oft liegt es gar nicht an dem Team, dass da sein Bestes gibt, sondern an den organisatorischen Rahmenprozesse. Dann muss das Management in irgendeiner Weise reagieren – und das ist immer unbequem.
 
Buchcover Scrum-Think bigWürde mich freuen, wenn ich euch auf mein Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” neugierig gemacht habe.

Video: Der Open Space – eine Grundlage

Die Digitalisierung erzwingt die Umstrukturierung vieler Unternehmen. Viele Manager suchen Anhaltspunkte dafür, wie sie das Unternehmen für diese Herausforderung aufstellen müssen. Schnell reagiert die agile Community und baut Blaupausen: Nexus, LeSS, SAFe® und wie sie alle heißen. Ich finde, das sind hilflose Versuche, Selbstorganisation zu verordnen. Dabei werden die Prinzipien der Selbstorganisation sträflich verletzt und wir fallen wieder in Command and Control zurück. Doch es gibt vielleicht eine Blaupause dazu, wie sich eine Organisation „agil und mithilfe von Freiwilligkeit“ organisieren kann. Buurtzorg hat es vorgemacht.
In diesem Video erkläre ich, wie die Open Space Technologie funktioniert. Wir müssen uns mit dieser Organisationsform auseinandersetzen, um zu verstehen, wie sich Organisationen aufstellen müssen.
Viel Spaß beim Anschauen
Boris
 
 

Video: Design Thinking – oder Produkt Entwicklung leicht(er)

 
Agile Skalierung bedeutet nicht, nur an einer bestimmten agilen Methode zu hängen und deren Einsatzradius zu erweitern. In einer tatsächlich fraktal skalierten Organisation, in der jedes einzelne Team unabhängig von den anderen entwickeln kann (siehe Architektur & Infrastruktur), muss sich auch die Herangehensweise an die Produktentwicklung selbst verändern. IDEO hat in diesem Bereich mit Design Thinking den Maßstab gesetzt.
 
In diesem kurzen Video erkläre ich euch, wie Design Thinking dazu beitragen kann, große Produkte mit vielen Teams skaliert zu entwickeln.
 
Mehr darüber könnt ihr auch in meinem Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” lesen oder unser Training “Produktfindung mit Design Thinking” besuchen.
Viel Spaß beim Anschauen!
Boris
 

 

Interview mit Christoph Schmiedinger

 
Foto_Christoph_SchmiedingerChristoph Schmiedinger ist unser agile Transition Spezialist im Bereich Banking und Fintechs. Er arbeitet in großen skalierten Projekten und agilisiert diese über die Zeit.
 
Boris: Christoph, wie ist es in einer Bank zu arbeiten und dort bei Teams Scrum einzuführen. Ist daran etwas besonderes?
Christoph: Es ist spannend und herausfordernd zugleich! Jede Branche hat seine eigenen Individualitäten und Herausforderungen – daher ist es in der Tat besonders, in einer Bank Scrum einzuführen. Spezielle Faktoren sind der Digitalisierungstrend, alte Legacy-Systeme und ein dynamisches Marktumfeld mit neuen Mitbewerbern.
 
Boris: Was hat sich für Banken in den letzten Jahren geändert, so dass diese darüber nachdenken Scrum in ihrer IT und in ihrer Software Entwicklung einzusetzen?
Christoph: Die Banken bewegen sich gerade in einem enorm herausfordernden Umfeld. Das Zinsniveau ist niedrig, die Margen knapp und die Regulierungszyklen werden immer kürzer. Hinzu kommt, dass eine Reihe von Start-ups, die sogenannten Fintechs an den Kundensegmenten der etablierten Banken knabbern. Der Druck, ständig neue und moderne Lösungen innerhalb kürzester Zeit auf den Markt zu bringen, steigt. Diese dafür notwendige Flexibilität zu erreichen, ist speziell für Banken herausfordernd, da die meisten eingesetzten Kernbankensysteme sehr alt (wir sprechen in der Regel von Mainframes) und daher besonders unflexibel sind.
 
Boris: Welche Rolle spielt Deiner Meinung nach dabei die Digitalisierung, von der nun alle sprechen? Und weshalb trifft das insbesondere Banken?
Christoph: Die Digitalisierung wird früher oder später jede Branche treffen und diese mehr oder minder revolutionieren. Die Vergangenheit zeigt, dass es in diesen Branchen oft Pioniere benötigt, die die Potentiale neuer Technologien nutzen, um etablierten Unternehmen den Kampf anzusagen. Genau diese Situation erleben wir gerade im Finance-Bereich. Eine Vielzahl dieser bereits zuvor erwähnten Fintechs punkten mit modernen innovativen Lösungen bei den Kunden. Klein angefangen, haben nun die ersten Fintechs auch die Banklizenz beantragt und bekommen und werden so nun zur tatsächlich ernstzunehmenden Konkurrenz.
Eine zweiter Faktor, der besonders bei Banken relevant ist, sind selbstverständlich die Kunden. Diese wickeln zunehmend mehr Bankgeschäfte online ab. Die Konsequenz: Der Bedarf an Online-Lösungen steigt während der Bedarf an stationären Filialen und Kundenberatern abnimmt. Viele Banken kämpfen nun mit ihren Kosten, die durch das große Filialnetz und den hohen Personalstamm verursacht werden. Mit Hilfe der Digitalisierung sollen nun die internen Prozesse optimiert und so Kosten und in weiterer Folge auch Personal eingespart werden. Dies wird auch notwendig sein, um wettbewerbsfähig zu bleiben.
 
Boris: Was sind deiner Meinung nach die Erfolgsfaktoren, um als Bank mit Scrum durchzustarten?
Christoph: Für mich sind es im Wesentlichen drei Faktoren. Der erste Faktor ist die absolute Kundenzentrierung. Sich bereits zu Beginn der Entwicklung mit den Kunden zu beschäftigen ist die Pflicht, die Ergebnisse der eigenen Hypothesen auch regelmäßig mit echten Bankkunden ab zu prüfen die Kür. Der zweite Faktor schließt sich gleich nahtlos an: kurze Zyklen – sowohl in der Entwicklung in Form von kurzen Iterationslängen als auch im Rollout in Form von schnellen Launches am Markt. Dieser Fokus auf kurze Zyklen schafft so die Basis für kontinuierliches und schnelles Feedback für die Entwicklung, die dieses wertvolle Gut wiederum in ihre Iterationen einspeisen kann. Der letzte Erfolgsfaktor für mich ist die Nutzung moderner Technologien. Keine Hemmung davor zu haben, neue Technologien auszuprobieren und diese auch einzusetzen. Die technologische Welt dreht sich so schnell – wir sollten uns die dadurch entstehenden Vorteile zu Nutze machen.
 
Boris: Kannst du uns noch einen Tipp aus deiner Praxis geben? Was sollte man beachten, wenn man Scrum in großen Projekten einführen will?
Christoph: It’s all about the people! Jene Kollegen, die das Umfeld führen, in dem Scrum eingeführt werden soll, sollten das passende Mindset haben. Nur wenn diese Kollegen die agilen Werte und Prinzipien vorleben, kann auch im großen Kontext ein agiler Spirit entstehen. Klar, es benötigt natürlich auch moderne Architekturen, Tools und Skills – diese können aber erlernt oder zugekauft werden. Das passende Mindset muss hingegen aus tatsächlicher Überzeugung stammen und ist somit viel schwieriger zu etablieren. Wenn Sie als Manager vor dieser Herausforderung stehen, Scrum in einem großen Projekt einzuführen, suchen Sie die passenden Führungspersönlichkeiten für die ScrumMaster- und Product Owner-Rollen.
 
Boris: Vielen Dank für das interessante Interview.
 
Buchcover Scrum-Think bigIch hoffe ich habe euch ein wenig Lust auf meine neues Buch gemacht: Ihr findet “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” in allen gut sortierten Buchhandlungen.
 
 
 

Scrum Think b!g – Leserstimme von Jürgen Margetich

 
Buchcover Scrum-Think bigUnternehmen, die sich auf den Weg machen, ohne formales Linienmanagement auszukommen, entwickeln in jedem Mitarbeiter die Kompetenz des Managens.
In gewohnt provokanter Art führt Boris Gloger in Dichotomien, die so vielleicht nicht zu halten sind, zum Beispiel ergebnisorientierte Arbeit am Projekt vs. karriereorientierter Gremienarbeit und Political Engineering. Dennoch muss man schon genau prüfen, ob das nicht jene Systemeffekte sind, mit denen wir tagtäglich zu kämpfen haben. Und damit hätte Gloger recht behalten. Es lohnt daher, sich spielerisch auf die Provokationen einzulassen und zu Lernfeldern zu reframen.
Das erste Drittel des Buchs ist Grundlagenwiederholung – für den Leser, der Neues sucht, vielleicht irritierend. Warum ich es dennoch genau gelesen habe und das auch weiterempfehlen möchte, ist der Umstand, dass wir (selbst ich als Berater) im Alltag vor allem mit klassischer Führung und Struktur, mit klassischen Organisationen und Projekten konfrontiert sind. Da lohnt es sich, einen Schritt zurück zu machen und zu fragen: Was soll denn hier überhaupt skaliert werden? Die Pyramide – oder eine agile Organisation? Sich die zu skalierende Basis genau anzusehen, ist möglicherweise der wichtigste Teil des Buchs. Vielleicht hätte ich mir am Anfang eine Kernaussage zur Skalierung gewünscht. Quasi das Architekturbild dazu, um dann nachzulesen, was dahintersteckt – welche Basis, welche Prinzipien etc.
Geht es hier ums Skalieren oder um die Basics? Ohne Basics kein Skalieren. So stellt Boris zum Beispiel auch den Bezug zu Alistair Cockburn´s Definition zu Agilität her: Collaborate, Deliver, Reflect, Improve. Hätte Boris in seinem Buch noch Checkboxes oder Skalen (1 – 10) nachgesetzt, könnte sich der an Skalierung interessierte Leser gleich selbst überprüfen und seine Organisation auch. Arbeiten wir zusammen? Liefern wir? Reflektieren wir? Verbessern wir uns? So einfach ist die Welt. Und wenn überall ein deutliches Ja steht oder eben eine 10: Wer würde sich dann noch die Mühe machen, die Bürokratie von SAFe zu implementieren, zu betreiben und zu verwalten? Richtig – nur Bürokraten.

Was hatte ich erwartet?

Ich hatte ein Buch erwartet, das sich – so wie es andere zum Thema Skalierung tun – mit skalierten Prozessen, Strukturen, Organisationsformen, der Anpassung von Zusammenarbeitsmodellen und ggf. adaptierten bzw. neuen Rollen befasst und diese vermittelt. Also ein Organizational Engineering Book. Was habe ich gelesen: Den Erfahrungsbericht eines durch und durch agilen Unternehmensführers, der erkundet, was Wachstum und Skalierung entlang der agilen Prinzipien bedeuten kann.
Wer à la SAFe ein Prozess-Organigramm zur nachfolgenden Implementierung erwartet, wird enttäuscht sein. Wer seine Organisation entwickeln möchte – Agilität skalieren, in diesem Sinne verbreitern, – der wird in den Grundprinzipien bestärkt seinen eigenen Weg entlang der Erfahrungsberichte, Praxisbeispiele und Gastkommentare finden. Ein Buch zum selber Arbeiten, nicht zum Implementieren.

NEIN.

Wenn wir von Skalierung sprechen, dann ist wohl der Aspekt des JA zum NEIN in der Organisation entscheidend. Boris Gloger rührt an mehreren Stellen an dieser Widerspruchsfähigkeit, die in eine klassisch gebildete, hierarchische Organisation erst eingebracht werden muss. Offen bleibt leider die Frage des systemischen Neins, also der Frage nach der Fähigkeit der Organisation, mit Hilfe vieler Neins an vielen Stellen des Unternehmens konstruktiv die eigene Stärke auszubauen, Wettbewerbsvorteile zu gewinnen und in der innerbetrieblichen Competition langfristig zu bestehen. Wie bei allen bisherigen Büchern von Boris Gloger dürfen wir auch hier eine zweite und ggf. dritte Auflage erwarten. In dieser wünsche ich mir dann Betrachtungen und fundierte Untersuchungen zu diesem Aspekt.

Alte Wunden

Mit seinem Hinweis auf die Theory of Constraints legt Boris seinen Finger tief in eine der ältesten Wunden der Skalierung. Skaliert wird, wenn der Ausweg aus einer Lieferunfähigkeit oder gefühlter bzw. realer Verspätung von Lieferungen durch Größe behoben werden soll. Was also passiert, ist: Das System, das in eine problematische Situation geführt hat, wird weiter ausgedehnt und verursacht so noch größere Schäden. Selten habe ich in meiner Beraterlaufbahn gesehen, dass diese Skalierungen (ungeachtet ihres methodischen Setups) erfolgreich gelaufen wären.
Daher lohnt es sich, einige einfache Prinzipien, wie Gloger sie auch im Buch aufführt, zu berücksichtigen: Anforderungen reduzieren, Auslastung auf 60–70 Prozent runterfahren, vom Multi-Project- zum Single-Project-Focus. Dafür eben liefern und verkaufen.
Etwas kontraintuitiv, aber wirksam: „weniger“, dafür „erfolgreich“.

Thema Vertrauen

Die schwerste Managementaufgabe in der Skalierung: Führung schafft Vertrauen. Boris Gloger stellt in seinem Buch eine hohe, fast schon nervige Forderung: Manager müssen ihren Teams vertrauen. Gleichzeitig attestiert er dem Management, im Dauer-Panikmodus zu arbeiten. An dieser Stelle könnte man das Buch entspannt zur Seite legen, sich ärgern und Gloger vorwerfen, er wisse nicht, wovon er spricht/schreibt. Und vor allem würde man sich angesichts der eigenen Geschichte enttäuschten Projektvertrauens noch mehr ärgern. Ehrlich.
Unterstellen wir mal den grundsätzlichen Willen zum Vertrauen, denn auch Manager wollen ja nicht per se misstrauen. In wie vielen Fällen hat man als Manager das Gefühl, das investierte Vertrauen wurde enttäuscht? So ist es auch mir beim Lesen dieser Passage (Seite 154) gegangen. Dann habe ich kurz nachgedacht und zwei Bausteine aus der bisherigen Lektüre dieses Buchs zusammengefügt:

  1. Für Agilität und hohe Beschleunigung wird von allem mehr gebraucht als notwendig – mehr Teammitglieder, mehr Platz, mehr Kompetenz, mehr Wissen …
  2. Ein Team, das das Ziel versteht und auch frei gewählt hat.

Und dann fiel es mir wie Schuppen von den Augen. Wann habe ich, wann haben Sie, geschätzte Co-Leser, beide Voraussetzungen geschaffen? Also 1. mehr … als notwendig bereitgestellt und 2. ein Team, das von sich aus „gepullt“ hat. Und hier ist schon die Misere.
Also frage ich mich, und vielleicht ist das auch die Motivation hinter dem Lesen dieses Buchs: Wie kann es mit einem Mangel – also „weniger … als notwendig“ – und einem eingeteilten, beauftragten Team gelingen, Vertrauen aufzubauen und nicht enttäuscht zu werden? Das ist die eigentliche Frage. Vielleicht braucht es auch ein anderes Buch: agil Skalieren in einer traditionellen Mangelwirtschaft unter veralteten Arbeitsverträgen? Nun gut. Also lese ich weiter und folge der Vorstellung der idealen Welt. Vielleicht kann ich ja aus dieser etwas in meine ganz und gar suboptimale, reale Welt mitnehmen.

Die fraktal skalierte Organisation

Ein neuer alter Begriff: das Fraktal.
Je weiter man sich an das Ende des Buchs heranliest, desto öfter wird man mit diesem Begriff konfrontiert. Weniger als Anleitung, mehr als Feststellung zur agilen Organisation in Skalierung. Wer mag da nicht denken, das Ende des großen Ganzen stünde an? Das eine Ganze würde substituiert durch die vielen kleinen Fraktale, die das große Ganze in sich tragen, selbiges aber würde nicht mehr in Erscheinung treten.
Wer für diesen Gedanken reif ist, der kann sich auch der Skalierung in und von agilen Organisationen/Teams/Projekten stellen. Noch eins weitergedacht: Erst wer diesem Gedanken folgt, kann sich überhaupt gelebter, wirksamer Agilität zuwenden.

Und so sollten Sie dieses Buch lesen

Fangen Sie mit Kapitel 6.3. „Die Skalierungstoolbox“ an. Während des Lesens dieses Kapitels können Sie gleich Ihr Projekt/Ihre Organisation skalieren. Entweder sind Sie jetzt enttäuscht (das Ganze ist ja immer noch hauptsächlich Scrum, halt ein wenig erweitert) oder
Sie sind begeistert (denn das Ganze ist ja immer noch hauptsächlich Scrum, halt ein wenig erweitert, z.B. um das Konzept der „Gilden“).
Dann lesen Sie von Kapitel 1 weg mit Stift und der permanenten Fragestellung: Machen wir das so wie beschrieben oder nicht?
Wenn ja, lesen Sie weiter. Wenn nein, wissen Sie ja, was es zu ändern gilt, um mit der Skalierungstoolbox, wie von Boris Gloger beschrieben, erfolgreich zu arbeiten.
Und schließlich lesen Sie den letzten Teil des Buchs. Darin finden Sie die richtigen Herausforderungen der Skalierung, vorausgesetzt, Sie haben die ersten beiden Schritte befolgt.
Hinter dem Berater und Trainer Boris Gloger spürt man in diesem Buch auch den gelernten Philosophen. Reich an Quellenangaben lässt sich der eigene Bücherschrank mit guten Buchempfehlungen aus dem Quellenverzeichnis füllen. Wer durch die Quellen (dabei auch HBR und zahlreiche Videos) zumindest querliest und surft, hat das Thema Agilität in vielen Facetten schnell umrissen und sich ein ausreichend gutes Überblicksbild geschaffen, um damit erste Schritte in der Skalierung zu wagen und eigene Erfahrungen zu sammeln.
Als langjährigem Weggefährten von Boris Gloger mag man mir beim Lesen dieses Buchs und meinen Kommentaren einen allzu freundlichen Blick vorwerfen. Aber wo soll ich ansetzen? Den Ausweg habe ich in folgender Frage gefunden, die Boris bisher – wie übrigens alle anderen Autoren der agilen Szene, soweit mir bekannt ist – komplett unbeantwortet gelassen hat: Wie sieht die agile Organisation, wie Boris sie beschreibt, in ihrer Skalierung in Zahlen, in Geld ausgedrückt aus? Auch das vielleicht ein Wunsch an die nächste Ausgabe: Szenarien gerechnet im Vergleich von klassischer zu agiler Organisation in Skalierungsvarianten.
Wenn Sie dieses Buch gelesen und sich der Mühe unterzogen haben werden, sich nochmals mit den Prinzipien und Grundsätzen agiler Teams auseinanderzusetzen, werden Sie unter Umständen zum gleichen Schluss kommen wie ich: Skalierung ist in erster Linie eine Aufgabe der Organisationsentwicklung und erst in zweiter Linie eine Frage der Methodik, Praktiken und Organisation.
 
Buchcover Scrum-Think big“Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”