How to Start? Eine Lese-Liste zum Thema Agile Banking und digitale Transformation

 
In der letzten Woche gab es an dieser Stelle den Beitrag zum Fintech-Buch. Natürlich gibt es in der Zwischenzeit bereits einiges an guter Literatur zum Thema Agile Banking, daher habe ich diese Woche eine kleine Liste an relevanten Büchern zusammengestellt, die mir beim Einstieg geholfen haben. Alle Bücher sind verlinkt und um meinen persönlichen Eindruck ergänzt – viel Freude beim Stöbern.

Tolga Tavlas: “Digital Banking Tips: Practical Tips for Disruptors!”

Dieses Buch bietet einen einfachen und kurzweiligen Überblicks und ist daher ein hilfreicher Einstieg in das Thema des Digital Bankings. Neben Tipps zum Aufbau von Digital Banking als tatsächlich wirtschaftliches Business gibt es auch ein Kapitel, das in einer 360°-Perspektive wichtige Begriffe des Digital Bankings erklärt und in einen Kontext einordnet.

Luigi Wewege: “The Digital Banking Revolution: How financial technology companies are rapidly transforming the traditional retail banking industry through disruptive innovation”

Auch wenn ich dieses aktuelle Buch (erschienen im Dezember 2016) nur angelesen habe, kann ich es für einen Einstieg in das Thema empfehlen, da es einen guten Überblick über die Transformation des Bankings gibt. Im Gegensatz zum ersten Buch fokussiert sich dieses im ersten Teil auf die Chronologie der Transformation, die durch Technologie und Tech-Firmen ausgelöst wurde, um im zweiten Teil ein paar der wesentlichen aktuellen Fragestellungen aufzuzeigen und zu beantworten. Auf der Plattform Vimeo ist eine Hörbuch-Probe verfügbar.

Jonathan McMillen: “The End of Banking: Money, Credit, And the Digital Revolution”

Umfassende Lektüre mit ausführlichem Hintergrund, warum das Bankgeschäft so wie es heute funktioniert, nicht weiter überlebensfähig ist. Im Gegensatz zu den Büchern von Wewege und Tavlas dreht sich dieses Werk vor allem um finanz- und volkswirtschaftliche Aspekte und weniger um Digitalisierung durch neue Technologien. Die Ansätze sind durchaus radikal und einige davon bestimmt noch viele Jahre von ihrer Praktikabilität entfernt. Nichtsdestotrotz hilft die fundierte Zukunftsanalyse beim Design aktueller Geschäftsmodelle.

Paul Vigna, Michael J. Casey: “Age of Cryptocurrency: How Bitcoin and Cybermoney are Overturning the Global Economic Order”

Fakt ist: Die Blockchain-Technologie wird Auswirkungen auf die Finanzbranche haben. Nicht umsonst tüfteln diverse Großbanken an den Möglichkeiten der Nutzung dieser Technologie für ihre Geschäftsmodelle. Über Blockchain-Techniken und insbesondere die Kryptowährungen Bitcoin gibt es mittlerweile zahlreiche Bücher. Ich habe mich für dieses entschieden, da es einerseits einen guten technischen Überblick liefert (ohne zu tief abzudriften) und andererseits weitere Anwendungsmöglichkeiten der Blockchain-Technologie analysiert und damit verbundene Auswirkungen aufzeigt.
Viel Spaß beim Lesen!
 
PS Nächste Woche erscheint mein nächster Blog zum Thema Agile Banking.
 
 

Was Banken von Start-ups lernen können

 
Cover_TheFINTECHBook.pdfLetztes Jahr hatte ich im Rahmen der Vorstellung von „The FINTECH Book“ in Wien die Möglichkeit, einen Vortrag über die Zusammenarbeit von Finance Start-ups (sog. Fintechs) und Banken zu halten, und dabei mit vielen Gründern von Fintechs ins Gespräch zu kommen.
In meinem Vortrag habe ich einmal mehr dafür geworben, als Bank diese Start-ups nicht nur als Bedrohung wahrzunehmen. Viele verstehen hinter einer Partnerschaft und Kooperation nur den Austausch von Wissen zu Produkten, Lösungen & Technologien. Was oft zu kurz kommt, ist die Tatsache, dass Banken auch oder gerade von Fintechs viel über die Arbeits- und Herangehensweise an Produktentwicklung lernen können.

Spirit never dies … oder doch?

Da wäre zum einen dieser leidenschaftliche Spirit, mit dem die gesamte Mannschaft eines Start-ups hinter dem Vorhaben steht. Diese Leidenschaft ist in vielen Banken eingeschlafen, sodass nach Möglichkeiten Ausschau gehalten werden muss, sie wieder zu beleben. Gelingen kann das mit tatsächlich motivierenden Visionen und der Einladung, die Lösungen mitzugestalten, um eben diese Vision zu verwirklichen. Aus „Push“ wird „Pull“ – die Chance, dass aus seelenlosen Maschinen wieder begeisterte Mitarbeiter werden, ist real.
Gerade der Finanzbereich befindet sich in einer einzigartigen Wandlung. Neben neuen gesetzlichen Anforderungen, die die Regulatorik betreffen, macht die fortwährende Niedrigzinspolitik innerhalb der Eurozone den Banken starke Schwierigkeiten. Das bisherige Geschäftsmodell funktioniert nicht mehr und wird fortlaufend in Frage gestellt. Dementsprechend werden disruptive Lösungen gesucht und forciert, die allerdings ohne breite Zustimmung im Kundenkreis implementiert werden. Mit einer mitreißenden Vision kann man aus diesem Fahrwasser ausscheren und den Spirit wieder aufleben lassen. Hochmotivierte Mitarbeiter schaffen es zudem viel eher, auf den Kunden einzugehen und ihm die Maßnahmen besser zu erklären.
Ein zweiter Erfolgsfaktor hinter dem Spirit des Start-ups ist die Größe. Es fühlt sich an wie eine kleine Familie, die gemeinsamen Hochs und Tiefs verbinden. Die Kollegen haben großes Vertrauen zueinander. Damit geht die Verteilung der Verantwortung auf jene Personen einher, die tatsächlich an der operativen Basis arbeiten.

„Don’t move information to the authority – move authority to the information“ – David Marquet

In agilen Methoden bedeutet das, dass die tatsächliche Wirtschaftlichkeitsverantwortung dem Product Owner, der Rolle mit der Vision, übergeben wird. Dem Team wird die Verantwortung übertragen, über die Umsetzung zu entscheiden und damit auch für die Qualität der Lösung zu sorgen.
In einzelnen agilen Methoden gibt es noch eine dritte Rolle, jene des Agile Coaches oder ScrumMasters. Diese Rolle verantwortet die Produktivität/die Schnelligkeit des Teams. So ergibt sich ein natürliches Spannungsverhältnis, in dem Produkte idealerweise möglichst ausgewogen entwickelt werden. Viele Unternehmen haben gerade mit der Rolle des Business-Verantwortlichen ihre Probleme – wie können diese tatsächlich verantwortlich sein, fehlen ihnen doch die dazu notwendigen Daten und viel zu oft auch das wirtschaftliche Gespür. Meines Erachtens können sich in diesem Bereich gerade die Banken hervorheben, deren Mitarbeiter durch ihre finanzielle Expertise in der Welt der Zahlen zuhause sind.

Trial & Error … and try again?

