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.
 
 
 
 
 

Interview mit Damla Nalbant

 
Damla ist schon lange bei borisgloger consulting. Sie hat viele Teams in großen und kleinen Unternehmen gesehen und sich in den letzten Jahren auf Scrum-Implementierungen in großen SAP-Umfeldern spezialisiert. Sie orchestriert dann schon mal einige Dutzend Menschen auf zwei Kontinenten. Damla lebt in Wien und fliegt, wie viele Consultants, montagmorgens zu ihren Kunden.
 
Damla Nalbant
BG: Damla, wie ist das so als Scrum Consultant in einem großen Konzern? Gibt es da etwas Besonderes, etwas das anders ist als bei einem kleinen Unternehmen?
Damla: Wenn ich es einfach beantworten müsste, würde ich sagen: Alles ist größer, mächtiger und komplizierter, als es bei einem kleinen Unternehmen je sein könnte. Jeder Prozess und jedes Vorhaben beinhaltet mehrere Schritte, Abteilungen und Personen. Ich habe zwei Großunternehmen in zwei agilen Projekten begleitet und in beiden Unternehmen waren mehrere Hundert Personen beteiligt. Das führt automatisch zu mehr nötigen Absprachen. Entscheidungen können nur über mehrere Hierarchien bzw. Freigaben getroffen werden. Jede noch so kleine Anforderung involviert mehrere Abteilungen, Fachbereiche oder Hierarchien, die diese absegnen, freischalten oder auch nur kennzeichnen müssen, dass sie es zur Kenntnis genommen haben. Es fühlt sich in einem Großunternehmen meistens sehr bürokratisch und langsam an.
 
BG: Du hast dich auf das Gelingen von SAP-Projekten mit Hilfe von Scrum spezialisiert. Was gefällt dir an SAP oder besser, weshalb findest du gerade dieses Feld spannend?
Damla: SAP sagt von sich als Unternehmen, dass es agil ist und seine Produkte agil implementiert. Viele Unternehmen sagen, dass sie ebenfalls agil sind und ihre Projekte agil umsetzen. Wenn man sich die Projekte jedoch genauer ansieht, sind SAP-Implementierungen oft mit langen Laufzeiten, großem Frust und unzufriedenstellenden Ergebnissen behaftet und kaum agil. Viele Projektleiter und Unternehmen kommen gar nicht auf die Idee, ihre SAP-Implementierung agil umzusetzen, da sie der festen Überzeugung sind, dass SAP-Projekte nicht agil umgesetzt werden können. Meistens lautet die Aussage: ”Agil ist schön und gut, aber bei SAP-Projekten geht es nicht.” Für mich persönlich gibt es kein “geht nicht” und umso spannender ist es für mich, Kunden bzw. Neukunden zu erzählen, dass es geht und dass wir mit mehreren SAP-Projekten erfolgreich waren.
Einer der Gründe, warum ich ERP-Projekte agil machen möchte, ist der Wille sowohl des Kunden als auch des Lieferanten, agil zu arbeiten. Wenn diese Voraussetzungen gegeben sind, dann muss man einfach mal machen, und genau an diesem Punkt setzen wir an. In der Umsetzung finde ich persönlich SAP-Projekte sehr herausfordernd, da es meistens Großprojekte sind und mit einigen 100 Personen umgesetzt werden. Agile Skalierung (Skalierungsmodelle) und der Umgang mit fachlicher Komplexität, die vereinfacht werden muss, sind nur zwei Beispiele von Herausforderungen, die in SAP-Projekten auf einen zukommen, und genau diese Herausforderungen treiben mich persönlich an.
 
BG: Du warst lange dabei, als wir bei einem großen Kunden ein agiles Transition Team begleitet haben. Was ist ein agiles Transition Team und wie unterstützen wir so ein Team?
Damla: Ein agiles Transition Team ist jenes Team, das sich mit Impediments der Organisation beschäftigt, die nicht mehr auf der Ebene eines Scrum-Teams gelöst werden können. Diese Impediments können zum Beispiel mehr Bedarf an Trainings und Schulungen sein, aber auch Testautomatisierung oder der Bedarf an agilen Tools. Viele Unternehmen starten mit mehreren Scrum-Teams, die nach einer Weile sehr gut liefern und alles läuft bestens bis zu jenem Punkt, an dem die Teams auf Impediments stoßen, die sie nicht beeinflussen können und für die es auch keine Verantwortlichen im Unternehmen gibt. An diesem Punkt entscheiden sich viele Unternehmen, ein Transition Team aufzusetzen, das wir vor allem in seinen Anfängen unterstützen. Wie sieht diese Unterstützung aus? Wir erstellen gemeinsam mit dem Transition Team ein Backlog, das sich aus den Impediments der Scrum-Teams erschließt. Diese Impediments werden priorisiert und in einem Sprint Rhythmus abgearbeitet und vorangetrieben.
 
