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:

• Folien zum regulären Vortrag
• Folien zum Pecha Kucha
• Video des Pecha Kucha

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.

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.

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!

Pull und Kanban – über die Entwicklung hinaus

Das Pull-Prinzip stammt aus dem Lean-Production und ist ein (mehr oder weniger expliziter Aspekt) agiler Softwareentwicklung. Die Idee ist, dass man nicht Arbeit in eine Ressource (z.B. Team) hineindrückt (push), sondern die Ressource sich selbst neue Arbeit holt (pull), wenn sie keine mehr hat. So wird Überlastung der Ressource vermieden.

In Scrum holt sich das Team im Sprint-Planning soviel Arbeit ab, wie es meint, im Sprint realisieren zu können – auch wenn der Product-Owner gerne mehr realisiert haben möchte. Er darf nicht mehr Arbeit in die Sprint drücken. Das Team wendet also Pull an.

Wenn man das Pull-Prinzip weiterdenkt, muss man mind. die Prozesse nach der Entwicklung mit einbeziehen (upstream processes). Faktisch findet in vielen Organisationen nach dem Sprint noch abschließende Qualitätssicherung und Überführung in den Betrieb statt. Dort sollte man natürlich auch nach dem Pull-Prinzip verfahren. Das Team drückt also nicht mit einer festen Live-Deadline die Ergebnisse des Sprints in die Qualitätssicherung und den Betrieb. Stattdessen holen sich Qualitätssicherung und Betrieb ihre Arbeiten, wenn ihre Auslastung es zulässt.

Wie setzt man das konkret um? Ganz Basic-Lean gedacht würde sich der Product Owner an das letzte Element der Wertschöpfungskette wenden und seinen Feature-Wunsch äußern, z.B. “Ich möchte, dass ich die Kontakthistorie von Kunden einsehen kann.” Diesen Auftrag würde er auf einen Zettel schreiben und an den Betrieb geben.

Der Betrieb würde daraus einen (Sub-)Auftragszettel an die Qualitätssicherung formulieren: “Ich möchte eine qualitätsgesicherte Funktionalität haben, die den Anwendern erlaubt, die Kontakthistorie von Kunden einzusehen. Außerdem muss die Funktionalität geclustert auf einem Tomcat mit mySQL betrieben werden können.”

Die Qualitätssicherung macht daraus einen Auftragszettel an das Entwicklungsteam: “Ich möchte eine Funktionalität haben, die den Anwendern erlaubt, die Kontakthistorie von Kunden einzusehen. Außerdem muss die Funktionalität geclustert auf einem Tomcat mit mySQL betrieben werden können. Die ganze Funktionalität muss soweit möglich mit FIT akzeptanzgetestet sein und es muss Beschreibungen geben, was noch manuell zu testen ist.”

Dann beginnt das Entwicklungsteam, diesen Arbeitsauftrag abzuarbeiten. Wenn es fertig ist, liefert es die Systemfunktion an die Qualitätssicherung zusammen mit dem zugehörigen Auftragszettel. Die Qualitätssicherung verfährt entsprechend an den Betrieb und dieser an den Kunden.

Der ganze Arbeitsfluss wird also über Auftragszettel gesteuert. Diese Auftragszettel heißen im Lean-Production Kanban.

Mit den Auftragszetteln wie beschrieben in der Softwareentwicklung vorzugehen, ist i.d.R. unnötig teuer. Es wird zu viele Missverständnisse geben. Viel besser ist das persönliche Gespräch. Also wendet sich der Product Owner direkt an das Team und erläuert, was er benötigt. Was uns dann der ganze Kanban-Ausflug bringt? Bei diesem Gespräch (Sprint Planning) müssen Qualitätssicherung und Betrieb einbezogen werden. Man faltet den Prozess mit den Auftragszetteln zusammen, um schneller zu sein. Die Beteiligten bleiben aber dieselben!