Durch kurze Iterationen zwingen agile Methoden ein Entwicklungsteam regelrecht dazu, in der Lösungsfindung kreativ zu werden. Immerhin gilt der Anspruch, nach der Iteration einen Nutzen für den Anwender erzielt zu haben. Das führt dazu, dass Teams kreativ werden und sich diverser Prototyping-Methoden bedienen. Das aus gutem Grund – wir schreiben das Jahr 2017. Selbst in der Hardware-Entwicklung sind schnelle Prototypen mit Hilfe von 3D-Druckern möglich. In Projekten, in denen mobile Anwendungen programmiert werden, können wir anfangs auf Papier-Prototypen zurückgreifen. Und in Organisationsentwicklungsprojekten bedienen wir uns anderer Mittel, beispielsweise Lego. Verprobt wird das Ganze direkt in der Filiale bei den Kunden, um so „echtes“ Feedback für die Weiterentwicklung zu generieren (siehe auch Nordstrom’s Innovation Lab). Es ergeben sich gleich mehrere Vorteile, wenn das meistens flächendeckende, stationäre Filialnetz der Banken dazu genutzt wird: Der Anwender, also in unserem Fall der Bankkunde, wird direkt in die Entwicklung eingebunden. Für die Banken werden sogar neue Formen der Kundenbeziehung aufgebaut, aus denen sich wiederum neue Verkaufsmöglichkeiten ergeben können. Und schließlich können die “Points of Sales“ nicht nur zur Erprobung einzelner Produkte und Ideen herangezogen, sondern auch für eine gänzlich neue Form des Marketings genutzt werden.
Eine weitere Besonderheit von Start-ups und Fintechs ist, dass diese nicht nur ihre Lösung iterativ weiter entwickeln, sondern dieses Prinzip auch ihrem Geschäftsmodell zu Grunde legen – stets auf der Suche nach dem noch Besseren. Aus dem Lean-Start-up-Gedanken entstammt ein Modell, in dem Ideen entwickelt werden, um diese anschließend zu verifizieren und daraus zu lernen. Wichtig ist: Jede Funktionalität für Ihr Produkt, jede Idee für Ihr Business ist immer nur eine Hypothese, die in der echten Anwendung verifiziert oder falsifiziert werden muss. Agile Methoden erlauben eine kontinuierliche Umpriorisierung in jeder neuen Iteration. So wird die Möglichkeit geschaffen, als Unternehmen bzw. als Team, das eine Lösung zur Verfügung stellt, wirklich flexibel zu agieren und sich ändernden Rahmenbedingungen anzupassen. Gerade in Zeiten der Niedrigzinspolitik ist die Suche nach neuen Geschäftsfeldern und damit neuen Einnahmequellen für Banken essentiell. Wichtig ist, den Mut zu haben, unkonventionelle Wege zu gehen und so neue Ertragsmöglichkeiten zu identifizieren, die ein Alleinstellungsmerkmal erlauben.

Integration – how to?

Doch wie können diese Ideen nachhaltig in großen etablierten Banken integriert werden? Ich stelle hier häufig die Metapher eines “Inkubator“-Modells vor. Im Wesentlichen geht es darum, ein erstes „Pilotprojekt“ auszuwählen und den agilen Samen zu setzen, also ein erstes Team mit einer klaren Mission und klaren Rollenausprägungen zu etablieren. In weiterer Folge sollen in diesem Projekt die agilen Methoden ausprobiert und evaluiert werden. Um es „wachsen“ zu lassen, braucht es in der Regel ein Management-Team, das dem Pilotprojekt bei Hindernissen zur Seite steht, um diese zu lösen. Wurden erste Erfolge erzielt, müssen diese „Good Practices“ in die Organisation transferiert werden, um weiteren Teams die Arbeit mit agilen Methoden zu ermöglichen. Auch in diesem Zusammenhang ist es wichtig, Mut zu haben und neue, andere Dinge auszuprobieren, die so noch nicht in einer Großbank durchgeführt wurden.
Ich denke, dass sich der Weg der Reise hin zu einer agileren Bank lohnt. Mit Hilfe der agilen Werte und Methoden und deren richtigem Einsatz können viele der erhofften Vorteile – insbesondere die Nähe zum Kunden, die kürzere Time-to-Market und eine flexiblere Planung – erzielt werden. Tatsache ist, dass die Reise anstrengend wird und viele alte Denkmuster durchbrochen werden müssen. Auch müssen wir uns von den Rucksäcken der Vergangenheit befreien und wenn notwendig, Relikte entsorgen, um Neues entstehen lassen zu können.
 

Interview mit Christoph Schmiedinger

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

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

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

Was hatte ich erwartet?

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

NEIN.

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

Alte Wunden

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

Thema Vertrauen

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

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

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

Die fraktal skalierte Organisation

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

Und so sollten Sie dieses Buch lesen

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

