Monday, December 6, 2010

Lean bedeutet einen Perspektivenwechsel

Anfang November besuchte ich in Hamburg einen Vortrag von Kent Beck (der "Erfinder" von eXtreme Programming und testgetriebener Entwicklung). Das Thema lautete: Software G Forces and the Effects of Acceleration. Neben vielen anderen interessanten Punkten hat dabei vor allem ein Aspekt ein Aha-Erlebnis bei mir ausgelöst: Agiel/Lean (die für mich zwei Seiten derselben Medaille darstellen) bedeutet häufig, traditionelle Sichtweisen aufzugeben und eine zuerst ungewohnte, neue Perspektive einzunehmen.
Becks Vortrag handelte davon, was geschieht, wenn ein Team/eine Organisation dazu übergeht, ihren Release-Zyklus immer weiter zu verkürzen: von jährlich auf quartalsweise auf monatlich auf wöchentlich auf täglich auf stündlich (ja, so etwas funktioniert tatsächlich, wie beispielsweise flickr eindrucksvoll beweist). Für jeden dieser Rhythmen hat Beck auf einer Folie dargestellt, was jeweils dafür nötig ist, um auf diese Stufe zu gelangen und welche Dinge man sich auf der anderen seite nicht mehr erlauben kann. 
Was ist nötig für monatliche Releases (links), und was kann man sich nicht mehr erlauben (rechts)?
 
 
 
 
 
 
Beispielsweise ist es ab einem monatlichen Rhythmus nicht mehr möglich, eine eigene Q/A-Abteilung zu haben, weil die Arbeitsübergaben und die Kommunikationsaufwände dann zu hoch wären, um so ein schnelles Tempo zu erlauben. (Intessanterweise kann man ab einem bestimmten Tempo auch keinen Bugtracker mehr haben. Stattdessen muss man es hinbekommen, dass nur noch extrem wenige Bugs entstehen, und diese wenigen Bugs müssen sofort gefixt werden - oder man muss sie ignorieren und bis in alle Ewigkeit mit ihnen leben.) 
Auf der Seite der Dinge, die nötig sind, um schneller zu werden, waren alte Bekannte zu lesen wie automatisierte Akzeptanztests, Continuous Integration und Refactorings (und zwar schon bei quartalsweisen Releases). 
Das hat mich zuerst erstaunt, aber dann ist der Groschen gefallen: Bei all diesen Praktiken geht es gar nicht in erster Linie darum, sie einzusetzen, um ein bestimmtes Ziel zu erreichen. Ich hatte vorher immer viel zu sehr von den Praktiken her gedacht. 
"Warum macht Ihr TDD?" - "Weil sich dadurch ein schlankeres Design ergibt." 
"Warum arbeitet Ihr im Pair?" - "Weil wir dann weniger Fehler machen." 
Das sind natürlich nach wie vor sehr gute Gründe. Wenn man aber die Reihenfolge umdreht, wird aus der möglichen Argumentation eine zwingende. Und sie ist besonders zwingend, wenn es um kurze Durchlaufzeiten und häufige Releases geht (was ja tatsächlich für viele Organisationen die größten Herausforderungen darstellt). Die Unterhaltung könnte dann ungefähr so aussehen: 
"Wir möchten gern wöchentlich Releasen. Geht das?" "Ja, aber nur, wenn wir Pair Programming einsetzen und TDD praktizieren." "Dann sollten wir sofort damit anfangen." "Gern, aber vorher brauchen wir etwas Zeit und Geld für Weiterbildung, andere Schreibtische und und größere Monitore." 
Pair Programming und Co. sind also keine Hindernisse für hohes Tempo, sondern eine Voraussetzung!
Dasselbe gilt übrigens für den Zusammenhang zwischen Geschwindigkeit und Qualität (ein Umstand, auf den die Poppendiecks immer wieder hinweisen): Die Alternative lautet nicht Geschwindigkeit oder Qualität. Sondern sie lautet: Schnell werden durch hohe Qualität oder langsam bleiben, weil die schlechte Qualität kein höheres Tempo zulässt. Wie im TDD-Beispiel ist es natürlich auch hier einfacher gesagt als getan, denn die Qualität zu erhöhen, ist ja alles andere als trivial. Aber wenn man schneller werden will (oder muss) führt kein Weg daran vorbei. XP-Praktiken sind nichts, was man macht, weil es irgendwie cool wäre, sondern sie stellen Bedingungen dar, an denen man nicht vorbeikommt, wenn man bestimmte Ziele erreichen möchte.
Zum Weiterlesen
  • Markus Gärtner hat mit seiner unvergleichbaren Live-Blogging-Technik den Vortrag von Kent Beck sehr schön zusammengefasst. Zur Zusammenfassung
  • Mary und Tom Poppendieck (2006): "Implementing Lean Software Development." Buch bei Amazon

1 comment:

Yes wie Kanban Yes wie Kanban