Stehen, stehen, immer nur stehen?

Hier ist ein interessanter Blog-Eintrag, in dem beschrieben wird, dass die japanischen Lean-Unternehmen auf das Stehen stehen (was für eine formvollendete Formulierung
Die dort genannten Gründe für das Stehen (bessere Ergonomie, herumlaufen ist wichtig etc.) gelten alle auch für die Softwareentwicklung. Unsinn? Nein! Mein Kumpel Henning hat seit seinem Bandscheibenvorfall einen Tisch, der sich auf Stehhöhe hochfahren lässt. Und daran haben wir auch schon Pair-Programming gemacht und es war auf keinen Fall unangenehmer als dies sitzend zu tun.
Irgendwie haben wir die Idee aber nicht weitergetrieben. Ich habe aber mehr und mehr das Gefühl, dass wir das nochmal tun sollten.

Toyoto Product System Details

Viele kennen die Prinzipien des TPS (Toyota Production System): Hier gibt es noch weitere sehr interessante Details dazu.

Ivar Jacobson über die Zukunft der Softwareentwicklung

The future of software development practices.

Aufgaben schätzen oder Aufgaben schneiden?

Viele agile Projekte arbeiten mit Stories, um die Anforderungen zu definieren. Die Komplexität von Stories wird mit abstrakten Story Points geschätzt. Bei der Sprint-/Iterationsplanung findet der sogenannte Task Breakdown statt: Die Stories werden in Aufgaben (Tasks) für die Entwickler zerlegt und diese Tasks werden dann in Personenstunden oder -tagen geschätzt (Commitment Driven Planning). Die Tasks sollten dabei möglichst klein sein. Häufig wird ein Tag als Obergrenze genannt. Dann hat man beim Daily Standup im Durchschnitt jedes mal mind. einen Tasks als erledigt zu vermelden.

Wir haben gute Erfahrungen damit gemacht, die Tasks nicht nur möglichst klein sondern auch möglichst gleich groß zu halten. Wenn alle Tasks gleich groß sind, muss man Aufwände nicht mehr zusammenrechnen, sondern muss nur noch Tasks zählen. Und wenn man irgendwo mal umplanen muss, ist das auch ganz einfach: Einen Task weghängen und einen neuen dafür dazu hängen. Die Vorteile sind in der Praxis deutlich spürbar.

Allerdings kommt man jetzt in eine Zwickmühle. Tatsächlich sind die Tasks konkret nicht alle gleich groß, sondern nur im Durchschnitt. Das kann dazu führen, dass das Team in einem Sprint/Iteration 20 Tasks schafft und in einem anderen 22 Tasks. Für Commitment Driven Planning reicht das Durchzählen der Tasks also nicht aus. Wenn man beim Sprint-/Iterationsreview feststellt, dass man ein paar Tasks mehr oder weniger geschafft hat als geplant, sagt das erstmal wenig aus. Die Abweichung könnte durch die natürlichen Schwankungen bedingt sein.
Das Problem ließe sich durch das Schätzen von Tasks in Stunden beheben, dann ist aber der Vorteil der gleichen Größe wieder futsch.

Daher hat eins meiner Teams mit “halben” Tasks experimentiert. Die meisten Tasks hatte die Normgröße. Einige wenige Tasks waren kleiner und wurden daher mit 1/2 annotiert. Das hat aber nicht so richtig gut funktioniert. Die bereits vorher sehr guten Commitments wurden dadurch nicht besser. Dafür wurde Sprint-/Iterationsplanung umständlicher und beim Review gab es immer wieder Verwirrung um das Tracking (“Zählen wir die halben Tasks für das Tracking jetzt voll oder nur halb?”). Folgerichtig hat das Team die halben Tasks wieder abgeschafft und arbeitet jetzt wieder unter der Annahme, dass alle Tasks gleich groß sind.

Interessant sind noch zwei Diskussionen, die wir geführt haben:
1) Boris Gloger hat vorgeschlagen, bei Sprint-/Iterationsplanung gar nicht mehr zu schätzen. Stattdessen fragt man das Team nach dem Task Breakdown einfach Story für Story “Würdet Ihr Euch darauf committen?” Tatsächlich reicht das vollkommen aus. Es geht darum, ein Commitment auf die Planung zu bekommen. Wie man das erreicht ist sekundär. Allerdings mochte das Team Boris’ Ansatz nicht folgen. Sie meinten, sie könnten auf dieser groben Ebene nicht einschätzen, ob die Planung funktioniert.
2) Man könnte die Tasks auf eine einheitliche Größe zwingen. Dann würde man nicht Tasks auf ToDo-Zettel schreiben, sondern auf Slot-Zettel. Ein Slot hätte eine feste Größe (z.B. 1/2 Personentag) und man müsste die Tasks so formulieren, dass sie auf diese Größe passen. Bei sehr kleinen Aufgaben müsste man mehrere Tasks auf einen Slot-Zettel schreiben. Diese Herangehensweise hat das Team kontrovers diskutiert, letztlich aber abgelehnt. Es schien den Entwicklern zu unnatürlichen Tasks zu führen.

