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 – Die Architektur

 
Ob ein großes Projekt skalieren kann, ist in erster Linie eine Frage der Architektur und nicht eine Frage dessen, ob man LeSS, SAFe, Nexus oder Voodoo anwendet.
Mehr zur Architektur in großen Projekten erzähle ich euch in diesem Video. Nächstes Mal wird es um das Thema Infrastruktur gehen.
 

 
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.
 
 
 

Skalierte Hardware-Entwicklung – Interview mit Matthias Wolf

 
Foto_Matthias_WolfMatthias ist einer unserer Hardware-Spezialisten und arbeitet in den großen internationalen Projekten zum agilen Arbeiten. Besonders wichtig ist ihm dabei, dass Entwickler viel Zeit mit dem Produkt verbringen dürfen und durch häufiges Prototyping wieder mehr Freude an ihrer Arbeit haben.
 
BG: Matthias, inwiefern sind Hardwareprojekte anders als Softwareprojekte? Worauf musst du als Coach besonders achten?
Matthias: Zunächst einmal gibt es mehr mentale Hürden zu überwinden. Oft werden wir mit der Ansicht konfrontiert, dass “das hier nicht geht” und Scrum überhaupt nur in der Software-Entwicklung funktioniere. Dabei waren die meisten frühen agilen Projekte vor allem Hardware-Entwicklungen: Kameras, Kopierer, sogar Autos. Wichtig ist, nicht zu versuchen, die bekannten Praktiken und Vorgehen aus der Software-Entwicklung eins zu eins auf die Hardware-Entwicklung zu übertragen, sondern vielmehr die dahinter stehenden Prinzipien zu beachten. Im Kern geht es doch darum, dass ein Team Ergebnisse liefert und sich und die eigene Arbeit ständig hinterfragt. Das ist in der Hardware genauso sinnvoll und wichtig.
Eine andere Besonderheit ist, dass das “Bauen” tendenziell immer noch länger dauert als bei Software – da ist es oft ja nur mehr ein Knopfdruck. Und auch wenn mit Werkzeugen, wie 3D-Druckern, Laser Cuttern und CNC-Fräsen, die Bauzeiten immer weiter reduziert werden können, ist man von “Sekunden” noch ein Stück entfernt. Feedback dauert dadurch einfach länger. Aus diesem Grund ist es umso wichtiger, dass man sich auf die aktuell wichtigsten Themen fokussiert und offene Fragen möglichst schnell durch kleine, schnelle Prototypen und die damit gewonnenen Daten beantwortet. Oft reicht dafür aber auch eine Skizze, eine Simulation, ein CAD-Modell oder ein Aufbau aus LEGO oder Styropor.
Die Entwickler müssen viele der Möglichkeiten auch erst kennenlernen, da die meisten Tools gerade erst entwickelt werden. Continuous Deployment war in der Software-Entwicklung vor einigen Jahren völlig undenkbar, heute ist das ganz normal – auch wenn es noch nicht jeder nutzt. Ähnlich wird es in der Hardware-Entwicklung sein. Ein Beispiel: Ein Werkzeug, das ich auch nutze, ist https://iotify.io/ Mit virtuellen Sensoren und Netzwerken kann man jetzt schon Internet of Things-Produkte in kürzester Zeit entwickeln und dann schnell Realität werden lassen. Da tut sich in den nächsten Jahren noch einiges.
 
BG: Wie siehst du das: Wie hilfreich ist Scrum auch bei großen Projekten und weshalb? Welche Vorteile hast du mit Scrum gesehen?
Matthias: Gemeinsame Planungen und Reviews über das gesamte Projekt rufen bei Entwicklern immer viel Begeisterung hervor. Endlich haben sie einen Gesamtüberblick und sehen, was die anderen Teams machen. Und sie erkennen, warum sie tun, was sie tun. Leider erkenne ich auch die Tendenz, dass Manager diese gemeinsamen Termine als Zeitverschwendung betrachten.
Gerade zu Beginn wird das Projektziel hinterfragt: Warum machen wir das Projekt? Was wollen wir erreichen? Warum tun wir das überhaupt? Eine Frage, die ich immer wieder stelle: Muss das Projekt überhaupt so groß sein? Kann man sich nicht auf bestimmte Funktionalitäten oder Märkte konzentrieren und so einiges an Komplexität aus dem Projekt nehmen? Leider ist es oft noch so, dass man immer alles will und alles gleichzeitig. Damit macht man sich und den Entwicklern das Leben aber unnötig schwer. Große Projekte benötigen mehr Menschen und das erhöht den Kommunikationsbedarf. Strukturierte Kommunikation über das gesamte Projekt hinweg wird umso wichtiger. Meistens scheitern Projekte nicht an technischen Problemen, sondern an mangelnder Kommunikation oder der Erkenntnis, dass der Kunde das Produkt gar nicht braucht. Gerade da sind Scrum oder Vorgehen wie Lean Startup besonders hilfreich.
 