Interview mit Hélène Valadon

 
Foto_Helene_Valadon_borisgloger
Hélène Valadon arbeitet bei uns mit den ganz großen Kunden, den DAX® Konzernen. Da werden ganze Bereiche umgebaut, Hardware entwickelt oder mal eben Projekte mit hundert Leuten und mehr gestartet.
Boris: In “Scrum Think b!g” spreche ich ganz bewusst davon, dass Blaupausen beim Skalieren großer Projekte nicht helfen. Du warst u.a. in Trainings bei Dean Leaffingwell (SAFe) und Craig Larman (LeSS). Sind diese Skalierungsframeworks aus deiner Sicht nützlich?
Hélène: Craig Larman spricht mir von der Seele, denn er sagt “Skalierung ist Deskalierung”. Das war auch immer unser Motto. Und er betont: Wenn man eine Organisation ändern will, muss man das gesamte System denken und an das, was es liefern kann. Diese Liefersysteme muss man identifizieren, statt nur in Funktionen und Aufgaben zu denken und dadurch lokale Optimierungen durchzuführen.
Weniger Übereinstimmung finde ich da mit SAFe, denn es bildet im Prinzip die aktuelle Organisation ab und versieht die Positionen mit neuen Rollennamen, die agil klingen. Man bekommt ein Abbild des alten Systems und versucht, die Prozesse zu optimieren.
Larman hingegen spricht von bestimmten Voraussetzungen, die für eine erfolgreiche agile Skalierung gegeben sein müssen, und einen solchen Rahmen steckst ja auch du ab. Es ist nicht nur eine Frage der Methode, man muss auch die Architektur, die Kompetenzen, den Ansatz der Produktentwicklung und schlussendlich die Führung neu denken.
In großen Unternehmen oder großen Projekten merke ich aber oft, wie schnell die zentrale Idee des teambasierten Systems vergessen wird. Diese autonomen, fachlich kompetenten Einheiten muss man aufbauen, damit ein System schnell wird. Sofern es notwendig ist, koordinieren sich diese Teams miteinander. Doch in der Praxis ist seitens des Managements der Drang sehr groß, weiterhin die Steuerung zu behalten und den Teams wenig Autonomie zu lassen.
Gleichzeitig zeigen sich Schwächen in dem, was agile Führung eigentlich tun sollte, nämlich den Rahmen zu schaffen mit einer klaren Antwort auf die Frage: “Was wollen wir liefern?” Die Rückkoppelung mit dem Markt und dem Kunden herzustellen, das ist die Führungsrolle. Nicht das Beharren auf Reportingstrukturen mit zig verschiedenen Ebenen und Schwerpunkten, denn das ist Projektmanagement – das wurde schon entwickelt, da brauchen wir nicht den Namen zu ändern. Bei Agilität geht es um das schnelle Liefern, um klare Wertorientierung und teambasiertes Arbeiten. Die Organisation muss dafür den Rahmen schaffen.
 
Boris: Was ist deiner Meinung nach die größte Herausforderung beim Skalieren von Scrum in Großkonzernen?
Hélène: Wie schon gesagt, das Teamthema. Und dann das Ändern der Blickrichtung von innen nach außen. Mit Innenorientierung meine ich Silodenken und starre Hierarchien. Zu schauen, was draußen passiert und von außen Feedback einzuholen, das ist die große Herausforderung für die Führungskräfte.
Derzeit ist ein Trend zu beobachten: Die Initiative zur agilen Transformation kommt inzwischen sehr oft von den höchsten Führungsebenen. Das ist einerseits gut, weil damit die Unterstützung da ist, allerdings wollen sie dann auch alles gleichzeitig machen. Alle Initiativen sollen agil laufen, die gesamte Organisation soll agil arbeiten. Man will schnelle Lösungen und das am besten wieder einmal durch einen Prozess dargestellt: Wie sollen wir zusammenarbeiten, damit alle sofort agil sind? Das ist wohl das Erfolgsgeheimnis der agilen Skalierungsframeworks, denn das klingt nach solchen schnellen Lösungen.
Wenn plötzlich so viele Initiativen gestartet werden, ohne vorher zu wissen, was agil tatsächlich bedeutet, trifft man täglich auf merkwürdige Situationen. “Wir sind doch jetzt agil” wird zur Ausrede für alles. Dabei wäre es für das Management nötig, andere – anerkannte – agile Unternehmen anzuschauen, sich mit der Literatur zu beschäftigen, Trainings zu besuchen, sich wirklich mit den Prinzipien und Werten beschäftigen.
 
