Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw

Video: Skills – und wir können es doch

Im Video “Infrastruktur – Verteilt euch!” habe ich erklärt, wie und warum Architektur und Infrastruktur darüber entscheiden, ob ein Projekt erfolgreich skaliert werden kann. Schön und gut, doch das reicht nicht, wenn die Kollegen inner- und außerhalb der Projektteams nicht die Skills oder Kenntnisse haben, um diese Infrastruktur zu beherrschen oder sie einfach nur zu verstehen. Es gibt sogar Fälle, in denen Betriebsräte verbieten, die Infrastruktur für die Kommunikation verteilter Teams einzusetzen. Im weitesten Sinne hat die Organisation hier nicht die Skills, die für skalierte Projekte essenziell sind.
Das Thema Skills hat einen großen Haken: Es fängt bei jedem selbst an. Hat man selbst die Skills, um in einem großen Projekt arbeiten zu können?
In diesem Video spreche ich über die Skills, die aus meiner Sicht für große Projekte unerlässlich sind. Ich hoffe, das Video bringt ein wenig Klarheit und ihr könnt mit der grundlegenden Idee etwas anfangen. Im nächsten Video werde ich erklären, was ich mit skalierter Produktentwicklung meine.
 

 
Buchcover Scrum-Think bigWenn ihr mehr über das Skalieren erfahren wollt: In meinem neuen Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” geht es genau darum.

Video: Skalieren – Infrastruktur – Verteilt euch!

Viele glauben, große Projekte mit Scrum bräuchten einen anderen, skalierten Scrum-Framework. Naja, Zertifizierungen zu LeSS, SAFe, Nexus oder Scaled Agile sind ein einträgliches Geschäft. Meine Erfahrung zeigt: Mehr als ein paar gute Best Practises finden sich in diesen Frameworks nicht. Die Frameworks bewirken auch nicht, dass und ob ein großes Projekt skaliert. Vielmehr ist es die Architektur, die die Voraussetzungen für wirklich skalierte Projekte schafft. Darüber hinaus ist eine Infrastruktur nötig, die

  1. Kommunikation und
  2. ständiges Zusammenbauen

ermöglicht. Das Thema Infrastruktur ist sehr umfassend und in dem Video kann ich nur einen ersten Einblick geben. Ich hoffe, dass es euch etwas Klarheit bringt und ihr mit meinen Metaphern etwas anfangen könnt 😃 . Im nächsten Video werde ich dann erklären, was ich mit Skills und Know-how meine.  

 
Buchcover Scrum-Think bigWenn ihr mehr über das Skalieren erfahren wollt: In meinem neuen Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” geht es genau darum.
 
 

Video: Skalieren – Grundideen

 
Agile Skalierungsframeworks versprechen schnelle und einfache Lösungen, diese vorgefertigten Strukturen führen aber nicht zum eigentlichen Ziel: dem agilen Unternehmen.
Bei der Skalierung von Scrum geht es nicht um die Multiplikation einer Methode, sondern um einen neuen Blick auf das große Projekt als fraktal skalierte Organisation.
Gefragt sind entkoppelte Produktarchitekturen, das konsequente Denken aus der Sicht des Kunden, das Projektmanagement-Office als umsichtiger ScrumMaster, die Lust auf frische Skills, gestützt von modernen Infrastrukturen. Und schließlich braucht es eine Führung, die ihre wichtigste Aufgabe darin sieht, Zusammenarbeit über alle Ebenen hinweg zu ermöglichen.
Erfahrt in meinem Video mehr zu den grundlegenden Building Blocks einer Skalierung.
 

 
Buchcover Scrum-Think bigWenn ihr noch mehr über das Thema Skalieren erfahren wollt, kann ich euch mein neuestes Buch empfehlen: “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”
 
 
 

Mein Scrum ist kaputt

 
Kennt ihr schon die Website www.meinscrumistkaputt.de? Nein? Ihr solltet mal reinschauen, denn dort findet ihr Podcasts zu Themen wie:

Die sind spitze, ich habe in einige reingehört und war begeistert.
 
Buchcover Scrum-Think bigDeshalb war ich sehr erfreut, als Dominik Ehrenberg, einer der Initiatoren von Mein Scrum ist kaputt, auf mich zukam und mich bat, mit ihm einen Podcast über mein neues Buch “Scrum Thing b!g. Scrum für große Projekte, verteilte Teams und verschiedene Kulturen” zu machen.
Im Interview mit Dominik erfahrt ihr einiges über die Ideen, die zu meinem Buch geführt haben. Hört doch mal rein: zum Podcast
Vielen Dank an das Team von Mein Scrum ist kaputt.
Boris

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 neues Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” neugierig gemacht habe.
 

