Stop the Line in der Softwareentwicklung

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


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!

Entry filed under: 1. Tags: , , .

Scrum-Tools Terminplaner in Ruby

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: