Scrum Leadership

Besonders komisch wird uns bei dem Begriff “Business Agility”. Denn worum soll es in der Agilität sonst gehen? Wofür machen wir das Ganze denn überhaupt? Da wird also ein neuer Begriff hervorgehoben, der etwas verdeutlichen sollte, was doch eigentlich von Anfang an klar gewesen sein sollte: Produktentwicklung ist ein Teamspiel. Und zwar ein dynamisches und kein Synchronschwimmen. Es geht darum, jenseits der festgelegten Prozesse und etablierten Werkzeuge den Fokus auf die Individuen und ihre Zusammenarbeit zu legen. Es geht darum, Wert zu liefern statt Berge von bedrucktem Papier. Es geht darum, innerhalb des Business - also mit Kunden, Nutzern, Stakeholdern, gemeinsam Probleme zu lösen, statt sich an den Wortlaut eines Vertrages zu klammern. Und vor allem, Änderungen zu begrüßen statt sie abzublocken, um einen Plan einzuhalten. Was sonst soll das denn sein, als “Business Agility”?

Vor kurzem erst haben wir in einem Vortrag aufgezeigt, wie wir Scrum als Agile Leadership verstehen. Nämlich als Führung einer Organisation nach den agilen Werten und Prinzipien mittels der Verantwortungsbereiche, Events und Artefakte von Scrum. Also auf die Art und Weise, die wir in unserem eigenen Unternehmen leben. Allerdings besteht unsere Firma auch nur aus einem Team, das wir nach Scrum organisiert haben, also im wesentlich selbst-gemanaged, in eigener Regie. Und wenn diese Konstellation noch klein und überschaubar ist, bringt sie uns schon auf die wesentlichen, einander scheinbar widersprechender Aussagen.

Scrum ist nicht genug

Als ein Trainingsanbieter für Scrum und verwandte Themen kennen wir sehr wohl die Grenzen von Scrum. Wir entwickeln selbst Produkte wie unsere Schulungen, aber auch die Website und das Lernmanagementsystem. Hierfür ist der Scrum-Rhythmus fast schon analog Scrum Guide implementiert. Aber wir sind auch Schulungsdienstleister. Das bringt eine ganze Reihe von zusätzlichen Planungs-, Organisations- und Supporttätigkeiten mit sich. Abgesehen davon kümmern wir uns auch um den Vertrieb von Firmenschulungen sowie einige gemeinnützige Nebenvorhaben. Da ist es klar, dass der Arbeitsmodus nicht allein von Scrum getrieben werden kann, sondern wir uns der Techniken von Kanban bedienen.

Auch in unserer Softwareentwicklung, also der Anpassung unserer Verwaltungssysteme sowie der Ergänzung der Website und des Lernmanagements, erscheint Scrum nicht als einzige Methode. Die agilen Entwicklungspraktiken Continuous Integration, Test Driven Development und Refactoring, um nur mal drei zu nennen, stammen aus dem eXtreme Programming. Also schon wieder eine Aufgabenstellung, für die Scrum alleine anscheinend nicht ausreichen kann.

Scrum ist genug

Im heutigen Verständnis von Scrum haben wir schon wesentlich mehr Flexibilität bei der Planung und Umplanung der Sprints. Wir haben immer schon Varianten von Scrum mit eingeführt, bei denen sich das Team auch um andersartige Aufgabenstellungen kümmern musste. Auch bevor David Anderson seine Erkenntnisse in der Kanban-Methode verdichtete. Also “konnte” Scrum immer schon DevOps.

Die x%, also den Anteil der im Sprint Planning einplanbaren Arbeit – aus Product Backlog – werden gemeinsam vom Product Owner und den Developern festgelegt. Das obige Beispiel entspricht eher unserer Arbeit bei DasScrumTeam. Wir haben einen leichten Überhang an Service-Aufgaben, die meistens mit vorab unplanbarer Arbeit einhergehen.

• Anfragen von Kunden
• Technische Probleme
• Fakturierung und Buchhaltung
• Büroorganisation
• Support und Beratung

Auch die Entwicklungspraktiken sind kein vollkommen neuer Posten in der Scrum-Welt. eXtreme Programming und Scrum haben sich schon immer nebeneinander entwickelt. Jeff Sutherland selbst besteht darauf, dass gewisse Praktiken bei Scrum Teams in der Entwicklung von technischen Produkten eingeführt werden. Ganz davon abgesehen bildet Scrum seit jeher den organisatorischen Rahmen, die Grundstruktur für die Integration, Neueinführung und Verbesserung beliebiger Praktiken.