BG: Hast du einen Tipp, worauf man bei der Einführung von Scrum im SAP-Umfeld besonders achten sollte?
Damla: Es gibt vieles, das man beachten muss. Die folgenden Punkte stellen sich allerdings immer wieder als große Herausforderungen heraus, unabhängig davon, ob das Projekt agil oder klassisch geführt wird:

BG: Danke für deine Zeit.
 
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.
 

Making of "Scrum – Think b!g" – Teil 3

Buchcover Scrum-Think bigHeute zeige ich euch, wie man über skaliertes Scrum (Scaled Agile) in kurzer Zeit sehr viel schreiben kann. Der Trick besteht darin, Scrum für den Schreibprozess anzuwenden. Wie im ersten Teil des Making of “Scrum – Think b!g” geschildert, habe ich eine Vision und eine grobe Struktur, sozusagen die Epics. Doch dann geht es ans Entwickeln. Das geht bei mir leider nicht in Sprints, weil Schreiben mein Hobby ist – es hat also nicht den gleichen Stellenwert wie Sport, meine Familie (meine Frau und meine Tochter, Haushalt, einkaufen, Instandhaltung, die Pferde meiner Frau), mein Unternehmen (Finanzen, Infrastruktur, Führung), meine Teams (Ausbildung), meine Kollegen (Anleitung und Führung) und meine Kunden (Beraten) oder mein Studium (in dieser Reihenfolge). Erst dann kommt das Schreiben. Es muss also in den Zwischenraum, wo noch ein wenig Platz ist. So wie jetzt gerade 😃 … Meine Frau ist bei den Pferden und reitet mit einer Freundin aus, meine Tochter hängt satt, aber ein wenig quengelig im Tragetuch vor meinem Bauch, ich sitze an unserem Esstisch und schreibe ein paar Zeilen. In diesen Situationen habe ich keine Zeit, lange darüber nachzudenken, was ich schreibe. Produzieren ist beim Schreiben das A und O. Nur was geschrieben ist, lässt sich betrachten, überdenken und überarbeiten.
Und da wir als Scrum-Evangelisten wissen, wie das geht, fängt der Sprint an. Die Timebox dauert so lange, wie meine Tochter friedlich im Tuch sitzt, also etwas über eine Stunde. Dann geht es los. Ich schreibe drauflos. Es fließt von selbst, etwas schreibt in mir. Bevor ich den Satz in den Rechner tippe, weiß ich nicht, was ich schreibe. Genauso war es beim Schreiben des neuen Buchs zur Skalierung. Einfach drauflos. Immer dann, wenn mir ein wenig Zeit blieb, sonntags oder im Zug, im Bus, im Flieger, im Hotel im Frühstücksraum oder im McCafé (das geht echt gut da 😃), habe ich in die Tasten gehauen.
Wie bei allen meinen anderen Büchern lag auch beim Buch zur Skalierung die Kunst darin, ständig zu schreiben, denn sonst musste ich immer wieder nachschauen, wie weit ich gekommen war. Ein Tag Pause war kein Problem. Wenn ich allerdings ein oder zwei Wochen, manchmal ganze vier Wochen nicht am Buch arbeitete, brauchte ich ein bis zwei Tage, um wieder ins Thema hineinzukommen.
Das Schreiben selbst ist nicht das Problem, das Überarbeiten schon. Der Ablauf sieht immer gleich aus: Ich schreibe am ersten Tag drauflos, bis zur Hälfte der Zeit, die ich zur Verfügung habe. Dann sehe ich mir das Geschriebene an und schreibe es oft noch einmal leicht um. Dann schreibe ich weiter. Am nächsten Tag lese ich alles, was ich am Vortag geschrieben habe und schreibe alles wieder um, was mir nicht gefällt. Innerhalb weniger Stunden ist damit schon die dritte Version des Textes entstanden. Nun schreibe ich einfach mit neuen Ideen die nächsten Abschnitte weiter. Ab und zu lese ich noch einmal alles vom Anfang des Kapitels an und schreibe um, was mir nicht mehr gefällt oder wo ich unklar bin.
So geht es in einer Tour, Kapitel für Kapitel weiter. Wenn ein Kapitel fertig ist, gebe ich es Dolores und sie fängt dann an, die vielen Schreibfehler auszubessern und verdrehten Satzwendungen zu entwirren oder ganze Passagen neu zu strukturieren. Sie liest das Manuskript aus der Sicht der Leser und, oh, sie nervt dabei. Immer fragt sie genau an den Stellen nach, die mir selbst noch unklar sind oder sie will Quellenangaben. Das Ärgerliche daran: Es hält auf und bringt mich aus dem Konzept, doch gleichzeitig erhöht das massiv die Qualität des Buchs. So hat sie zum Beispiel eingefordert, dass ich das Kapitel über die Regularien in der Medizintechnik noch einmal genauer ansehe. Oder sie wollte ganz genau wissen, warum ich von einer fraktal skalierten Organisation spreche – mir war es zwar klar, aber ich hatte es für die Leser nicht nachvollziehbar genug herausgearbeitet. Wenn ich das Manuskript inhaltlich abgeschlossen habe, ist aber noch lange nicht Schluss. Dolores bearbeitet das gesamte Manuskript einmal durch, lässt es ein paar Tage liegen, liest es nochmal durch und macht Feinkorrekturen, gibt es dann ins Korrektorat des Verlages und sieht sich anschließend die Korrekturen an, übergibt danach das fertige Manuskript dem Verlag, prüft nach ein paar Wochen das erste Layout, meldet Änderungen an den Verlag, sieht das zweite Layout durch und gibt es frei. Und dann, endlich, geht mein Buch in den Druck.
Wü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.
 