Video: Scrum 3.0 – Der Framework der Skalierung

Große Projekte skalieren dann, wenn Voraussetzungen geschaffen werden, die übrigens auch für die agile Organisation im Allgemeinen gelten. Dazu braucht man keine Frameworks wie SAFe oder LeSS, die lediglich über den Prozess skalieren.
Bild (Organisations-)Architektur
 
Wie ihr in dem Bild seht, geht es darum, eine geeignete (Organisations-)Architektur zugrunde zu legen und die einzelnen Organisationseinheiten sowohl technisch als auch kommunikativ mit einer unterstützenden Infrastruktur zusammenarbeiten zu lassen. In den meisten Fällen gelingt weder das Erste noch das Zweite, weil die Menschen oft noch nicht die geeigneten Skills haben, um mit diesen neuen Architekturen und/oder Infrastrukturen umgehen zu können. Klar, das lässt sich lernen, muss aber eben auch getan werden.
Dann stellt sich schnell heraus, dass die Skalierung großer Projekte ein umfassendes Produkt-Know-how erfordert, zumindest muss man sich die Bedürfnisse der User genau ansehen. Design Thinking unterstützt diesen Prozess.
Beim Management all dessen kommen moderne Frameworks zum Einsatz. Ob Kanban agil ist oder nicht, spielt keine Rolle – es erzielt die richtigen Effekte. Wie wir inzwischen wissen (z.B. durch Frederic Laloux), kann es schlussendlich nur gelingen, wenn die Führung einer Organisation diese Neuausrichtung zulässt. Eine skalierte agile Organisation, die fraktal skalieren will, braucht daher eine Führungsspitze, die bereit ist, die entsprechenden Fundamente zu legen.
Im Video erläutere ich kurz, wie all das zusammen hängt.
 

 
Buchcover Scrum-Think bigWürde mich freuen, wenn Euch das Video auf mein neuestes Buch: Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen, neugierig gemacht hat und ihr an meinem Webinar “Skalierung” am 02.03.17, 15-16 Uhr teilnehmt – zur Anmeldung.
 
 
 

Interview mit Jürgen Margetich

 
Jürgen Margetich ist einer unserer Executive Consultants und Co-Autor von “Das Scrum Prinzip – Agile Organisation aufbauen und gestalten”. Bei seinen Kunden arbeitet Jürgen auf Vorstandsebene und begleitet Transformationen ganzer Unternehmensbereiche. Seine Kunden sind anspruchsvoll und haben gelernt, mit Beratern auf eine ganz bestimmte Art umzugehen. Unser Ansatz ist ein wenig anders und irritiert oft, denn wir verlangen, dass Führungskräfte selbst ins Tun kommen, statt alles an die Berater auszulagern. Welche Erfahrungen hat Jürgen bei der Arbeit im skalierten Umfeld gemacht?
 
Jürgen MargetichBG: Jürgen, was macht dich zu einem besonderen Scrum/Agile Consultant und wie bist du überhaupt mit Scrum in Berührung gekommen?
Jürgen: Scrum habe ich 2003 kennengelernt, als ich für ein anderes Beratungsunternehmen den Stage-Gate-Prozess eines Innovationsprojekts bei einem Telekom-Kunden begleitete. Die erste Begegnung hat mich etwas irritiert. Erst nachdem ich mich intensiver damit auseinandergesetzt hatte und wir zusammen das Scrum-Cooking für deine Trainings entwickelt haben, habe ich Agilität und Scrum für mich entdeckt.
Seit 1998 bin ich als systemischer Management-Coach, Unternehmensberater und immer wieder auch mit eigenen Ideen und Unternehmen aktiv. Ich kenne das Ringen um Ideen und Erfolge aus beiden Perspektiven. Moderne Führung wie auch Beratung, systemisches Coaching und agile Organisation haben für mich eines gemeinsam: Sie bauen immer auf die Selbstorganisationskraft der Kunden bzw. Mitarbeiter und Kollegen, führen stark und lateral. Und darin konnte ich mich in den letzten Jahren gut üben. Erst kürzlich bekam ich in einer Session beim Kunden folgendes Feedback: “Du bist immer präsent, mit deiner ruhigen Ausstrahlung und Art führst du uns. Man merkt, du hast immer ein Bild vor Augen, einen Plan, und führst uns Schritt für Schritt. Und du gibst deinen Plan auch mal auf, um das zu übernehmen, was in der Gruppe entsteht, wenn es eher zum Ziel führt.” Das ist natürlich ein schönes Kompliment und ich freue mich, wenn ich so wahrgenommen werde.
 