Auch wenn wir uns also vieler verschiedener Ansätze bedienen, sind wir doch im Kern ein Scrum Team, das nach dem Sprint-Rhythmus im empirischen Prozess – Transparenz schaffen, Überprüfen und Anpassen – Wert liefert.

Was viele Stimmen in der agilen Szene also gerne lauthals verkünden, dass “Scrum zu unflexibel” sei, basiert auf mangelndem Hintergrundwissen und zu kurz gedachter Schlussfolgerung. Scrum ist äußerst flexibel bei der Wahl der Anwendungsbereiche und damit verbundener Prozesse und Praktiken. Das Führungsmodell von Scrum muss daher auch in Kontexten funktionieren, die sich weit jenseits der Softwareentwicklung abspielen.

Scrum Leadership im kleinen oder mittelständischen Unternehmen

Auch wenn Unternehmen mit weniger als 10 Mitarbeitern keine Seltenheit sind, zählen durchaus auch noch Unternehmen bis zu 300 Mitarbeitern eher zu den kleineren Vertretern, gemessen an Großkonzernen mit tausenden oder zehntausenden Beschäftigten. Wie soll denn ein Führungsmodell auf Scrum-Basis, was ja von einem Scrum Team ausgeht, mit wesentlich mehr als 10 Mitarbeitern funktionieren?

Gut, wir können uns kaum vorstellen, dass wir 300 Developer in einem einzigen Team zusammenfassen. Dabei ist der Grundgedanke dahinter, dass sich alle Mitarbeiter als Teil eines sozialen Systems zur Wertschöpfung betrachten, so verkehrt nicht. Tatsächlich haben wir von Unternehmen dieser Größenordung gehört, die zumindest einmal in der Woche ein “all-hands”-Meeting durchführen. Praktisch das “Scrum of Scrums” des Unternehmens. Um fair zu bleiben, die Mitarbeiter gehen danach wieder in ihre Teams.

Scrum Leadership beruht auf drei Kräften:

• Produkt-Führung
• Soziale-Führung
• Arbeits-Führung

Produkt-Führung: Die Verantwortung des Product Owners

In einem klassischen Stakeholder-Diagramm würde man also den Product Owner als Scrum Leadership-Rolle immer bei dem meisten Einfluss und dem meisten Beitrag zum Produkt ansiedeln.

Product Owner als Top-Stakeholder

Wir hören jetzt schon die vielen Stimmen die sagen: “Aber bei uns sind die Product Owner in den Development-Teams, wir haben nicht nur einen.” Dazu entgegnen wir, dass wir hier vom tatsächlichen Product Owner reden, also der Person, die Rechenschaft für die Produktentscheidungen leisten muss:

• Kümmern wir uns mit dem Produkt um das richtige Problem?
• Bieten wir dem Kunden eine wünschenswerte Lösung?
• Können wir das Produkt technisch realisieren?
• Lohnt es sich, da Geld reinzustecken?

In dem Fallbeispiel von GrooveX zeigen wir, wie der CEO hier die Gesamt-Product Owner-Rolle ausfüllt. Doch kann es durchaus sein, dass sich der verantwortliche Product Owner Unterstützung holt, zum Beispiel wenn:

• Entwicklungsteams an mehreren Standorten arbeiten und man kurze Entscheidungswege realisieren möchte,
• mehrere Produkte entwickelt werden, die absolut keine geschäftlichen oder technischen Überschneidungen haben,
• einzelne Teilaspekte des Produkts so komplex sind, dass jemand mit einem besseren geschäftlichen Verständnis der Detailanforderungen gebraucht wird, also zum Beispiel bei einer Produktfamilie mit eigenständigen Unter-Produkten wie Microsoft Office.

Die Produkt-Führung lässt sich also auch im mittelständischen Unternehmen mittels Scrum realisieren. Wie sieht es da mit den anderen Führungsaufgaben aus?

Soziale Führung: Die Verantwortung des Scrum Masters

Es gibt unterschiedliche Meinungen dazu, ob man Organisationen überhaupt als soziale Systeme sehen kann. Wenn wir als soziales System eine Kombination von Menschen und deren Beziehungen verstehen, die einen gemeinsamen Zweck haben und diesen durch ihr Zusammenwirken verfolgen, dann sind kleine und mittelständische Unternehmen auf jeden Fall in diesem Definitionsbereich.