Boris: Gibt es etwas in meinem neuen Buch, das dir besonders gefallen hat?
Hélène: Ja, die Pyramide, die alle Ebenen aufzeigt, auf denen Veränderungen stattfinden müssen – also Architektur, Infrastruktur, Skills, Produktentwicklung und Scrum. Du machst sehr deutlich, dass es hier nicht nur um einen Prozess geht. Weil aber nicht die ganze Organisation auf einmal umgekrempelt werden kann, versuchen wir immer, zuerst kleine Initiativen zu schaffen, in denen die notwendigen Rahmenbedingungen auf den Ebenen, die du nennst, zu einem guten Teil erfüllt sind. So können alle, inklusive Führungskräfte, live beobachten, was mit agil gemeint ist. Die Vorstellungskraft reicht meist nicht aus, man muss es erleben. Bei den Führungskräften arbeiten wir zusätzlich mit Visualisierung, damit in dieser Komplexität die Zusammenhänge klarer werden und vor allem das transparent wird, was geändert werden muss.
 
Bild (Organisations-)Architektur
 
Boris: Transformationen müssen auch noch begleitet werden, wenn wir schon wieder weg sind, am besten von internen Coaches. Wie baust du solche Coaching Teams auf, die man ja für ein Unternehmen mit tausenden Mitarbeiten braucht?
Hélène: Das ist das Wichtigste, dass Unternehmen die Eigenkompetenz aufbauen. Natürlich im Coaching, und da wiederum speziell im Teamcoaching, im Product Ownership und im Leadership. Genau so wichtig sind aber auch Engineering-Praktiken und Produktarchitektur. Wir bilden diese Coaches im Team nach dem Shadowing-Konzept aus:
Die zukünftigen internen Coaches beobachten zuerst, wie wir es machen und nach einiger Zeit tauschen wir die Rollen und wir sind die Beobachter. Am Anfang ist die externe Expertise extrem hilfreich, weil man sich sonst nur im Kreis dreht und vieles nicht sieht, was eigentlich ein Problem ist. Wichtig ist vor allem beim Coaching der ScrumMaster, den Fokus nicht zu einseitig auf die Methode Scrum zu legen, sondern auch Themen wie Architektur, Engineering etc. aufzunehmen.
Boris: Hélène, vielen Dank für das Interview – ich wünsche dir noch viel Erfolg bei deinen Projekten.
 
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: 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.

Die Rolle von DevOps in der Skalierung – Interview mit Andreas de Pretis

 
Logo_25th-floorAndreas de Pretis ist Gründer und Geschäftsführer der 25th-floor GmbH, einem agilen IT-Dienstleister in Wien. 25th-floor ist seit einiger Zeit in der österreichischen IT-Szene als Spezialist für DevOps bekannt. Andreas betreut seit Jahren die Infrastruktur von borisgloger consulting und er hat für “Scrum Think b!g” einen Gastbeitrag beigesteuert.
 
Boris: Andreas, wie lange gibt es 25th-floor schon und was bietet ihr an?
Andreas: Ich bezeichne mich selbst gerne als spezialisierten IT-Allrounder mit einer Leidenschaft für alles rund um Operations, Infrastruktur und Software-Entwicklung. Nach nunmehr fast 19 Jahren in der Branche kann ich auf ein breites Spektrum an Erfahrungen in diversen Positionen und Rollen zurückblicken – vor allem natürlich in meinem eigenen Unternehmen. Die 25th-floor GmbH haben wir Anfang 2004 nebenberuflich gegründet, seit Ende 2005 bin ich “all in”. Seitdem entwickeln wir Individualsoftware und Produkte für unsere Kunden und betreiben diese großteils auf eigener Infrastruktur in Wiener Rechenzentren. Die Wartung und Weiterentwicklung unserer Infrastruktur ist, neben meiner Tätigkeit als Geschäftsführer, nach wie vor mein Job – was sich dank eines hohen Grades an Automatisierung recht gut vereinbaren lässt. Vor allem DevOps – noch bevor das Kind um 2009 herum einen Namen bekam – leben wir eigentlich schon immer, da es für uns die logische Konsequenz der agilen Entwicklung war. Beides ist deshalb bei uns ganz tief in der Firmen-DNA programmiert.
 