Im Ergebnis ist das Team als bei einer Sprint-/Iterationsplanung verblieben, die mit etwas unscharfen Werten hantiert – alle Tasks werden als gleich groß angesehen, obwohl sie das nicht sind. Das ist solange unproblematisch, wie das Team trotzdem ein Commitment auf die Planung abgibt und das tut es. Jetzt muss man mal beobachten, wie es sich mit der tatsächlichen Qualität der Planungen verhält.

BTW: Ich persönlich mag den Ansatz von Boris und ich tendiere zu dem Slot-Zettel-Ansatz, um alle Tasks gleich groß zu bekommen. Dass ggf. mehrere Tasks auf einem Slot-Zettel stehen, halte ich für unproblematisch, weil sie so klein sind. Man wird die Aufgaben eines Slot-Zettels ohnehin nicht aufspalten und parallel abarbeiten lassen wollen.

P.S.: Tasks gleicher Größe zu haben, reduziert Variabilität und reduzierte Variabilität führt laut Lean Development/Production zu einer höheren Produktivität. Siehe auch bei David Anderson.

Einladung zu den XP-Days Germany 2008 in Hamburg

Das Programm für die XP-Days Germany 2008 in Hamburg steht jetzt fest (siehe Programm). Vorträge gibt es am 27.11.08 (Donnerstag) nachmittags und am 28.11.08 (Freitag) den ganzen Tag. Wir haben ein vielfältiges Programm, dass sowohl den Interessen von Neueinsteigern wie auch alter Hasen im Bereich der agilen Methoden gerecht wird.

Wie der Untertitel der Konferenz bereits deutlich macht: Die XP-Days bieten allen agilen Methoden ein Forum, nicht zur eXtreme Programming. Das zeigt sich auch dieses Jahr wieder am Programm. Die meisten Vorträge bieten Wissenswertes, dass sich mit jeder agilen Methode kombinieren lässt.

Der Samstag richtet sich an all diejenigen, die aktiv mitdiskutieren wollen. Dazu muss man kein Experte mit jahrelanger Erfahrung sein. “Nur” das Engagement ist wichtig. Folgerichtig gibt es für den Samstag kein vorab festgelegtes Programm. Stattdessen wird eine “Unconference” im Open-Space-Stil stattfinden.

Jetzt bleibt eigentlich nur noch eines zu tun: Anmelden und den Frühbucherrabatt sichern!

Scrum-ban

Corey Ladas hat einen interessanten und provakanten Artikel über Scrum und Lean/Kanban geschrieben. Auch wenn man nicht jedem Argument folgen mag, finde ich den Artikel denkanstößig.