Die klassische Linienführung beschäftigt sich vor allem damit, wie Zuständigkeiten abgegrenzt werden. Der Hierarchieknoten neben mir hat andere Aufgaben als ich, der über uns hat die gesammelte Verantwortung, der Zweig an meiner Position muss sich von mir etwas sagen lassen. Diese hierarchische Aufteilung eignet sich vor allem für geordnete Kontexte - also dort, wo sich Probleme und deren Lösungen gut in Teilprobleme und -Zuständigkeiten zerlegen lassen.

Wenn wir nach den agilen Werten und Prinzipien vorgehen, interessiert uns die Zusammenarbeit mehr als die Aufgabenabgrenzung. Das bedeutet, dass wir es mit einer anderen Art von sozialer Systembetrachtung zu tun haben.

Die systemische Betrachtung und deren Konsequenzen liegen im Verantwortungsbereich des Scrum Masters. Während klassische Führungskräfte innerhalb des Systems Führung durch ihre Position ausüben, arbeiten Scrum Master durch Facilitation, Coaching, Mentoring, Training und Beratung am System. Aber wen beraten sie? Die Agile Leaders?

Hier kommen wir zur Besonderheit der Scrum Leadership. Sie kommt ohne Manager aus – und ein “Agile Leader” ist ein Manager mit netterer Stellenbezeichnung.

Arbeits-Führung: Die Verantwortung des Teams

In vielerlei Hinsicht ist die Bezeichnung “Developer” für alle diejenigen, die wertschöpfend in Scrum arbeiten, problematisch. Zu leicht lässt sich der Begriff mit Softwareentwicklern verwechseln. Vielfach führt diese Verwechslung zu Konstrukten mit “Scrum Teams” aus Softwareentwicklern und separaten Organisationseinheiten von Business Analysten, Testern oder anderen Spezialisierungen. Deshalb möchte ich hier analog zu älteren Scrum-Definitionen lieber von “Teams” reden. Denn die Führung der Arbeit – Einschätzung, Planung, Koordination, Reporting, Prozessverbesserung – erfolgt in Scrum durch das oder die Teams.

Ein Team ist eine besondere Form der sozialen Gruppe. Teammitglieder sind nicht nur durch eine gemeinsame Zielrichtung miteinander verbunden, sondern arbeiten auch sich selbst koordinierend zusammen an dieser. Teams können die unterschiedlichsten Aufgaben haben, aber sie zeichnen sich dadurch aus, dass sie die gemeinsam schaffen. Natürlich gibt es prinzipiell auch Teams, die sich von Managern führen lassen. Deshalb verwendet Richard Hackman auch gerne den Begriff “Real Team”. Ein reales – oder “echtes” – Team arbeitet gemeinsam an einem geteilten Ziel, verantwortet den eigenen Fortschritt, und managed den eigenen Arbeitsprozess.

Hackman spricht gerne von “effektiven Teams”. Effektive Teams sind echte Teams mit einer mitreissenden Zielrichtung, befähigenden Strukturen, einem unterstützendem organisatorischen Rahmen und der Begleitung durch Experten im Teamaufbau, der Motivation, dem Coaching und der Ausbildung. Echte Teams

• liefern zur Zufriedenheit des Kunden
• verbessern ihre Zusammenarbeit kontinuierlich
• bieten den Individuen Raum zur eigenen Weiterentwicklung

Wie funktioniert das ohne Manager? Da kommen vor allem zwei Rahmengeber ins Spiel.

• Product Owner bieten die Zielsetzung an. Sie liefern den organisatorischen Rahmen der Arbeit und unterstützen die Teams bei der Wertschöpfung durch ihre wirtschaftliche Perspektive.
• Scrum Master kümmern sich um das Coaching, die Facilitation und die Ausbildung und bauen dafür befähigende Strukturen auf. Sie unterstützen die Teams bei der Formulierung und Verbesserung ihrer Arbeits- und Teamprozesse.

Wir vertrauen also in der Scrum Leadership auf die Selbstmanagement-Fähigkeiten von Teams, anstatt übermässige Kontroll- und Berichtshierarchien einzuführen. Das funktioniert mit einem Team, und mit einer kleinen und mittleren Organisation von Teams.

Doch wie sieht es mit Großunternehmen aus?

Scrum Leadership in großen Unternehmen