BG: Sag, wir bei borisgloger consulting arbeiten ja schon immer in großen skalierten Umfeldern. Aber was unterscheidet deiner Meinung nach die Arbeit in einem wirklich großen Umfeld von der Arbeit mit vielleicht 20 Personen?
Jürgen: Die ersten Worte, die mir dazu in den Sinn kommen, sind “Complexity” und “Ambiguity”. Beide Worte sind Teile des jetzt so gängigen VUCA-Begriffs (volatility, uncertainty, complexity, ambiguity). Zuerst zur Komplexität: Eine Organisation wie ich sie begleite und berate, mit mehreren Hundert bis mehreren Tausend Mitarbeitern, ist meist durch sehr heterogene Aufträge und Arbeitsfelder sowie oft intransparente Abhängigkeiten geprägt. Da geht es nicht um ein Projekt oder um ein Programm, sondern um Hunderte, wobei die Linienaufgaben noch gar nicht berücksichtigt sind. Wer da noch glaubt, er könnte mit einem Federstrich die Richtung weisen oder in einer One-Man-Show auftreten, wird an der Trägheit der Masse verpuffen. Systemisches Wirken und stringentes Kommunizieren sind da die Schlüssel. Kommunizieren im Sinne eines verändernden und veränderten Teilhabens an der Kommunikation der Organisation, damit letztlich die richtigen Gespräche und mit diesen die richtigen Handlungen stattfinden können.
Der zweite Begriff drängt sich aus dem ersten fast zwingend auf. Ambiguität – die Mehrdeutigkeit. Jeder Inhalt hat in diesem komplexen System fast jede mögliche Intention (polititsch, fachlich, individuell, emotional …). Es lässt sich nicht mehr die eine Wahrheit über ein Phänomen oder eine Situation festhalten. Damit wird das Arbeiten mit vielen gleichzeitigen Wirklichkeiten – also mit der Mehrdeutigkeit – zur Kernkompetenz in der Beratung. Und wieder bedeutet das in letzter Konsequenz, sich als Katalysator für den Kommunikationsprozess einzubringen. Direktives oder deterministisches Denken ist hier noch hinderlicher als in kleineren Gruppen.
Wichtig ist auch zu verstehen, dass wir in kleinen Projekten hierarchisches Denken und Wirken noch gut unter dem Deckmantel “agil” verstecken können. Man tut halt ein bisschen agil. Je größer das System desto offenkundiger werden die Fakes und umso destruktiver ist auch Fehlverhalten auf allen Ebenen. Es ist einfach mehr Masse unterwegs – mehr Kommunikation. For the good or the bad of it.
 
BG: Du arbeitest ja nach unserem Transition Team Modell. Was unterscheidet deinen Ansatz, mit Kunden zu arbeiten, von den Skalierungs-Frameworks LeSS, Nexus und SAFe? Wie sehr hilft da unser eigenes Modell?
Jürgen: Fangen wir mal mit SAFe an. Da gibt es die größte Entfernung zu unserem Modell. Gerade unsere Konzernkunden werden anfangs von SAFe angezogen – kommt einem ja auch bekannt vor. Am Ende aber macht es zu wenig Unterschied und hilft nicht, vom Organisieren ins Machen und Liefern zu kommen. Doch wenn wir eines brauchen, dann ist das eine nachhaltige und kontinuierliche Lieferorientierung. Ganz gleich, ob wir an Produkten oder einer Organisation arbeiten.
Unser Ansatz ist a) werteorientiert und b) fokussiert. Beides ist in meiner Arbeit entscheidend. Ja, man kann den Methodenkoffer mit Checklisten, Anleitungen und Detailrollen vollpacken. Aber am Ende bleibt die Frage: “Haben wir uns mit den richtigen Prioritäten beschäftigt und sie erfolgreich umgesetzt? Oder sind wir im drüber Nachdenken verblieben?” Erst letzte Woche hatten wir in einer Arbeitsgruppe eine Entscheidung zu treffen: Wollen wir die restliche Zeit darüber sprechen, wie das Konzept auszusehen hätte, was man machen müsste? Oder bauen wir einen Prototypen, mit dem wir in die Kommunikation und Verprobung in der Organisation gehen? Wir haben uns für den Prototypen zur Kulturveränderung entschieden, wir bekamen sofort Feedback und einzelne Leute haben das “Produkt” mit in ihre Teilorganisationen genommen.
Keine Frage, jedes Vorhaben braucht einen angemessenen Plan, ein strukturiertes Vorgehensmodell und die richtigen Werkzeuge. All das muss so eingebracht werden, dass es den Blick auf das Wesentliche nicht verstellt, sondern fokussiert und unterstützt. Unser Ansatz macht das.
 