Making of "Scrum – Think b!g" – Teil 2

In dieser Fortsetzung des Making of „Scrum – Think b!g“ möchte ich euch zeigen, wie es weitergeht, nachdem ich ein neues Buchprojekt begonnen habe. Sobald die ersten Skizzen für die Kapitel fertig sind, beginne ich mit dem eigentlichen Schreibprozess.
Bei mir sind Schreiben und Recherche eines. Ich bemerke beim Schreiben, dass mir Informationen fehlen, oder ich lese noch einmal eine Info an anderer Stelle nach, die mich wiederum zur nächsten Quelle führt, die ich lesen muss, damit ich dann wieder etwas in das Buch einarbeiten kann. Kurz, während ich mein eigenes Buch schreibe, lese ich sicher rund 40 Bücher pro Jahr und unzählige Artikel, Blogposts und Whitepaper. Ich unterhalte mich mit vielen Menschen, und das Wichtigste: Ich wende das, was ich schreibe, immer sofort an. Oder ich tue etwas in der Praxis und das wandert dann sofort ins Buch. Lesen, denken und handeln unterscheiden sich bei mir nur insofern, als es unterschiedliche Ausprägungen der gleichen Intention sind – ich will ein Problem lösen. Meist für den Kunden, dessen Teams oder dessen Management.
Ihr kennt das sicher auch: Sobald man sich mit etwas beschäftigt, gibt es plötzlich unzählige Möglichkeiten, um das Wissen anzuwenden. In den letzten 18 Monaten haben meine Kollegen und ich Scrum in Dimensionen skaliert, von denen ich vor wenigen Jahren nicht einmal geträumt habe. SAFe, LeSS, Nexus, skaliertes Scrum, Scaled Agile etc. hätten uns dabei nicht die Spur helfen können. Doch der in Making of “Scrum Think b!g” – Teil 1 geschilderte Ansatz hat die Manager wirklich großer Organisationen begeistert und so durften wir im Laufe der Zeit sogar bei noch größeren Vorhaben unterstützen, als ich sie in diesem Buch beschreibe.
Und dann passiert beim Lesen das Unerwartete: Ich finde ein Buch oder einen Podcast, der alles zusammenbindet, was ich selbst gedacht habe. So geschehen, als ich kurz davor war, das Schlusswort zu schreiben. Ich konnte das ganze Buch noch einmal ganz anders zusammenfassen, weil ich neue Beispiele für noch größere Organisationen hatte.
Beim Schreiben selbst wende ich eine Technik an, die es mir erlaubt, viel zu schreiben – sehr viel. Wie das geht, erzähle ich euch in meinem nächsten Beitrag.
Wü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.