Vielleicht lassen sich große Unternehmen gar nicht als ein einzelnes System sehen, verfolgen die Bereiche, Abteilungen oder Subkonzerne häufig eigene Ziele. Trotzdem macht es Sinn, nach den verbindenden Elementen zu suchen. Und da werden wir in Großunternehmen noch deutlicher als in KMUs auf den drei Ebenen fündig:

• Die Ebene der Unternehmenswerte, -Ziele und Strategien zur Erfüllung derselben.
• Die Koordinationsebene für Produktentwicklungen, Projekte oder Dienstleistungen.
• Die Arbeitsebene, in der die unmittelbare Wertschöpfung stattfindet.

Klaus Leopold verwendet für diese Ebenen recht treffend die Metapher “Flight Level”. Ob visionär–strategisch, taktisch–koordinierend oder wertschöpfend–organisierend, im Vordergrund steht bei ihm die Visualisierung der Arbeit unabhängig vom jeweiligen Prozess. Allerdings gibt es auf allen Ebenen – wie in Kanban üblich – Feedbackschleifen, die in regelmässigen Zyklen zur Verschaffung von Transparenz, Überprüfung und Anpassung genutzt werden.

Das klingt schon fast wie Scrum, auch wenn Klaus keine bestimmten definierten Rollen, Artefakte oder Ereignisse voraussetzt. Doch stellen wir uns einfach mal vor, wir lösen uns von der falschen Vorstellung, dass Scrum Teams nur zum Sprint Review etwas liefern können. Vielleicht müssen sie noch nicht einmal Scrum Teams heissen. Auch hier brauchen wir die Führung über das Produkt und die Unternehmensziele, die soziale Führung und die praktische Handhabung der Entwicklung und des Service.

Die Arbeitsebene – Scrum auch ohne Scrum?! Wie auch Service-Teams und Business Units von Scrum-Prinzipien und Praktiken profitieren können.

Vor kurzem haben belgische Trainerkollegen ein Scrum-artiges Vorgehensmodell für beliebige Geschäftsteams vorgestellt. Das Hauptproblem bei der Anwendung von Scrum in Teams, die Dienstleistungen anbieten oder Produkte vertreiben, statt sie zu entwicklen ist anscheinend die Bezeichnung der Scrum-Artefakte – weniger der Prozess an sich.

Unabhängig von der Art der Arbeit gibt es stets lang- und mittelfristig planbare Ziele und den Umgang mit kurzfristigen Herausforderungen. Deshalb spricht der aktuelle Scrum Guide auch nicht von Produktentwicklung, sondern von Wertschöpfung:

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

Praktisch mag das dazu führen, dass die Product Owner-Verantwortung in einer Service- oder Businessorganisation wenig von einer Teamleiterrolle abweicht. Die Ziele müssen richtig mit denen der Gesamtorganisation abgeglichen werden.

Viele Organisationen merken nach einer Weile mit Scrum, dass sie ohnehin die bestehenden, auf hierarchischer Arbeitsteilung basierenden Organisationseinheiten so nicht mehr brauchen. Die tatsächlichen geschäftlichen Herausforderungen werden mit echten funktionsübergreifenden Teams bewältigt. So wandern mitunter auch die unterstützenden Tätigjkeiten in die Teams. Was wiederum auch eine großartige Entwicklungschance für alle Mitarbeitenden mit sich bringt.

Scrum Teams sind also keine Komponenten einer größeren funktionalen Maschinerie, sondern sich selbst-managende Mini-Unternehmen im Unternehmen. Was nicht heißt, dass ihr eigener Fortschritt zu Lasten eines größeren Ziels erfolgt.

Die Koordinationsebene - Large Scale Scrum und Alternativen zur Zusammenarbeit im großen Stil

Es gibt keine offizielle Definition für skaliertes Arbeiten mit Scrum. Das sehen einige als Manko, andere kommen mit ihren eigenen Rahmenwerken und Modellen. Wir sehen es als Chance, eine tatsächlich auf die Bedürfnisse der Organisation aufgebaute Teamlandschaft zu gestalten.

• Für große Produktentwicklungen bieten sich eng synchroniserte “Über”-Scrum Teams an, wie sie beispielsweise in Large Scale Scrum oder Nexus favorisiert werden. Unter der Produkt-Führung eines einzigen Product Owners erfolgt in einem gemeinsamen Takt das stetige Zusammenspiel aus Lernen und Liefern.
• Service-Organisationen können sich so organisieren, wie sie den meisten Wert schaffen können. Das kann für einen technischen Kundendienst anders aussehen als für ein Call Center oder ein Krankenhaus. Hier kann ein Nebeneinander ohne zentrale Steuerung, aber mit gemeinsamer Koordination schon viel bewirken.
• Vertriebsteams können sogar gegeneinander antreten, in einer Art friedlichem Wettbewerb innerhalb des Unternehmens. Dafür benötigen sie möglichst viel Autonomie und Handlungsfähigkeit ohne Abstimmung “nach oben”.

In Großunternehmen haben wir alle diese Varianten und mehr. Wie viele der Teams und Organisationseinheiten nachher tatsächlich im gleichen Rhythmus zusammenspielen, und wieviele in separaten Feedbackschleifen vorangehen, richtet sich nach der Kohäsion der Produkte oder Dienstleistungen.

Die Steuerungsebene - Visionen und Ziele aufstellen, Gesamtfortschritt im Blick behalten – und das mit Work in Process - Limits

Was auf der mittleren Ebene furchtbar kompliziert erscheint, ist auf der strategischen Ebene auf einmal wieder recht einfach. Alles was es braucht, ist die Entscheidung auf welche Vorhaben, Produktschritte, Projekte, Initiativen, Verbesserungen – man verzichtet. Priorisierung ist nicht einfach die Bewertung oder Reihung von Zielen und Wünschen. Wie Klaus Leopold so passend darlegt, wird in vielen Organisationen komplett ignoriert, dass man ein System überlastet, wenn man alle Vorhaben gleichzeitig anfangen will. Deshalb benötigt es auf der Steuerungsebene gerade eine starke Product Owner-Persönlichkeit. Denn das Produkt ist hier das Gesamtunternehmen, mit allen wertschöpfenden und unterstützenden Tätigkeiten.

Neben der Visualisierung der Arbeit – des Value Streams – lohnt sich gerade auf der strategischen Ebene auch die Visualisierung der Wertschöpfungskette – der Value Chain. Wenn man zumal noch die Informationen über Komponenten, Aktivitäten, Praktiken und Daten um deren jeweilige Entwicklungsstufe ergänzt, erhält man eine sehr aufschlussreiche Wardley-Map über die aktuelle Situation – und damit gute Erkenntnisse über sinnvolle Strategieentscheidungen.

Diese Prozesse sind nicht so einfach zu begleiten. Daher empfiehlt sich hier die Position des Scrum Masters als Executive Facilitator. Zusammen mit den Vertretern der wertschöpfenden Einheiten bilden Executive Product Owner und Scrum Master gewissermassen das echte Nexus-Team einer Organisation. Werte und Strukturen statt “Gedankenkontrolle” “Wir wollen dann bei uns Agile ausrollen.” “Erst einmal sorgen wir für das richtige Mindset.” “Einige wehren sich gegen die agile Transition.”

Wahrscheinlich haben wir Agilen Coaches und Scrum Trainer die falschen Erwartungen und Annahmen selbst mit erzeugt, die in den Köpfen vieler potentieller und tatsächlicher Scrum-Anwender verankert sind. Auch uns ist es als Trainer schon passiert, dass wir – zumindest in Gedanken – einem Teilnehmer gesagt haben: “Da denkst Du falsch!”

David Snowden adressiert diese Fehleinschätzung und die damit verbundene falsche Hoffnung, nach einer “Korrektur” des “Mindsets” würde schon alles laufen, in seinem Artikeln und Vorträgen zum Thema “Rewilding Agile”.Es sei vermessen, von anderen Menschen eine Änderung ihrer grundsätzlichen Einstellungen und Glaubenssätze zu verlangen. Stattdessen solle man für passende Strukturen sorgen, in denen sich das gewünschte Verhalten besser herausbilden kann. Statt also von jemandem verlangen, “agil” zu sein, schaffen wir Rahmenbedingungen welche Entscheidungen nach agilen Werten und Prinzipien begünstigen.

In der Scrum Leadership sorgt der Scrum-Prozess selbst für einen großen Teil der Rahmenbedingungen. Das Scrum Leadership-Dreieck bietet die Orientierung nach Geschäftszielen, Verbesserung der Zusammenarbeit und Lieferung von Wert. Um diesen Kern herum bieten Product Owner und Scrum Master – gerne auch in der Ausprägung CEO und COO – die grundsätzlichen Rahmenbedingungen.