BG: Bei einer agilen Transition gibt es einige Dinge zu beachten, aber was sind deiner Meinung nach ein oder zwei besonders wichtige Dinge? Welche Tipps kannst du uns geben?
Jürgen: Die erste Sache wäre “Leadership bottom up”. Erst wenn Mitarbeiter anfangen, ihre Sprache und ihre Kommunikation mit Vorgesetzten und Experten zu verändern, beginnt die wirkliche Transition. Ein Beispiel: Management und Squad-Team eines Kunden hatten vereinbart, dass das Team jede Entscheidung trifft. Nun kam es zum Review-Meeting. Das Team präsentierte seine Entscheidungen, aber mit welcher Handlungsaufforderung an das Management?

  1. Variante 1 – klassisch: “Was denken Sie über die Entscheidung? Ist das in Ihrem Sinne?”
  2. Variante 2 – partizipativ: “In unserem Rahmen würden wir die Entscheidung so treffen.”
  3. Variante 3 – unschwer zu erkennen die Schlüsselformulierung im Sinne agiler Transition: “Liebes Management, welche Hintergrundinformation oder welchen Parameter können Sie uns zur Verfügung stellen, den wir in unsere Entscheidungsfindung einbeziehen werden?”

Lesen Sie das nochmal in Ruhe durch. Diese Formulierung hält den Frager (das Team) über den ganzen Dialog eindeutig in der Entscheiderrolle und weist dem Management eine Servicerolle zu (mit der Frage nach wichtigen Hintergrundinformationen). Wir haben das mit Management und Team so aufgesetzt und es war ein Schlüsselmoment. Hier kann man Monate der agilen Transition verstärken oder schwächen – durch einen Satz.
Der zweite Aspekt, auf den man achten sollte, ist mit den Träumen und Tabus aller Beteiligten sorgsam umzugehen. Was bedeutet das? Gerade “Agile” ist ein beliebtes Trägerboot für alle möglichen Bestrebungen und Anliegen geworden. Achten Sie darauf, dass die verschiedenen Themen dort behandelt werden, wo es sinnvoll und förderlich ist. Führungsschwäche löst sich nicht mit Agile auf und auch ein Kompetenzmangel wird nicht automatisch kompensiert.
 

BG: Lieber Jürgen, ich danke dir für unser Gespräch. Ich wünsche dir weiterhin viel Erfolg für deine Projekte!

 

Buchcover Scrum-Think bigWürde mich freuen, wenn ich euch auf mein neues Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” neugierig gemacht habe. 

 

Scrum Think b!g – Leserstimme von Anton Jessner

 
Buchcover Scrum-Think bigIch habe Boris Glogers neues Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” gelesen und hatte dabei einige Déjà-vus aus meinen beruflichen Werdegang als Entwickler und später als ScrumMaster und Coach. Sechs davon habe ich ausgewählt, um zu illustrieren, warum die Integration von Anwendern wichtig ist, wie agile Organisationen aus sich heraus entstehen sollen und warum der Mythos “Menschen wollen keine Veränderung” nicht stimmt.
 
Diese und andere Themen machen es unter anderem aus, dass agile Skalierung gelingt und sie werden im Buch sehr anschaulich und zusammenhängend beschrieben. Gerade die Zusammenhänge in ihrer Gesamtheit machen es aus und das finde ich äußerst hilfreich.
 

Déjà-vus

Déjà-vu “Produktentwicklung ohne Einbeziehung des Kunden und Anwenders kann funktionieren, aber nicht gelingen”:

