Posts tagged ‘Lean’

ASMM: Agile Scaling Maturity Model

During a presentation of our approach to scaling agile I constructed „Stefans Agile Scaling Maturity Model“ (SASMM, not trademarked) in an ad-hoc fashion: The number of scaling practices you don’t need. It was a joke but I think there might be something behind the curtain.

Let’s start with the Agile Scaling Cycle: We start with reducing dependencies between teams and with the outside context. Then we do some work and need to coordinate the remaining dependencies. During this work we generate insights and detect organizational impediments. These direct us during the further development of the company. The evolved structures and processes of the company give us additional options for reducing dependencies and we start a new loop through the Agile Scaling Cycle. The whole cycle is driven by the agile scaling principles (which are just the agile/lean principles reformulated for scaling; see http://scaledprinciples.org).

Bild

The trick here is to reduce dependencies to the point where coordination becomes dead simple. When we went through the Agile Scaling Cycle several times the company should be more mature, teams should be less dependent and in consequence we need very few coordination practices. Therefore the first formula to compute the scaling maturity on a scale from 0 to 10 (the higher the score more mature) could be:

ScalingMaturityLevel = 10/NumberOfCoordinationPractices

Of course some coordination practices are more agile than others. A dependency matrix is less agile than a shared Sprint Review. So we could weight the practices by the additional weight they put on the process. But that would be another blogpost and in the end I’m not convinced that maturity models are valuable.

April 9, 2014 at 10:28 am Leave a comment

Agile Skalierung: eine Kollage

In diesem Blogpost versuche ich mal eine Sammlung der verschiedenen Sichtweisen auf das Thema agile Skalierung (also der Organisation von agiler Entwicklung, wenn mehr als ein Team notwendig ist).

Scaled Agile Framework™ (SAFe)

Das Methodenframework SAFe von Dean Leffingwell erfährt im Moment viel Beachtung und ist höchst umstritten:

Die deutschsprachigen SAFe-Protagonisten, mit denen ich selbst gesprochen haben, stimmen der o.g. Kritik interessanterweise im Wesentlichen zu. Sie argumentieren aber, dass SAFe trotzdem ein erster Schritt hin zu ein ganz klein wenig mehr Agilität sein kann, dass man SAFe sowieso nicht so implementieren würde, wie es beschrieben ist und dass man direkt nach der Implementierung damit anfangen müsste, es sofort zu ändern (überspitzt: wieder zu demontieren).

Ein SAFe-Trainer meinte, er sähe die größte Gefahr von SAFe darin, dass viele SAFe-Trainer und Coaches Agilität nicht verstanden hätten und daher keinen sinnvollen Einsatz von SAFe sicherstellen könnten. Wer sich tatsächlich für SAFe entscheidet, sollte also viel Aufwand darin stecken, den agilen Erfahrungshintergrund der Trainer/Coaches intensiv zu durchleuchten (das gilt natürlich generell für die Auswahl von Coaches/Trainern). (Vielleicht sollte man sogar prinzipiell immer jemanden mit an Board holen, der SAFe für Unsinn hält 🙂

Disziplined Agile Delivery (DAD)

DAD von Scott Ambler hat lange nicht die Aufmerksamkeit wie SAFe erreicht. Das erklärt vielleicht auch, warum es deutlich weniger Kritik dazu gibt.

Large Scale Scrum (LeSS)

LeSS von Craig Larman und Bas Vodde ist eigentlich gar keine echte eigene Methode, weil schlicht das Scrum-Framework für die Skalierung interpretiert wird.

Agility Path

Agility Path von scrum.org liefert im Gegensatz zu SAFe, DAD und LeSS keine Struktur für skalierte Agilität, sondern definiert den Prozess, wie man zu dieser Struktur kommt. Ähnlich wie SAFe und DAD ist es direkt kommerzialisiert.

Auch bei Agility Path könnte man diagnostizieren “im Westen nichts Neues”. Das, was Agility Path ausmacht, haben Ken Schwaber und andere agile Praktiker schon vor Jahren beschrieben. Man begleitet die Einführung und Ausbreitung von agil kontinuierlich und setzt dafür ebenfalls Inspect&Adapt ein (häufig bildet man ein Transitionsteam dafür).

Enterprise Transition Framework™ (ETF)

Das ETF von Agile42 scheint mir im Grunde fast identisch mit Agility Path zu sein. Vielleicht ist einer der Gründe für die Existenz, dass Agile42 die Scrum-Zertifizierungen der Scrum Alliance anbietet und ein Gegenpol zu Agility Path von der Konkurrenz-Zertifizierungsorganisation scrum.org schaffen wollte.

We don’t need no new methods

Und dann gibt es noch die Gruppe derjenigen, die meinen, dass man für agile Skalierung keine neuen Methoden braucht und schon gar keine mit Trademarks. Die Prinzipien, die wir für die agile Skalierung brauchen, kennen wir bereits seit Jahren. Die Praktiken für die Skalierung sollten schrittweise passend zum Unternehmen gefunden werden. Inspirieren sollte man sich bei der Suche nach geeigneten Praktiken von der Praxis (z.B. bei anderen Unternehmen) und nicht von Methoden. (Dieser Gruppe gehöre ich selbst an).

Was fehlt?

Wenn Ihr noch Ressourcen kennt, die das Bild vervollständigen, hinterlasst mir einen Kommentar zu diesem Artikel. Ich werde den Artikel dann ergänzen.

February 14, 2014 at 10:58 am Leave a comment

Agilität, Skalierung und Kundenbegeisterung

In vielen Fällen reicht es heute nicht mehr aus, mit nur einem kleinen agilen Team an einem Produkt zu arbeiten. Dann müssen mehrere Teams gemeinsam arbeiten. Für die Koordination wurden Frameworks/Methoden wie SAF oder DAD vorgeschlagen. Jetzt gibt es einen weiteren Vorschlag: man braucht gar kein zusätzliches Framework zur Skalierung. Stattdessen sollte man sich an den agilen Prinzipien orientieren und seinen eigenen Weg finden. Zusätzliche Praktiken zur Koordination werden situativ verwendet, wenn sie helfen, die Prinzipien besser umzusetzen. Eine Gruppe von agilen Experten (inkl. meiner Wenigkeit) hat diese Prinzipien zusammengeschrieben und unter http://scaledprinciples.org veröffentlicht. Wer die Prinzipien unterstützt, kann sich dort auch als “Unterstützer” aufführen lassen. Die Skalierungsprinzipien sind in diese Bereiche gruppiert:

  • Begeisterte Kunden
  • Zufriedene produktive Mitarbeiter
  • Globale Optimierung
  • Unterstützende Führung
  • Kontinuierliche Verbesserung

Markus Gärtner hat die Prinzipien zu globaler Optimierung in seinem Blog detaillierter beschrieben und kommentiert. Die Prinzipien zu zufriedenen produktiven Mitarbeitern hat Andreas Schliep detaillierter beschrieben und kommentiert. Ich möchte hier die Prinzipien rund um begeisterte Kunden etwas genauer betrachten:

Begeisterte Kunden sind der Garant für jedes Unternehmen, langfristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, die Grundlage für dieses Wachstum zu schaffen.

Ich meine, dass für Unternehmen der Kundennutzen im Fokus stehen sollte und nicht das Geld. Ich bin (wie viele andere auch) davon überzeugt, dass begeisterte Kunden ein sehr verlässlicher Indikator für den langfristigen finanziellen Erfolg des Unternehmens sind. Ein starker finanzieller Fokus führt hingegen meist zu unzufriedenen Kunden (Qualität von Produkt und Service wird reduziert, um Kosten zu sparen) und damit langfristig zu finanziellen Einbußen. In diesem Kontext waren uns zwei Prinzipien wichtig:

  1. Definiere, was Wert bedeutet schafft
  2. Produziere kleine, lieferbare Inkremente

Definiere, was Wert bedeutet und schafft

Das gemeinsame Verständnis über die wertschöpfenden Elemente muss gerade in einer skalierten Produktorganisation bei allen Mitarbeitern vorhanden sein. Leitbilder helfen dabei, die strategischen Ziele zu erreichen. Ein klares Wertverständnis gibt gemeinsame Orientierung.

Bei der Entwicklung mit nur einem Team ist dieses Prinzip relativ leicht umgesetzt. Das Team arbeitet im direkten Kontakt mit der Business-Seite (Product Owner, Anwender, Kunden) und baut darüber sehr schnell ein Verständnis darüber auf, was die Kundenbedürfnisse sind und wie das entwickelte Produkt diese Bedürfnisse befriedigt. Dadurch steigt die Verbundenheit des Teams mit den Kunden, den Kundenbedürfnissen und dem Produkt. In der Folge bringt das Team selbst Ideen dazu ein, wie die Kunden durch aktuelle Technologien begeistert werden können. Bessere Produkte, begeisterte Kunden und nicht zuletzt zufriedenere Mitarbeiter sind die Folge. In skalierten Umfeldern besteht die Gefahr, dass zusätzliche Hierarchien für die Koordination der Teams eingeführt werden, die die Teams wieder stärker von den Kunden und der Wertschöpfung entfernen. Auch in skalierten Umfeldern sollte jedes Teammitglied wissen, ob und wie das Gesamtprodukt die Kunden begeistert und was der Beitrag des eigenen Teams dazu ist.

Produziere kleine, lieferbare Inkremente

Inkremente bauen aufeinander auf und beinhalten stets den Nutzen und die Funktionalität der vorherigen Inkremente. Daher eignen sie sich ausgezeichnet zur Herstellung und Messung von Mehrwert. Ein lieferbares Inkrement eines Produktes hat somit qualitativ alle Eigenschaften, die man zur Auslieferung braucht, wobei die Produktorganisation Stück für Stück die fehlenden funktionalen und nicht-funktionalen Eigenschaften ergänzt. Im Idealfall kann der Wert eines Inkrements sofort in Nutzen für den Kunden umgesetzt werden. Doch auch wenn das nicht möglich ist, bieten kleine, lieferbare Inkremente die Basis für die kontinuierliche Verbesserung des Produkts, sie minimieren Risiken und reduzieren Komplexität.

Scrum fordert auslieferbare Produktinkremente nach jedem Sprint – es darf keine offenen Restarbeiten an den Funktionalität dieses Inkrements geben. Dadurch werden Risiken effektiv minimiert und es entsteht Transparenz über die reale Leistungsfähigkeit des Teams. Außerdem können Produktinkremente bei Bedarf sofort durch Kunden benutzt werden. Die Time-2-Market reduziert sich. Dadurch wird Feedback aus dem Produktivbetrieb früher generiert und die Wertschöpfung durch das Produkt beginnt früher. In skalierten Umfeldern ist es deutlich anspruchsvoller, lieferbare Produktinkremente zum Sprintende fertig zu stellen. Schließlich müssen dafür die Beiträge aller Teams noch während des Sprints integriert werden. Trotzdem sollte man dieses Ziel auch in skalierten Umfeldern verfolgen. Risikominimierung ist schließlich in skalierten Umfeldern noch wichtiger als für ein einzelnes  Team (der potenzielle Schaden in einem Großprojekt ist einfach deutlich größer). Ich finde hier ein Toyota-Motto hilfreich: “Wenn etwas schwierig ist, mache es häufiger!” Dann wirst Du nämlich lernen, wie es einfacher gehen kann.

January 29, 2014 at 6:15 am 2 comments

How cross-functional should my Team be?

In a Lean/Agile world teams should be cross-functional. Period.
Or maybe it’s not that easy? What does cross-functionality actually mean? And is it true that the more cross-functional, the better?

Bild

I wrote an article together with my brother Arne Roock adressing these questions. The article is published in the current edition of the “Agile Review” by it-agile. The article is available as PDF for download. (There is also a german version of the article).

August 13, 2013 at 5:26 pm Leave a comment

Vorträge “Innovation – das wahre Bottleneck?!” auf der OOP 2012

Auf der OOP 2012 habe ich einen regulären Vortrag sowie ein Pecha-Kucha zum Thema “Innovation – das wahre Bottleneck?!” gehalten.

Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

January 25, 2012 at 9:08 pm 2 comments

XP-Days Germany am 26-28.11.09 in Karlsruhe

XP Days Germany ist die größte deutschsprachige Konferenz zur agilen Softwareentwicklung. Sie findet dieses Jahr vom 26. bis 28. November in Karlsruhe statt.

Einige Highlights:

  • Keynote von Alistair Cockburn
  • Zwei Halbtagestutorials mit begrenzter Teilnehmerzahl
  • Vier parallele Tracks am Hauptkonferenztag
  • Mehrere Pecha-Kucha-Blöcke
  • Community Day mit Open Space und World Cafe

Das detaillierte Programm,den Link zur Anmeldung und zahlreiche weitere Informationen gibt es auf http://www.xpdays.de

Laufende Neuigkeiten über Teilnehmerzahlen, freie Plätze, Programmänderungen etc. werden über Twitter verbreitet. Informationen dazu gibt es hier: http://xpdays.de/2009/twitter.html

Ich selbst werde mit einem Vortrag zum inkrementellen Entwurf und einem Pecha-Kucha-Vortrag zu Stop-the-Line vertreten sein.

Ich hoffe, wir sehen uns auf den XP-Days.

September 18, 2009 at 8:17 am 1 comment

Stop the Line in der Softwareentwicklung

Die Idee, “Stop the Line” in der Softwareentwicklung anzuwenden erscheint Managern und Entwicklern zwar irgendwie einsichtig, aber auch gefährlich. “Sitzt dann der Großteil der Entwickler rum, weil sie nicht effektiv zur Problemlösung beitragen können? Wäre es nicht besser, man würde erstmal seine aktuelle Aufgabe zuende erledigen? Man kann doch die Leute nicht untätig rumsitzen lassen!”

Ich möchte in diesem Blogeintrag versuchen, etwas besser zu erklären, wie man “Stop the Line” in der Softwareentwicklung umsetzen kann. Vielleicht erscheint die Idee dann weniger gefährlich.

Stop the Line der Produktion
Beginnen wir mit dem Ursprung der Stop-the-Line-Idee: Lean Production / Toyota Production System. Tritt in der Produktion ein Problem auf (z.B. Kratzer auf einer produzierten Tür), wird die Produktion gestoppt. Dann wird geprüft, was die Ursache für das Problem ist und diese Ursache wird beseitigt. Und das alles sofort und schnell.

Dieses Vorgehen ist sinnvoll, weil die Ursache für das Problem meistens systematischer Natur ist. Das Wegpolieren des Kratzers beseitigt das ursprüngliche Problem (z.B. Maschine falsch eingestellt) nicht und das Problem tritt bei den folgenden Türen immer wieder auf.

Und es heißt “Stop the Line” und nicht “Stop the Plant”. Bei einem Kratzer hören also nicht alle Leute in der Fabrik auf zu arbeiten. Es hören die auf, die in der Produktionslinie arbeiten, in der das Problem aufgetreten ist.

Es ist nicht sinnvoll, wenn in der gestoppten Produktionslinie vorgelagerte Verarbeitungsschritte weiterarbeiten. Diese würden Zwischenprodukte auf Lager produzieren. Und gerade Lagerhaltung versucht man im Lean Production zu vermeiden. Dass physikalischer Lagerplatz Geld kostet, ist sicher ein Aspekt, aber nicht der entscheidene. Viel wichtiger ist, dass große Lagerbestände hohe Overheadkosten verursachen und Qualitätsprobleme verdecken.

Hohe Overheadkosten durch Lagerhaltung
Große Lagerbestände versurachen hohe Overheadkosten: Man muss das Zwischenprodukt ins Lager transportieren. Dort muss man einen geeigneten Lagerplatz finden und meistens noch vermerken, wo man das Zwischenprodukt abgelegt hat. Später muss man wieder ins Lager, das Zwischenprodukt wiederfinden und es zurück zur Produktionslinie transportieren. Und dabei besteht auch immer die Gefahr, durch Transport und Lagerung das Zwischenprodukt zu beschädigen.

Verdeckte Qualitätsprobleme durch Lagerhaltung
Qualitätsprobleme werden verdeckt, weil der Lackmustest für die Qualität eines Zwischenproduktes erst ganz am Ende erfolgt. Ob wirklich alles gut zusammenpasst, weiß man ganz sicher erst, wenn das Produkt (in unserem Fall das Auto) komplett montiert ist. Eine falsch eingestellte Maschine könnte z.B. dazu führen, dass die Tür wenige Millimeter zu breit ist und daher nicht richtig schließt.

Softwareentwicklung ist aber anders
Soweit, so gut. Natürlich ist Softwareentwicklung keine Autoproduktion, nicht mal annähernd. Daher ist erstmal Skepsis angebracht, wenn man versucht, Konzepte aus der Produktion in die Softwareentwicklung zu übertragen.

Lagerhaltung in der Softwareentwicklung
Beginnen wir mit der Lagerhaltung in der Softwareentwicklung. Gibt es sowas überhaupt? Klar. Alles, was nicht komplett fertig (Done) ist und an dem im konkreten Moment niemand arbeitet, liegt im Lager. Und die Läger finden wir in den lokalen Workspaces auf den Entwicklerrechnern wie auch in Branches in der Versionsverwaltung.

Aber ist Lagerhaltung in der Softwareentwicklung auch so schädlich wie in der Produktion? Plattenplatz kostet ja kein nennenswertes Geld mehr. Allerdings sind die Kosten für den Lagerplatz in der Produktion sicherlich auch nicht ausschlaggebend. Overheadkosten und Qualitätsprobleme sind bestimmend. Nehmen wir uns zunächst die Overheadkosten vor. Das Transportieren von Code in ein Lager (z.B. Branch) kann erstaunlich teuer sein. In vielen Unternehmen können Entwickler den Branch nicht selbst anlegen, sondern müssen den Branch von zentraler Stelle anlegen lassen. Aber das eigentliche Drama entsteht, wenn man den Code wieder aus dem Lager holt, um ihn wieder zu reaktivieren. Dann muss man in der Regel Mergen und das verursacht fast immer hohe Kosten. Zusammenfassand würde ich behaupten, dass die Overheadkosten für große Lagerbestände in der Softwareentwicklung sogar höher sein können als in der Produktion.

Sehen wir uns jetzt die Qualitätsprobleme an. Auch in der Softwareentwicklung weiß man erst ganz am Ende, ob alles gut zusammenpasst und man wirklich das gebaut hat, was Nutzen generiert. Dieses Phänomen ist in der Softwareentwicklung sogar noch viel stärker ausgeprägt als in der Produktion. Produktion kann man relativ genau vorausplanen und sie ist geprägt von repetitiven Arbeiten. Wenn man eine Tür korrekt produzieren kann, produziert man weitere Türen mit hoher Wahrscheinlichkeit auch korrekt. In der Softwareentwicklung haben wir es hingegen fast immer mit Einzelstücken zu tun. Dadurch ist die Vorhersagbarkeit viel eingeschränkter – nicht ohne Grund entwickeln wir Software agil, während Produktion eher nicht agil verläuft. Also gilt wie schon beim Overhead auch bei der Qualität: Die Qualitätsprobleme, die durch große Lagerbestände entstehen, sind in der Softwareentwicklung noch viel größer als in der Produktion.

Lagerhaltung sollte also gerade in der Softwareentwicklung vermieden werden!

Stop the Line in der Softwareentwicklung
Wenn wir jetzt Stop-the-Line in der Softwareentwicklung anwenden wollen, müssen wir zunächst definieren, bei welchen Probleme wir die “Linie” stoppen wollen und was überhaupt die “Linie” ist. Man sollte klein anfangen und sich dann schrittweise verbessern. Meistens ist ein guter Anfang, das Fehlschlagen von Tests in der Buildumgebung als stopp-würdiges Problem zu definieren. Wenn die Tests fehlschlagen, stoppen sofort alle Entwickler in dem Team ihre Arbeit, bis sich mind. ein Entwickler gefunden hat, der sich um das Problem kümmert. Während der Entwickler an dem Problem arbeitet, können die anderen Entwickler weiterarbeiten. Sie dürfen aber keinen Code in die Versionsverwaltung einchecken – schließlich funktioniert das Feedback über die Buildumgebung im Moment nicht. Das bedeutet meist, dass die Entwickler solange weiterarbeiten können, bis sie mit ihrem aktuellen Feature fertig sind. Wenn das Problem dann noch besteht, sollte man die Gruppe der Problemlöser schrittweise vergrößern, solange bis das Problem gelöst ist. Und das funktioniert ganz gut, weil man Problemlösung meistens gut parallelisieren kann. Dann probiert eben nicht ein Entwickler acht verschiedene Lösungsstrategien sequenziell aus, sondern acht Entwickler probieren jeweils eine Lösungsstrategie aus.

Und wenn dieses Verfahren gut läuft, kann man schrittweise die Bedingungen verschärfen. Findet der Product-Owner, ein Tester oder ein Entwickler einen Bug, dann Stop-the-Line. Ist die Arbeit an einer Anforderung durch Hindernisse blockiert, dann Stop-the-Line. Wenn ein Entwickler vergurkten Code findet, dann Stop-the-Line. Wenn die automatisierten Tests unvollständig sind, dann Stop-the-Line.

Erfahrungen
Jeder muss seine eigenen Erfahrungen sammeln. Meine Erfahrungen mit Stop-the-Line sind sehr gut. Gerade hat ein Team eines Kunden mit Stop-the-Line ein Problem an einem Tag beseitigt, dass vorher bereits 3 Wochen durch die Gegend eierte.
Ich kann jedem nur empfehlen, Stop-the-Line in der Softwareentwicklung auszuprobieren. Und das kann man mit überschaubarem Risiko auch immer tun. Und wer sich das nicht zutraut, den unterstütze ich als Coach gerne 🙂

Vielleicht haben Leser dieses Blogs ja ebenfalls Erfahrungen mit Stop-the-Line in der Softwareentwicklung gemacht? Dann schreibt das doch bitte in die Kommentare!

June 2, 2009 at 5:39 pm Leave a comment

Older Posts