Je größer der Rahmen der Veränderung ist, desto lauter wird der Ruf nach Strukturen und Frameworks. Diese führen aber dann häufig nicht zu der erhofften Steigerung der time-to market Wendigkeit und bergen die Gefahr, zum Selbstzweck zu werden. In dieser Keynote berichte ich euch von unserer mehrjährigen Transformationsreise und wie wir mit der Konzentration auf das Wesentliche und gepflegtem Rosinenpicken unseren Weg gehen. Und warum Design darin eine wichtige Rolle spielt.
Wer im Umfeld agiler Skalierung gearbeitet hat, kennt das eiserne Gesetz der Großprojekte: Over budget, over time, under benefits, over and over again.
Dass das immer wieder passiert, liegt daran, dass immer wieder versucht wird, Skalierungsframeworks über Gruppen von Teams zu stülpen, von denen jedes einzelne für sich genommen gar nicht die Voraussetzungen für Agilität erfüllt, weder bei den Kompetenzen noch bei der Technik noch beim Entscheidungsspielraum. Um das zu kompensieren, entsteht eine gut gemeinte Koordinationsschicht, deren Bemühungen sich aber nach und nach als „Bürokratie mit agilen Namen“ verfestigen.
Sinnvoller ist es, zuerst kleine Einheiten agil zu machen und ihnen auf der untersten Ebene Crossfunktionalität, technische Exzellenz und Product Ownership zu ermöglichen. Dafür müssen die dort bereits bestehenden Strukturen entkalkt und flexibel gemacht werden. Ist das erst geschehen, wird es deutlich einfacher, mehrere Teams auf ein gemeinsames Ziel auszurichten, da der Großteil des potentiell bürokratischen Koordinationsbedarfs entfällt. Jetzt wird auch Agilität im Großen möglich.
Der Vortrag richtet sich sowohl an diejenigen, die zum ersten mal das Wagnis agiler Skalierung eingehen wollen, als auch an solche, die bereits damit begonnen haben und sich wundern, warum noch nicht die gewünschten Erfolge eingetreten sind.
Alles soll aktuell agil werden: von der Verwaltung über Start-ups bis hin zum traditionellen Mittelstand. Der agile Wandel wird oft als Heilsversprechen gesehen. Doch ist das wirklich so? Was entscheidet über den (Miss-)Erfolg von agilen Transformationen? Welche Gemeinsamkeiten kann man übergreifend ableiten? Im Vortrag werden die Muster und Wirkungshebel mit dem Fokus auf Best Practice Sharing betrachtet.
Testimonial: Die Kunst der agilen Transformation ist nicht das Runterbeten von agilen Rahmenwerken und Regeln, sondern die Übersetzung dieser in die jeweilige Kultur gemeinsam mit den Beteiligten. Hierzu braucht es Kreativität, Freiraum, Empathie und Mut zur Veränderung. Und die aktive Unterstützung des Managements.
„Wir arbeiten agil! Mit einem Lastenheft können wir nichts anfangen!“
Wir hören das so oder so ähnlich auf den Fluren der Entwicklungsabteilungen, einigen Beteiligten sind die Unterschiede gar nicht bewusst. Dieser Wissensmangel stellt ein Risiko für den Projektverlauf dar. Prinzipiell gilt: Das Lastenheft kommt vom Kunden, das Product Backlog enthält alle Anforderungen an das Produkt.
Kundenanforderungen sind der Input für die Wertschöpfung im Unternehmen. Es ist fahrlässig, diese Anforderungen unbeachtet zu lassen. Jedoch sind Anpassungen an das Unternehmen notwendig, bei der Bearbeitung ist eine Fortschrittskontrolle hilfreich. Das ermöglicht auch pragmatische Schritte, um das Projekt bei drohender Verzögerung wieder in den Griff zu bekommen.
Björn Schorre beschreibt in seinem Vortrag die Zusammenhänge zwischen Lastenheft und Product Backlog. Diese beiden Artefakte sind für ihn kein Entweder-oder. So erläutert er die Übernahme der Anforderungen in die agile Arbeitsweise und gibt somit Denkanstöße für klare Unterscheidung zwischen Kundenanforderungen und interner Abwicklung.
„Ein Agile Coach arbeitet stetig daran, sich selbst überflüssig zu machen.” Schon mal gehört? Klar! Schon mal gemacht? Äh… Genau, das ist nämlich leichter gesagt als getan.
Wir erzählen davon, wie wir uns als Agile Coach Team bei idealo auf die Reise begeben haben, genau das ehrlich und wahrhaftig zu tun. Wirklich. In echt. Dabei berichten wir von den Herausforderungen, denen wir in unserer alten Arbeitsweise in fester Zuordnung der Agile Coaches zu Teams, Projekten und Abteilungen begegnet sind. Vor allem aber erzählen wir, wie nun unsere neue Strategie aussieht, um mit 16 Agile Coaches unsere Arbeit sinnvoll zu skalieren, sodass 400 Menschen in 60 Teams in 17 Areas in 6 Domains die Unterstützung bekommen, die sie brauchen, um die echten Probleme der Organisation zu lösen.
Alle reden von einem agilen Organisationsdesign entlang von Wertströmen. Was sind diese Wertströme eigentlich? Wie sehen solche Wertstrom-Strukturen in Firmen aus, wenn im Falle von Banken und Versicherungen Abteilungen wie Vertrieb und Kundenbetreuung Teil davon sein müssten? Wie passen typische agile Organisationselemente wie Tribes und Release Trains und diese Non-IT Bereiche in diese Wertströme?
Der Vortrag führt kurz in die Grundideen und den Nutzen von Organisationsdesign nach Wertströmen ein. Ein besonderer Fokus liegt auf zwei Praxisbeispielen zur Verzahnung von einer agilen Liefer-/Entwicklungseinheit mit Teams aus Vertrieb bzw. Kundenbetreuung. Mit den Beispielen aus der Praxis zeigen wir, welche Modelle man in der Praxis fahren kann und welche Fehler vermieden werden sollten.
Mit dem Entschluss „wir machen agil“ startete die KfW 2018 ihren Weg zu einer agilen Organisation. Als weltweit größte nationale Förderbank und drittgrößtes deutsches Finanzinstitut wurde sie, ähnlich wie die Partner aus Industrie und Wirtschaft, vor große Herausforderungen gestellt. Der Umgang mit sich schnell verändernden Anforderungen, Effizienz- und Kostendruck bewegten die Bank schlussendlich dazu, den Schritt in die agile Transformation zu wagen. Heute, 4 Jahre später, nehmen die beiden ReferentInnen Sie mit auf eine Bestandsaufnahme: Ist die skaliert-agile KfW nun anpassungsfähiger, kundenorientierter und effizienter?
Ann-Kathrin Müller, KFW IT Change Consultant im Transition Team Scrum (TTS), und Sascha Parastandeh, externer Agiler Coach, geben in ihrem Vortrag einen spannenden Einblick in die Herausforderungen, Fehler und Erfolge auf dem Weg zu einem agilen Unternehmen. Im Fokus stehen in diesem Vortrag die Learnings aus dem Aufsetzen von selbstorganisierten, skalierten Teams, gemeinsam getragener Priorisierung durch neue Portfolioprozesse und einer veränderten Führung im skalierten agilen Kontext.
Dieser Vortrag zeigt zuerst anhand eines Praxisbeispiels auf, wie ein eigenes Framework entwickelt und eingeführt wurde, die Transformation daran aber beinahe scheiterte. Anschließend wird dargestellt, was darauf gelernt werden konnte – also welche Gründe für das Scheitern des eigenen Frameworks verantwortlich waren. Auf dieser Basis wird dann geklärt, in welchen Situationen ein Standard-Framework sinnvoll ist und wann es Sinn macht, ein eigenes Framework zu entwickeln. Es erfolgt die Ableitung einer Hilfestellung, damit andere Unternehmen besser entscheiden können, inwiefern ein eigenes Framework sinnvoll ist.
Veränderungsvorhaben lösen besonders bei Führungskräften häufig Besorgnis oder gar Ängste aus. Kann ich das? Schaffe ich das? Was wird nach der Transformation aus mir und meinem Job?
Ängste können zu Reaktionen führen, die die das Potenzial haben, Transformation maßgeblich zu erschweren oder sogar unmöglich zu machen.
In diesem Vortrag werden Angstauslöser, Coping Strategien und wiederum deren Auswirkung auf den Changeprozess erläutert. Außerdem wird gezeigt, welche Vorgehensweisen Sorgen gar nicht erst entstehen lassen oder, wenn vorhanden, konstruktiv bearbeiten und beseitigen können.
Wenn Transformationen gegen die Wand fahren, liegt es häufig daran, dass Fehlentwicklungen zu spät erkannt werden. Mit den richtigen KPIs und einer guten Mustererkennung in Veränderungsprozessen kann man frühzeitig feststellen, ob die Transformation erfolgreich wird und kann konsequent die richtigen nächsten Schritte einleiten.
In unserem Vortrag berichten wir, welche KPIs wir in unserer Transformation bei PWC Deutschland nutzen und wie datengestützte Mustererkennung zum Erreichen unserer Ziele beiträgt. Anhand konkreter Beispiele gehen wir darauf ein, welche Transformations-gefährdenden Muster wir KPI-gestützt beobachtet haben, wie wir damit umgegangen sind und was wir daraus gelernt haben.
Agilität in einer großen Abteilung mit vielen Entwickler:innen und Stakeholder:innen ist alles andere als trivial! Der Scrum Guide forderte bis 2020 eine Begrenzung der Entwickler:innen auf 9 Personen je Team. Spätestens danach muss per Definition dieses in zwei Teile aufgebrochen werden. Da diese Teams an demselben Produkt arbeiten, teilen diese sich die Anforderungen und je nach Skalierungsframework werden weitere Meetings zur Koordination gebraucht. Auch das Risiko eines gemeinsamen Release des Produkts steigt signifikant an.
Doch wie arbeiten größere Softwareentwicklungsabteilungen mit vielen Entwickler:innen am Anfang ihrer agilen Transformation an einem Produkt? Viele am Markt etablierte große Organisationen setzen hierbei auf Skalierungsframeworks, um Team, Releases und Anforderungen zu koordinieren. Wenn es um diese Frameworks wie LeSS, SAFe und Nexus geht, scheint es immer eine implizite Annahme zu geben: Die Anzahl der Teams ist die Variable, nicht die Komplexität des Produkts selbst.
Doch genau diese Top-down-Ansätze lösen nicht die Probleme eines komplexen Produkts. Das Ziel von Scrum, spätestens nach jedem Sprint Feedback zu der Entwicklung, dem sogenannten Inkrement zu bekommen, wird fast nie erreicht. Die Zyklen zum Lernen werden deutlich länger. Zusätzlich bringen die Ansätze sogar neue Probleme mit sich. Die technischen Abhängigkeiten, die politischen Spiele und die Probleme zwischen den Teams steigen stark an.
Um die Komplexität zu beherrschbar zu machen, muss das Produkt in kleinere, aber jeweils wertstiftende Einheiten aufgebrochen werden. Doch wie kann dieses realisiert werden? Es bieten sich kollaborative Ansätze an, in diesem Fall strategisches Domain-driven Design mit Event Storming und Domain Storytelling. Dabei werden große Systeme bzw. Monolithen in sogenannte Bounded Contexte aufgeteilt. Anhand dieser Kontexte können autonomere Teams und Produkte realisiert werden. Durch die Berücksichtigung von bewährten Kommunikations- und Kollaborationsmustern wie der Sprint Review oder dem Backlog Refinement aus Scrum können die Releases dann relativ einfach team- und produktübergreifend koordiniert werden.
Der praxisnahe Talk greift zwei echte Projektsituationen und Problemstellungen auf und zeigt, wie man gemeinsam mit dem Fachbereich und den Entwicklern zu dynamischen, selbstorganisierenden Einheiten kommt. Nils Hyoma stellt komprimiert die im agilen Projekt in einer hochkomplexen Umgebung gewonnen Erfahrungswerte vor. Er erläutert, wie und weshalb ein gut durchgeführtes strategisches Domain-driven Design zum zentralen Erfolgsfaktor in agilen Projekten werden kann.
Agilität dringt immer weiter in zuvor unerschlossene Gebiete vor. Darunter sind auch die Produktentwicklungsinitiativen der großen Automotive-Hersteller und -Zulieferer. Dabei merken wir, dass es die große Komplexität und die Vielzahl an Abhängigkeiten und involvierten Gewerken agilen Methoden nicht einfach macht, einfach und selbstsicher zum Erfolg zu führen. Das Ganze dann auch noch zu skalieren ist die ultimative Herausforderung, der wir uns unlängst in einem großen Projekt gestellt haben.
Dabei haben wir den End-to-End Wertstrom, von Ideation über Produktentwicklung bis zum SOP hin zur Serienfertigung und dem EOP betrachtet, und Spezifika, die ursächlich aus dem Grad der Unbestimmtheit gegenüber der “richtigen” Lösung resultieren, als Basis für ein passfähiges Zusammenarbeitsmodell gesetzt. Skalierung spielt dabei eine wichtige Rolle, also die Art und Weise, wie passfähige Zusammenarbeitsmodelle von Team- über Bereichs- bis hin zur Unternehmensebene und wieder zurück definiert und operationalisiert werden können.
Conny Dethloff und Christoph Schmiedinger berichten in Ihrem Vortrag über die Erfahrungen des Einsatzes von Agilität in skalierten hardware-lastigen Produktentwicklungsprozessen (PEP) und die Unterschiede zur Softwareentwicklung. Wie müssen Wertströme visualisiert werden, um diese anschließend in verschiedenen kleinen agilen Teams abzubilden? Wie können sich diese Teams synchronisieren, damit am Ende ein „echtes“ Produkt entsteht? Wie muss die kurz- bis mittelfristige Planung aussehen, um den langen Vorlaufzeiten bei Zulieferern Planungssicherheit zu vermitteln? Sind MVPs überhaupt möglich und können Prototypen diesem Gedanken wirklich Rechnung tragen? Und wie lässt sich der ganze Dokumentationsaufwand bewerkstelligen, den sicherheitskritische Applikationen mit sich bringen. Und was hat das Ganze eigentlich mit Lean, Toyota und Monozukuri zu tun?
Freut euch auf einen erfrischenden Vortrag aus der Praxis mit konkreten Beispielen aus echten Produktentwicklungsprozessen.
Kontinuierliche Verbesserung ist die Voraussetzung für das Überleben von Unternehmen. Dafür benötigt es Transparenz, um zu erkennen, wo ein Team oder eine Organisation in Bezug zu einem erstrebenswerten Zustand steht. Darauf aufbauend können Maßnahmen abgeleitet und deren Wirksamkeit überprüft werden. Ein wichtiges Werkzeug hierfür sind Metriken, die uns helfen, eben diese Transparenz herzustellen. Teilweise werden diese immer wieder benutzt, um Teams zu bewerten und darüber zu urteilen was „gut“ und was „schlecht“ ist. Dies führt dazu, dass sich viele Teams mit dem Einsatz von Metriken schwertun.
In unserem Vortrag wollen wir Metriken in erster Linie als das betrachten, was sie sind: Pure Information, die Transparenz ermöglicht und die Chance bietet, dazuzulernen. Anhand verschiedener Praxisbeispiele, die wir in den letzten Jahren in unterschiedlichen Branchen sowie im agilen als auch nicht agilen Umfeld gesammelt haben, zeigen wir, mit welchen Metriken es Teams gelingt, ihre Situation zu sehen, zu verstehen und zu verbessern. Dabei betrachten wir auch die Fallstricke über die viele Teams immer wieder stolpern sowie die Bedeutung psychologischer Sicherheit und die Rolle des Managements.
In diesem Vortrag werden Herausforderungen der agilen Transformation in einer klassischen Organisation aufgezeigt. In Form eines Dialoges beleuchten die Vortragenden konkrete Situationen im Transformationsprozess aus Sicht des treibenden Transformationsteams und bewerten Vor- und Nachteile von gewählten Vorgehensweisen. Mit einem Fokus auf die Startphase der Transformation entsteht so ein praxisnaher Einblick auf den Unternehmenswandel in Richtung „agil“.
Wir schreiben das Jahr 2022 – die gesamte Enterprise-Welt wird von den großen Modellen agiler Skalierung beherrscht. Die ganze Welt? Nein! Als alternativer Weg zur “Skalierung” verfolgt die Kanban Methode den Ansatz, Organisationen als ein Netzwerk “lebender und atmender” Services zu betrachten. Durch die Visualisierung des realen Flusses der Arbeit und Wertschöpfung durch dieses Netzwerk kann die Gesamtorganisation adaptiv und agil mit den Geschehnissen der Außenwelt umgehen. So kann ein großer Wettbewerbsvorteil erlangt werden, gänzlich ohne Modelle, die für Teams gedacht waren. Ohne künstlich zu “skalieren”.
Du fragst dich nun vielleicht, wie solch ein “Network of interconnected, interdependent services” in der Praxis aussieht? Genau das zeigen wir in diesem Vortrag.