Making of "Scrum – Think b!g" – Teil 1

Am 13. Februar 2o17 kommt mein neues Buch “Scrum – Think b!g“ … in die Kinos hätte ich glatt geschrieben 😃  – natürlich in die Buchhandlungen.
“Wie machst du das nur? Ein Unternehmen führen, mit Kunden arbeiten, ständig publizieren und nun bringst du auch noch dein siebentes Buch raus?”, fragen mich Freunde und Kollegen immer wieder, wenn sie hören, dass ich mal wieder ein Buch rausgebracht habe. Dolores, meine Editorin, ist nicht nur dafür verantwortlich, dass meine Texte lesbarer werden, sie hat mir auch einmal erklärt, dass ich ein strukturschaffender Schreiber sei. Das heißt: Ich plane ein Buch nicht im Vorhinein im Detail durch, ich sammle nicht zunächst alle Materialien und Informationen und beginne dann erst zu schreiben. Es ist umgekehrt: Ich beginne zu schreiben und entwickle dabei die Struktur und den Inhalt.
Meine Art zu schreiben ist deswegen für viele nicht nachvollziehbar. Wenn ich ein Buch beginne, dann ist zunächst nur eines klar: das Thema. Die Vision sozusagen. In diesem Fall ging es darum, ein Buch über skaliertes Scrum zu schreiben. Ursprünglich wollte ich die einzelnen Skalierungsframeworks wie SAFe, LeSS, Nexus und andere einander gegenüberstellen und dann zeigen, dass diese Frameworks nicht funktionieren und wir etwas anderes brauchen. Ich wollte gewissermaßen meinen eigenen Framework entwickeln.
Tja — und dann kam sie, die Schreibblockade. Es ging nicht. Ich dachte zunächst, es läge daran, dass ich nicht genug über die anderen Frameworks wüsste. Also begann ich zu recherchieren und war gelangweilt. Auf der Agile 2015 wollte ich mich noch von den US-amerikanischen Consultants und ihren tollen Tools und Frameworks inspirieren lassen. Ich stieß auf Nexus, Scaled Agile und was nicht alles.
Tolles Marketing, keine Frage. Doch in meinen Augen war da nichts, was tatsächlich erklärte, wie man nun ein großes Projekt skaliert. Es ödete mich an. Zumal ich wirklich wusste, wovon ich sprach. Ich hatte bereits wirklich große Projekte erfolgreich mit Scrum abgewickelt. Bei dem, was ich hörte und las, war nichts Brauchbares dabei.
Doch ich tue den Consultants unrecht. Es gab eine kleine Gruppe von Agilisten, die ich seit langem kannte und die noch immer auf der Konferenz anzutreffen waren. Sie waren erfolgreich, hatten allerdings keine Frameworks im Angebot. Ich glaube, ihnen verdanke ich den Geistesblitz, den ich wenige Tage später hatte. Ich ignoriere diese Frameworks einfach und mache das, was wirklich erfolgreich ist: Rahmenbedingungen für agile Großprojekte schaffen, statt Blueprints verkaufen.
Meine Schreibblockade war wie weggeblasen und ich zeichnete das neue Buch in mein Notizheft. Ja, ich beginne jedes Buch mit einem Bild, häufig ist es eine Mindmap. Dieses Mal waren es mehrere kleine Zeichnungen, die die grobe Struktur des Buchs ergaben. Zeichnungen lassen mich die Struktur finden. Sie entsteht vor meinen Augen, ohne dass ich vorher weiß, wie die Struktur ist. Eines dieser Bilder war diese erste Skizze, die zwar später zu einer anderen Darstellung führte, sie war aber entscheidend für die Struktur des Buchs.

Was im Bild leicht zu erkennen ist: Agiles Skalieren setzt viel mehr voraus als eine neue Idee darüber, wie die Akteure in einem Scrum-Projekt miteinander umgehen. Agiles Skalieren erfordert ein Umdenken auf sechs Ebenen:

  1. Architektur
  2. Infrastruktur
  3. Know-how & Professionalität
  4. Es erfordert ein neues Produktentwicklungsparadigma
  5. Einen Management-Framework, den ich Scrum 3.0 nenne
  6. Und die fraktale Organisation

Als das klar war, begann ich mit dem Schreiben ….. mehr dazu in einem nächsten Blogbeitrag.
Würde mich freuen, wenn ich Euch auf mein neuestes 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.