In meiner einstigen Programmiererkarriere um die Jahrtausendwende entwickelte ich zusammen mit drei weiteren Kollegen für knapp eine Million Euro eine innovative Basel-III-Anwendung für Firmenratings. Die Analyse wurde von einem engagierten Projektleiter gemacht und dauerte über ein Jahr. Danach wurde mächtig Funktionalität eingebaut, damals alles State of the Art und testgetrieben. Der Projektleiter war überaus zufrieden und das Produkt wurde mit mehr Funktionalität fertig, als er sich erhofft hatte. Danach bekamen die Anwender das Produkt. Nachdem sie es sich zum ersten Mal angesehen hatten, meinten sie, sie hätten anstelle der komplexen Anwendung lieber nur ein Texteingabefeld, um die Ratingergebnisse einzutragen. Und dann noch einen “Ok”-Button zum Abschließen.
Kein Anwender war vor der Fertigstellung gefragt, einbezogen oder jemals um Feedback gebeten worden. Im guten Glauben war 100 Prozent funktionierende Software produziert worden, allerdings war das Projekt absolut nicht gelungen. Das Produkt wurde kein einziges Mal eingesetzt und stattdessen durch eine Maske ersetzt.
 

Déjà-vu “Anwender und Kunden ins Projekt einbeziehen ist der Schlüssel zum Erfolg”:

In einem EU-Projekt, in dem ich der ScrumMaster war, hatten wir vom ersten Sprint an die Anwender mit dabei. Wir lieferten alle zwei Wochen an 17 Stadtregierungen in England, Frankreich, Deutschland und China Softwareinstrumente für mehr Bürgerbeteiligung mithilfe einer Politikbeteiligungsplattform. Das gelang durch semantische Analysen von Social Media Content.
Es gab eine große Vision und ein paar Epics, in die sie runtergebrochen wurde. Im Laufe von zwei Jahren haben sich die Technologien, unsere Einschätzungen von dem, was das Endprodukt können sollte, und die tatsächlichen Bedürfnisse sehr stark geändert. So hatte eine Stadtregierung den Bedarf nach mehr Feedbackmöglichkeiten für die Bürger. Das haben wir dann allen anderen auch zur Verfügung gestellt. Oder: Twitter stellte sich für die Content-Analyse auf Grund der kurzen Nachrichten als zu wenig aussagekräftig heraus. Stattdessen haben wir Speech-to-Text-Spracherkennung zur Contengenerierung integriert, um das politische Geschehen in regionalen Gebieten zu analysieren.
So waren im Endeffekt alle beteiligten Kunden und Endanwender zufrieden und es konnte mehr Funktionalität umgesetzt werden, als in der Vision vorgegeben war. Das gelang hauptsächlich durch das Mitspracherecht, durch das permanente Feedback und die Benutzung der Software durch die Endanwender (Einwohner) und Kunden (Städte). Um Projekte gelingen zu lassen, ist die Einbeziehung von Anwendern nötig.
 

Déjà-vu “Bedürfnisse der Anwender beobachten bringt mehr als Zuschreibungen und die Mutmaßung, was sie brauchen”:

Die Call-Center-Anwendung für ein österreichisches Telko-Unternehmen sollte die heterogene Anwendungslandschaft in einer einheitlichen Sicht darstellen. Dazu haben wir Call Center Agents mit Videokameras bei ihrer Arbeit gefilmt und nach ihren größten Wünschen gefragt. Damit als Basis haben wir in jedem Sprint herausgefunden, was sie wirklich brauchten, und vor allem, wie viele Klicks welche Teile brauchten. Diese wurden zuerst vereinheitlicht. Das bringt bei 800 Agents enorme Zeiteinsparungen in der Kundenservicierung. So wurden Messungen und Beobachtungen als Basis für Priorisierungen von User Storys genommen.
 

Déjà-vu “Agile Frameworks sind nicht immer der Schlüssel zum Erfolg bei Skalierungen”:

Ich habe selbst miterlebt, wie der Bau einer agilen Organisationen diese verlangsamen kann. Das Management übernahm die Planung und lehnte die Firmenstrategie an das Framework von Leffingwell an. Plötzlich gab es Integrationssprints und ausgeliefert wurde zwar noch zweiwöchentlich, die wirklichen Reviews wurden aber nur mehr quartalsweise wirklich ernst genommen.
Grund war, dass man es nicht schaffte, das Management in den agilen Prozess zu integrieren – ein Scrum of Scrums hätte zu viel Involvement und Beteiligung verlangt. Folge: Die Lieferzeiten wurden immer länger. Durch langsameres Feedback und eine geringere Verantwortlichkeit unter den Teams, die ja nur mehr alle paar Monate integrierten, litt die Qualität enorm und die Gemeinsamkeit ging verloren. Hier wurde das Prinzip Geschwindigkeit als oberste Maxime massiv verletzt.
 

