Scrum Think b!g - Leserstimme von Anton Jessner

Ich 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.