"Scrum – Think b!g": Ab 13. Februar 2017 im Handel

Im Sommer 2015 habe ich die ersten Sätze zu meiner Version von Scaled Agile bzw. der Skalierung von Scrum geschrieben. Natürlich dachte ich, dass ich mein neues Buch – “Scrum – Think b!g” – viel schneller fertigstellen könnte, doch es kam anders. Unter anderem habe ich in der ersten Hälfte des Jahres 2015 intensiv an der fünften (5.!) Auflage meines Klassikers “Scrum – Produkte zuverlässig und schnell entwickeln” gearbeitet. Es hat sich übrigens gelohnt: Das Feedback zur neuen Auflage ist großartig.
Doch nun ist er fertig, der Gegenentwurf zu den gerade angesagten agilen Skalierungsmodellen wie SAFe oder LeSS. Meine Lektorin Dolores Omann hat die letzten Korrekturen an den Carl Hanser Verlag übermittelt und gestern ist das Buch in den Druck gegangen. Ab 13. Februar 2017 findet ihr es in den Regalen der Buchhandlungen und natürlich könnt ihr es auch jetzt schon bei Amazon vorbestellen.
Mein ganz besonderer Dank geht dieses Mal an die ersten Kritiker, die mir teilweise schon während des Schreibprozesses wunderbares Feedback gegeben haben, das ich gleich einbauen konnte. Es fühlt sich gut an, ein Buch geschrieben zu haben, das andere lesenswert finden.
Wer wissen will, wie die Skalierung von Scrum im Unternehmen durchführbar ist, abseits der Blaupausen und Marketingversprechungen des agilen Mainstreams, dem lege ich mein neues Buch ans Herz. Viel Spaß beim Lesen!
Hier der Umschlagtext:
 
Scrum Think big//

Viele Mitarbeiter an vielen Standorten sollen gemeinsam ein Projekt agil abwickeln was ist dabei zu berücksichtigen? In kleinen Teams hat sich Scrum als Weg für erfolgreiche Produktentwicklung längst etabliert, doch jetzt geht es um andere Dimensionen. Unter dem Druck der Digitalisierung beginnen selbst Großkonzerne, die Erfahrungen aus agilen Pilotprojekten auf immer größere Teile der Organisation zu übertragen. Agile Skalierungsframeworks versprechen schnelle und einfache Lösungen, diese vorgefertigten Strukturen führen aber nicht zum eigentlichen Ziel: dem agilen Unternehmen.
Boris Gloger zeigt anhand seiner eigenen Erfahrungen einen anderen Weg. 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.

Making of "Scrum – Think b!g"

Das Buch ist geschrieben, noch ist es beim Lektorat, dann muss es ins Layout gebracht und gedruckt werden. Die ersten Kunden fragen mich aber bereits, was denn da drinsteht, in dem tollen neuen Buch zum Thema Skalierung von Scrum. Um die Wartezeit zu verkürzen, dachte ich mir, ich schreibe ein „Making of Scrum – Think b!g“. Den Anfang macht diese Grafik: Sie zeigt, wie ich ein neues Buchprojekt beginne.
Boris_Skalierung1
Zunächst zeichne ich meine Gedanken. Ich male ein Bild und versuche mir vorzustellen, was ich schreiben werde. Die vielen vielen Ideen lassen so ein Bild entstehen. Sind die Skizzen erst einmal gemacht, schaue ich aber anschließend eigentlich nicht mehr hinein. Sie helfen mir nur dabei, das Buchprojekt zu starten.
Entscheidend war aber diese zweite Grafik, die einige Minuten nach der ersten entstanden ist. Sie zeigt schon sehr deutlich, wie ich das Buch aufbereiten werde und welche die wichtigen Themen sein werden. Oben links seht ihr alle Kapitel und einige Aspekte des Buches, die sich durch alle Kapitel hindurchziehen.
Boris_Skalierung2Klar ist auch: Einige dieser Ideen sind im Buch enthalten, andere sind aus dem einen oder anderen Grund nicht mehr enthalten. Wie gesagt, ich sehe mir diese Skizzen nicht mehr an, wenn sie erst einmal gemacht sind. Das Schreiben selbst ist beim Schreiben der Erkenntnisprozess.
Es wird noch eine Weile dauern, bis das Buch im Buchhandel ist. Bis dahin werde ich den einen oder anderen Artikel über die Inhalte des Buches wie gewohnt hier auf unserem Blog veröffentlichen.