Boris: Was hat sich in der IT in den letzten Jahren verändert?
Andreas: Das ist gar nicht so leicht zu beantworten, da unsere Branche bekanntermaßen so schnelllebig ist wie keine andere. Das alles zu beleuchten würde wohl den Rahmen dieses Interviews sprengen. Fakt ist, dass große Unternehmen heute nicht mehr um Themen wie Cloud-Computing (egal ob Public, Private oder Hybrid), Automatisierung auf allen Ebenen, mobile Arbeitsplätze, verteilte Teams, agilen Mindsets und Methoden, neuen Arbeitswelten und schlankeren Prozessen herumkommen.
Ein Beispiel möchte ich aber doch konkret herausziehen: Open Source in der IT. Obwohl Open Source und auch der Einsatz in Konzernen nichts neues mehr ist, merke ich doch, dass es in letzter Zeit massive Bewegungen in diese Richtung gibt. Kein Unternehmen kommt heutzutage mehr ohne Open Source Software, Bibliotheken, Utilities & Tools aus und immer mehr erkennen den Mehrwert angestammter Free and Open Source Software (FOSS) Projekte gegenüber schwerfälligen “Enterprise”-Systemen. Dazu kommt, dass schon seit geraumer Zeit viele sehr große Unternehmen in die Weiterentwicklung von FOSS investieren, ihr eigenes Know-how einbringen, die Entwicklung vorantreiben oder eigene Frameworks und Technologie unter Open Source Lizenzen stellen.
Neben Software betrifft das auch Hardware (Open Hardware, Open Compute Project uvm.). Selbst Microsoft hat sich unter der Führung von Satya Nadella hier massiv gewandelt und gilt mittlerweile als der größte Contributor auf GitHub. Facebook, Google, Spotify, Netflix & Co zählen ebenfalls zu den Top-Mitspielern bei der Entwicklung und Veröffentlichung von Frameworks, Libraries und Tools unterschiedlichster Art.
Als EntwicklerIn kann man sich nur freuen, aus dem Vollen schöpfen, sich idealerweise selbst einbringen und auf die Schultern von Giganten stellen. GitHub hat mit seiner Plattform definitiv einen Bärenanteil an der Entwicklung der letzten Jahre.
 
Boris: Ich bin der Meinung, dass die Infrastruktur für den Erfolg eines skalierten Projektes wesentlich ist. Siehst du das auch so?
Andreas: Da kann ich dir nur voll und ganz zustimmen – und zwar die Infrastruktur auf allen Ebenen: angefangen bei Räumlichkeiten, Ausstattung des Arbeitsplatz, Kommunikation und Zusammenarbeit, Prozessen, Bürokratie bis hin zur Technik und natürlich im IT-Umfeld. Die Infrastruktur muss die Menschen im Unternehmen unterstützen, ihnen helfen, sich auf ihre Aufgaben zu fokussieren, Informationen schnell auszutauschen und Prozesse effizient abzuwickeln. Leider stehen die internen Richtlinien vieler Unternehmen dem oft noch im Weg. Meiner Meinung nach muss Infrastruktur v.a. in großen Projektorganisationen zu einem Gutteil wieder “demokratisiert” werden: Man sollte weniger Wert auf den leider oft schwerfälligen Enterprise-Charakter legen und stattdessen die MitarbeiterInnen einbeziehen und den jeweiligen Kontext berücksichtigen.
Wichtig ist dabei, nicht zu vergessen, dass sich die Infrastruktur ebenso flexibel und rasch weiterentwickeln kann. Eine Blaupause, die vor Jahren einmal abgesegnet wurde, kann nicht für immer gelten. Hier sorgen vor allem veraltete Software-Versionen, Plattformen und Stacks für hohe Workaround-Kosten und einschränkende Arbeitsbedingungen.
 
Boris: Wie wichtig ist aus Deiner Sicht kontinuierliches Liefern?
Andreas: Aus meiner Sicht ist kontinuierliches Liefern nicht nur wichtig, sondern heutzutage unerlässlich. Wer am Markt bestehen will, kommt gar nicht umhin, ständig zu liefern und dementsprechend rasch und flexibel auf Veränderungen reagieren zu können. Abgesehen davon ist User-Feedback das Um und Auf, um in weiterer Folge die richtigen Entscheidungen treffen zu können. Schnelles und kontinuierliches Liefern ist ja dank agiler Software-Entwicklung eigentlich nichts Neues und auch in großen Strukturen keine Wissenschaft mehr. Aktuell gewinnt das Thema durch den Digitalisierungs-Hype, extrem agile disruptive Startups und die Geschwindigkeit der Großen in der Branche endlich an Fahrt, auch in massiven Softwareprojekten und Konzernstrukturen. Liefer- und Releasezyklen von mehreren Monaten bis zu einem Jahr oder darüber hinaus können von keinem CEO mehr hingenommen werden.
 
Boris: Du hast mir mal von einem neuen Paradigma erzählt: Das neue Paradigma: “Infrastructure as a Service. Kannst du kurz erläutern, was sich darunter verbirgt?
Andreas: Das muss schon eine Weile zurückliegen, dass ich dir davon erzählt habe. Neu in dem Sinne ist das nämlich nicht. Wenn man so will, ist “Infrastructure as a Service” (IaaS) das Fundament der Cloud und hat schon einige Jahre am Buckel. Den Anfang hat 2007 Amazon mit seinem EC2 Service gemacht. Mit deiner Frage beziehst du dich aber vermutlich auf “Infrastructure as Code”, die Automatisierung von Server-Konfigurationen bzw. der gesamten Server-Infrastruktur inkl. Umfeldsystemen den gesamten Lifecycle betreffend – ein wichtiger Aspekt v.a. hinsichtlich DevOps.
Sämtliche Systemparameter, Abhängigkeiten, Konfigurations-, Installations- und Deployment-Schritte werden dabei nur noch als Code abgebildet und gescriptet. Es gibt dafür bereits einige sehr gute und erprobte Systeme, die auch mit Enterprise-Support ausgestattet sind. Ein Vorteil daran ist, dass das Setup ganzer Server und Laufzeitumgebungen sehr einfach versioniert, testgetrieben entwickelt und in einer Deployment-Pipeline mit einem CI-System abgebildet werden kann. Ein unerlässliches Werkzeug, wenn die Bereitstellung neuer Systeme nicht mehr Monate, sondern Tage oder Stunden dauern soll oder Teams auch für die eigene Infrastruktur verantwortlich sind.
Das Thema hat in den letzten zwei Jahren durch Docker und die Renaissance von Container-Virtualisierung noch eine ganz neue Dimension bekommen und an Dynamik gewonnen. Laufzeitumgebungen für Applikationen werden nicht mehr klassisch eingerichtet und konfiguriert, sondern als Ganzes an mehr oder weniger “dumme” Server-Umgebungen ausgeliefert. Die Applikation oder das (Micro)Service bringt in sich alles mit, was sie braucht, um korrekt zu funktionieren. Dabei kann gleichzeitig eine Dev-Prod-Parity, die Gleichheit zwischen der Entwicklungs- und Produktionsumgebung (mit allen Schichten dazwischen), hergestellt werden. Ein sehr spannendes Thema, mit dem ich mich seit geraumer Zeit intensiv auseinandersetze.
Zusammenfassen lässt sich das wohl am besten mit: Make deployments boring again!
 
Boris: Was würdest du Kunden empfehlen, die beginnen wollen eine Continuous Delivery Pipeline aufzubauen. Womit starten sie am besten?
Andreas: Der erste und wichtigste Tipp ist, Continuous Delivery nicht als rein technischen Aspekt zu sehen und nicht mit Continuous Integration oder v.a. Continuous Deployment zu verwechseln. Letztere sind lediglich ein Teil von Continuous Delivery. Was die ersten Schritte betrifft, gilt wie so oft: Man muss einfach mal damit beginnen und die entsprechenden (Pilot-)Teams mit den nötigen Ressourcen, Kompetenzen und Freiheiten ausstatten. Wenn die organisatorischen Rahmenbedingungen geschaffen wurden, die Teams und die Menschen in den Teams wieder ermächtigt wurden, eigene Entscheidungen zu treffen und für die Lieferungen auch die Verantwortung zu tragen, dann sind Technik, Automatisierung und die dafür nötigen Skills keine Raketenwissenschaft mehr. Wie so oft gilt: zuerst die Menschen, dann die Prozesse, dann die Tools.
 
Boris: Vielen Dank für das interessante Gespräch.
Andreas: Gerne, vielen Dank für die Einladung.
 
Wer mehr über die notwendigen Tools und die Infrastruktur zur Skalierung von Scrum und agilen Projekten lesen will, findet Andreas’ Beitrag hier und in meinem neuesten Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”:
 
Buchcover Scrum-Think big
 

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”
 
 
 

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.