Déjà-vu “Eine agile Organisation entsteht schrittweise”:

Bei skalierten und großen Entwicklungen habe ich als ScrumMaster und Management Coach erlebt, wie hilfreich eine lernende Organisation mit möglichst wenigen Kopplungen ist. Ursprünglich hatten wir 6 Teams mit insgesamt 50 Personen, die jeweils extrem spezialisiert waren. Sprintziele konnten wegen den äußerst komplexen Integrationen selten erreicht werden. Außerdem gab es ein Framework, das von einem Architekten entworfen worden war. Dokumentation, Vorgaben und Sourcecode hatten nichts miteinander zu tun.
Als Maßnahme haben wir eine Community of Practice für Architektur ins Leben gerufen, die ausschließlich für Entscheidungen zuständig war. Alle Entwickler konnten so erreicht und in die Verantwortung genommen werden. Gleichzeitig haben wir beschlossen, dass jedes Team jede Funktionalität bauen können soll. Aus den 6 Spezialistenteams wurden nach ein paar Monaten des Lernens dann im Wesentlichen zwei Arten von Teams, die an zwei Bereichen des Produkts arbeiteten.
Diese Einbeziehung von Verantwortung und das Aufbrechen der Silos wird im Buch auch als sehr zentral beschrieben.

Déjà-vu “Der Mythos, dass Menschen die Veränderung nicht wollen, stimmt nicht”:

Im Bankbereich habe ich eine agile Transition begleitet. Zunächst stieß ich auf Widerstand, weil nur die Teams agil werden sollten, während das mittlere Management daran wenig Interesse hatte. Außerdem waren die Host-Monoliten und ihre Vernetzungen sehr schwer zu entkoppeln und zur Absicherung für permanente Änderungen sehr schwer automatisiert zu testen. Das Team konnte das schlichtweg nicht.
 
Alle diese und noch mehr Déjà-vus hatte ich beim Lesen des Buchs.
 

Effizienz statt Effektivität

Nun zum Buch selbst: Boris Gloger beschreibt darin ausführlich, wie Produktentwicklung im Generellen und Skalierung im Speziellen gelingen kann, nämlich mit der obersten Maxime der Effektivität. Wirklicher Gewinn ergibt sich durch den Fokus auf Effektivität anstelle von Effizienz. Es geht also darum, den Fokus darauf zu richten, die richtigen Dinge zu tun, und nicht so sehr darauf, die Dinge richtig zu tun.
Der Vorteil der agilen Entwicklung liegt demnach nicht darin, dass etwas günstiger wird, sondern dass Kunden immer schneller immer mehr für ihr Geld bekommen, eben das Richtige. Das ist das, was wirklich gebraucht wird und daher einen Mehrwert liefert, was innovativ ist, was einen Wettbewerbsvorteil liefert, was neue Märkte erschließt, was Risiko minimiert (im Buch erfolgt Risikobewertung mit Cost of Delay) – das, was die Anwender eben wollen.
Aber auch das, was die Menschheit weiterbringt, sowohl in Form von Erfolgserlebnissen bei den Entwicklern als auch von sinnvollen Produkten für die Anwender und Anwenderinnen. Wenn beides aufeinandertrifft, bringt das Motivation und Kreativität durch Sinngebung.
 
Was sind aber nun die richtigen Dinge und wer entscheidet, was die richtigen Dinge sind?
Nicht der Product Owner oder der Kunde weiß das, sondern die Anwender und Anwenderinnen. Diese arbeiten ja mit dem Produkt. Laut Boris Gloger sollte man aber nicht die Anwender fragen, was sie brauchen, denn sie wissen es nicht. Sie spüren es (vielleicht), aber können es nicht ausdrücken.
Beobachte sie daher und identifiziere, was sie brauchen könnten. Baue das möglichst schnell. Stell es ihnen zur Verfügung und reflektiere mit ihnen gemeinsam, ob es das ist, was sie voranbringt. Bleibe an diesem Punkt nicht stehen, sondern wiederhole diese Schritte. Design Thinking eben.
Also nicht schneller arbeiten, schneller tippen, bessere Frameworks, sondern mit der maximalen Geschwindigkeit Produkte bauen, die sinnvoll sind – Effektivität statt Effizienz eben. Die Geschwindigkeitsmaßnahmen sind der Fokus, von dem aus eine agile Organisation aufgebaut werden soll.
 

Entkopplung

Damit aber Produkte sehr schnell in ihrer immer größeren Unterschiedlichkeit robust gebaut werden können, braucht es Teams, die nicht mehr auf Spezialisierungen aus sind, sondern breit gestreutes Wissen haben.
Auch hier wieder: Der entscheidende Ausweg ist ein Denken in Teameffektivität und nicht in individueller Mitarbeitereffizienz, und das über die gesamte Produktentwicklungskette, von der Idee bis zum Einsatz. Wird nicht die gesamte Wertschöpfungskette über das Team hinaus betrachtet bzw. kann das Team aufgrund fehlender Crossfunktionalität diese nicht sehen, führen Optimierungen auf der lokalen Ebene zu Suboptimierungen auf der darüberliegenden Ebene. Dafür braucht es allerdings im Team auch eine entsprechende technische Exzellenz, wie automatisierte Tests und entkoppelte Systeme.
Laut Boris Gloger existiert in den meisten technischen Systemen, ob es nun Soft- oder Hardware ist, eine zu starke Kopplung der einzelnen Komponenten.
Er beschreibt, dass eine Architektur prinzipiell nicht planbar ist, weil man weder zum Zeitpunkt der Planung noch zu einem späteren Zeitpunkt weiß, was das System wirklich leisten soll. Architektur ist etwas Dynamisches und nichts Statisches. Wenn etwas dynamisch strukturiert realisiert werden kann, dann ist das Architektur.
D.h. schnell selbst etwas bauen, einbauen, rückbauen, zubauen, umbauen, erweitern, verringern, testen, herzeigen, reflektieren und anwenden. Wiederverwendung von Software ist kein Mantra mehr, dem alles unterzuordnen ist. Komplexe Frameworks sind oft nicht mehr zu warten und zu unflexibel, um auf ständige Veränderung zu reagieren. Die Demonolitisierung wird zum Monoliten selbst, als geliebtes Baby gesehen, das aber kein Baby mehr ist, sondern ein degenerierter Spross.
 

Hyperspezialisierung als Stolperstein

Und es gibt in vielen Organisationen eine Hyperspezialisierung. Das ist eines der größten Hindernisse, wenn man schnell an Fahrt gewinnen, mit anderen in einer wertschätzenden Art zusammenarbeiten und wirklich entkoppelte Systeme mit einfachen Schnittstellen haben will.
Eine der stärksten Kopplungen passiert durch klassisches Projektmanagement, wo der gesamte Projektverlauf im Vorfeld und alle Produktdetails festgelegt sind. Das beste klassische Projektmanagement der Welt wird demnach nie Erfolg haben, wenn es nicht ständige Veränderung mit einbezieht, nämlich die Veränderung, die das System mit jedem Feedback bekommt.
All diese Spezialisierungen verlangsamen die Projekte und die Produktentwicklung enorm, sind immens kommunikationsaufwändig, müssen demnach übergeordnet koordiniert und geplant werden.
Fragmentierung gibt es auch noch in der Teilung von Kopf- und Handarbeit, sprich zwischen jenen, die sich was ausdenken, und jenen, die das Gedachte umsetzen, was ebenfalls auf das Projektmanagement zutrifft. Geschäftsführung, Management, Product Owner können und müssen nicht mehr alles wissen und sie sollen auch nicht mehr alles entscheiden. Ziel sollte es sein, dass das Management integriert ist und Scrum-Teams in die Selbstorganisation führt und Selbstorganisation von Scrum-Teams und Management gemeinsam gelebt wird.
Also nochmal: Durch Spezialisierung entstehen mehr und mehr gekoppelte Systeme.
Im Wesentlichen ist agile Produktentwicklung aber ein ständiges Lernen von den Experten, den Menschen, die das Produkt entwicklen. Aus dem gemeinsamen Lernen extrahieren kreative Designer mögliche Lösungen, die den Experten dabei helfen, ihre Probleme adäquat zu lösen. Verschiedene Spezialisten arbeiten dann nicht mehr in ihren Silos, sondern in Teams zusammen.
Jede der Lösungen bringt wieder neue Erkenntnisse. Erkenntnisse verändern die Welt ständig und neue Bedürfnisse wecken wieder neue Lösungen. Die Optimierung über diese Spezialisierungen erfolgt meist aus Effizienzdenken und nicht aus einer Effektivität heraus. Anpassungsfähigkeit steht also über Effizienz.
Neu ist auch die Betonung, die im Sprint parallel bearbeitete Anzahl von Dingen ebenfalls zu limitieren, oder noch einfacher: eines nach dem anderen zu committen und ein Single Story Board zu haben.
Die effektivste Form der Abarbeitung ist die sequenziell stattfindende. So erhält man das Wichtigste immer zuerst. Für die Skalierung der Organisation heißt das: So wie die Arbeit des oder der Teams limitiert sein soll, so ist es umso wichtiger, auch auf Portfolioebene die parallele Arbeit zu limitieren.
Neu ist auch das agile Portfoliomanagement mit Scrum. Das Steering Board beispielsweise setzt die grobe Struktur des Programms oder des großen Projekts und wird so zum Product Owner, das Projektmanagement-Office wird zum ScrumMaster und die einzelnen Projektteams zu Entwicklungsstreams.
 