BG: Du bist sehr in der Lean Startup Community aktiv. Was macht diese Community aus? Welche Ideen heckt ihr da so aus?
Matthias: Generell ist die Bereitschaft, Risiken einzugehen und Fehler zu machen, deutlich höher. Ein Fehler ist keine Schande, sondern eine wertvolle Erfahrung auf dem Weg zu einem erfolgreichen Produkt. Gleichzeitig versucht man aber auch, durch kluges Vorgehen das Risiko zu reduzieren. Oft kann man nämlich Annahmen schon im Vorfeld sehr einfach überprüfen und verhindern, dass man Zeit in sinnlose Entwicklungen steckt. Es ist spannend zu sehen, mit wie viel Energie und Einfallsreichtum die Leute an teilweise verrückte Ideen rangehen. Genauso schnell sehen sie aber auch ein, wenn etwas nicht funktioniert und ein Projekt eingestellt werden muss. Diese Bereitschaft, auch mal zu sagen “Das war jetzt nix!”, ohne gleich einen Schuldigen zu suchen, wünsche ich mir auch in etablierten Unternehmen.
 
BG: Gibt es eine Besonderheit, die man bei agilen Hardware-Projekten im skalierten Umfeld beachten muss?
Matthias: Interdisziplinäre Teams, die sich häufig am Gesamtprodukt treffen, sind besonders wichtig; die Idee ist aber auch schwerer zu vermitteln. Die Distanz zwischen einem Konstrukteur und einem Firmware-Entwickler, vor allem in der Geisteshaltung, ist oft größer als zwischen einem Frontend- und einem Backend-Entwickler. Deshalb ist räumliche Nähe durch gemeinsame Projekträume und Büros sehr hilfreich.
Die Modularisierung des Produkts und die Standardisierung von Komponenten hilft, schnelle Iterationen zu ermöglichen. Dafür ist es auch notwendig, Schnittstellen abzustimmen, gegen die entwickelt werden kann. So kann in einem Sprint ein Modul weiterentwickelt werden, ohne das Gesamtprodukt neu erfinden zu müssen. Oder mehrere Teams können unabhängig an mehreren Modulen arbeiten. Nach wie vor sind Änderungen an der Hardware immer noch teuerer als an Software. Wenn man dem Produktteam jedoch verständlich machen kann, dass Änderungen nicht schlecht sind und man sie am besten von Anfang an vorsieht, steht einem erfolgreichen Produkt wenig im Weg.
 
BG: Lieber Matthias, ich danke dir für unser Gespräch. Ich wünsche dir weiterhin viel Erfolg für deine Projekte.
 
Buchcover Scrum-Think bigWer mehr über das Skalieren erfahren möchte, dem empfehle ich mein neues Buch: “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”.
 

Video: Skalieren – Grundideen

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

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

Mein Scrum ist kaputt

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

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

Scrum Think b!g – skalierte Hardware Projekte

 
Wer über skalierte Produktentwicklung, Scaled Agile, SAFe, Nexus usw. schreiben will, der kommt nicht umhin, sich damit auseinanderzusetzen, dass die wirklich interessanten Skalierungs-Projekte die sind, die sich mit Hardware befassen. Während des Schreibens von “Scrum Think b!g – Scrum für große Projekte, viele Teams und viele Kulturen” wurde mir klar, wie schwer es ist, in einem Buch alles abzudecken – also nicht nur das Skalieren großer Softwareentwicklungsprojekte, sondern eben auch jenes von Hardware-Projekten.
Unsere ersten Erfahrungen mit wirklich großen skalierten Hardware-Projekten haben wir in der Entwicklung von medizintechnischen Geräten gemacht. Dabei mussten viele unterschiedliche Disziplinen gemeinsam liefern. Wir hatten es hier nicht mit dem Problem zu tun, dass einige Dutzend oder Hunderte von Softwareentwicklern miteinander arbeiten mussten. Es war viel komplexer: Ein Elektroingenieur ist nun mal kein Biologe und spricht eine andere Sprache als dieser. Das beteiligte Marketing versteht oft nur Bahnhof von dem, was die Wissenschaftler in ihren Labors wirklich tun und diese wiederum verstehen nicht (oder wollen nicht verstehen), dass sie sich an die zeitlichen Vorgaben der Investoren halten müssen … sonst geht das Geld irgendwann zur Neige. Aber neben diesen kulturellen Aspekten der Skalierung gibt es bei großen und verteilten Projekten noch ganz praktische Probleme: Da gibt es unzählige Abhängigkeiten zu Lieferanten und das Problem, dass die Planung für die Hardware gemacht wurde, als die Wissenschaftler noch gar nicht wussten, was sie wirklich brauchen. Klar sind das nur Prototypen, doch auch die kosten Geld, und sie umzubauen ist nicht wirklich einfach.
Wie kann da Scrum oder eine agile Vorgehensweise helfen? Zunächst: Der Framework zwingt alle Beteiligten dazu, transparent zu werden. Die Kommunikation zwischen den einzelnen Silos kommt durch die Forderung “nach einer Iteration muss etwas Lieferbares da sein” in die Gänge. Häufig kommt es am Ende der einen oder anderen Iteration dazu, dass das geforderte Ergebnis doch nicht eingetreten ist. Das ist dann zwar oft für das Management sehr betrüblich, denn oft liegt es gar nicht an dem Team, dass da sein Bestes gibt, sondern an den organisatorischen Rahmenprozesse. Dann muss das Management in irgendeiner Weise reagieren – und das ist immer unbequem.
 
Buchcover Scrum-Think bigWürde mich freuen, wenn ich euch auf mein neues Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” neugierig gemacht habe.
 

Video: Scrum 3.0 – Der Framework der Skalierung

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

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