Kein Buch mit Blaupausen

Boris Gloger will mit seinem Buch keine n+1-te Blaupause für Skalierung abliefern. Die gute Nachricht: Die Skalierungs-Frameworks braucht es nicht bzw. sie sind sogar hinderlich.
Bei den Skalierungs-Frameworks à la SAFe oder LeSS wird versucht, möglichst traditionell weiterzumanagen und die Organisation möglichst gleich zu belassen. Stattdessen ist es effektiver, für eine agile Entwicklung eine agile Organisation zu bauen bzw. diese umzubauen.
Eine agile Organisation besteht eben nicht aus vielen agilen Teams, sondern aus den agilen Kommunikationen mit der dafür notwendigen skalierten Architektur. Ein zentraler Bestandteil ist das agile Portfoliomanagement. Agilisierung im Großen mit vielen Teams soll durch gemeinsames Denken entstehen sowie aus den Bedürfnissen der Organisation heraus aufgebaut werden. Frameworks wie SAFe gehen den umgekehrten Weg und nicht immer den Weg einer lernenden Organisation.
Fazit: Ich habe alle Bücher von Boris Gloger gelesen. Dieses ist für mich das eingängigste nach „Selbstorganisation braucht Führung“.
Der einzige Punkt, der für mich nicht klar hervorgeht, ist: Wer gibt jetzt die Richtung wann genau vor? Sind es die Anwender durch das Feedback im Design-Thinking-Prozess oder die Entwickler als wirkliche Experten oder doch wieder alleine die Product Owner? In dem Zusammenhang werden auch mehrere “konkurrierende” Arten der Priorisierung beschrieben, einmal mit Business Value, dann wieder mit Risikominimierung nach Cost of Delay.
Das Buch hat sicher den Level “Advanced”. Es schaut noch mehr hinter die Kulissen und bietet erstmals einen Ausblick auf „Next Organisations“ – mit dem Laloux’schen Farbenmodell ausgedrückt: Scrum wird teal. Es wird klar gezeigt: Wenn man schneller auf dem Markt sein will, hat man sich ernsthaft um Entkopplung zu kümmern, sowohl bei der Technik als auch auf organisationaler Ebene.
Das Buch ist zwar ein Buch über Scrum im Großen, zum Gelingen von Großprojekten mit vielen Teams. Es zeigt allerdings, dass Skalierung im Kleinen beginnt und auch im Kleinen beginnen soll, unter dem Motto: “Das Große ist schon im Kleinen angelegt. Schau auf das Kleine und erkenne das Große.”
Was Boris Gloger noch schafft, ist eine gewisse Entspannung im Methodenstreit. Es gibt nicht das einzig Richtige oder Falsche, sondern jede Organisation muss ihren Weg gehen.
Er zeigt Wege, wie diese Wege beschritten werden können, die es zu gehen lohnt und Ansätze, die es erleichtern. Er weckt weiters auch die Lust, am Thema Organisationsentwicklung dran zu bleiben. Hier gibt es noch viel zu bewegen, zu erkennen, viel rauszuholen und vor allem viel zu feiern. Das Buch zeigt, dass Scrum schon eine weite Entwicklung gemacht hat, dass es sich weiterentwickelt und nie am Ende ankommen wird. Und das ist gut so.
 
Das Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” bekommt von mir 5 von 5 Punkte.
 

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 Medizintechnikgerä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 neues Buch Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen neugierig gemacht habe. Es kommt am 13. Februar 2017 in die Buchhandlungen.