Zu meinen Vorträge auf den Karlsruher Entwicklertagen stehen nun auch die Folien online zur Verfügung:
Danke an die andrena objects ag für das Bereitstellen der Unterlagen
Peter Kruse, Honorarprofessor für Organisationspsychologie in Bremen, hat 8 Regeln aufgestellt, um den völligen Stillstand in Unternehmen zu erreichen. 3 Minuten und 37 Sekunden sehr Amüsantes und Nachdenkliches zum Changemanagement: 8 Regeln für den totalen Stillstand
Allen, die agile Entwicklung noch immer für eine Absurdität unprofessioneller Hobbyentwickler und Hippies halten, sei der Artikel „Windows aus der Asche“ aus dem aktuellen SPIEGEL empfohlen, der auch auf SPIEGEL-Online verfügbar ist. Der Beitrag berichtet, wie Microsoft für die Entwicklung von Windows 7 konsequent auf Extreme Programming gesetzt hat („Von nun an, so viel stand fest, sollte der Kunde treiben“ und „in ganzen Abteilungen sitzen die teuren Programmierer nicht mehr allein, sondern paarweise vor den Monitoren“; „Beginne mit dem Machbaren, dann füge Stück für Stück hinzu. Und immer gleich gründlich testen!“) und welche Auswirkungen das hatte: „Plötzlich kommen der Reihe nach Produkte heraus, die den fast ungeteilten Beifall der Fachwelt finden“, und Brad Silverberg, Entwicklungsleiter von Windows 95, stellt fest: „Zum ersten Mal seit langer Zeit sind die Leute wirklich entzückt von neuen Microsoft-Produkten.“ Auch Qualität und Terminplanung wurden beeinflusst: „Windows 7 […] ist nun nach kaum zwei Jahren fast fertig. Und der Start wurde schon zweimal vorverlegt, zuletzt auf den 22. Oktober.“
Ich denke, damit dürfte die Brauchbarkeit agiler Verfahren auch für große und schwierige Projekte endgültig empirisch gezeigt sein. Anders formuliert, agile Entwicklung ist jetzt nicht mehr nur Sache der Pioniere, sondern wird nach und nach zum entscheidenden Wettbewerbsvorteil — ein Vorteil, den vor Microsoft auch schon Google, Amazon und ebay genutzt haben.
Ich hoffe nur, dass die deutsche IT-Industrie hier nicht wieder durch „aktives Zuwarten“ den Zug verpasst und weitere Arbeitsplätze gefährdet, sondern erkennt, dass es höchste Zeit wird, sich umfangreiches Know-How und Praxis angzueignen. Es ist schließlich wesentlich einfacher, die Organisation noch umzustellen, solange man das nach eigenem Zeitplan machen kann, als wenn man von der Konkurrenz vor sich her getrieben wird.
Felix Rüssel hat vor einiger Zeit in seinem — übrigens insgesamt sehr lesenswerten — Blog einen älteren Beitrag von mir zum Kundennutzen unter dem Titel „Kundenzufriedenheit vs Kosten“ in die Kritik genommen. Einer von Felix‘ Kernsätze war: „Die agile Sichtweise schlägt […] stark vereinfacht vor, Kundennutzen grundsätzlich zu maximieren. Dies darf jedoch nicht zu Lasten des Gesamtbudgets des Projektes gehen! Dieser Konflikt muss durch den ProductOwner bzw. den Projektleiter erkannt und zusammen mit dem Kunden gelöst werden“, und er beklagt sich: „Die Kundenzufriedenheit spielt […] unbestritten eine zentrale Rolle, wird jedoch gerade in der agilen Welt zu oft als alleiniges Heilmittel angesehen. Es wird oft aus der Sicht des Ingenieurs argumentiert, der Prozesse und Arbeitsergebnisse optimieren möchte.“
Ich teile Felix‘ Auffassung nicht, dass die alleinige Fokussierung auf die Kundenzufriedenheit nur aus einer technokratischen Sicht kommt. Ich denke, sie hat auch handfeste betriebswirtschaftliche Gründe, zumindest wenn der Kontext stimmt. Felix argumentiert in seinem Beitrag aus der Sicht eines Softwarehauses: „In den meisten Fällen arbeiten heute Teams in der Projektentwicklung weiterhin mit Werkverträgen, d.h. es wird ein definiertes Ergebnis zu einem bestimmten Termin geschuldet.“ Das bedeutet aber eben nicht nur ein Werkvertrag, sondern auch eine neue, künstlich eingezogene betriebswirtschaftliche Ebene: Für den Auftragnehmer ist in dieser Situation nicht mehr der betriebswirtschaftliche Erfolg der Software relevant, sondern einzig der Erfolg des Projekts ihrer Erstellung, gemessen an Einhaltung von Umfang und Termin möglichst unterhalb des Budgets und zu einer Qualität, die mir nicht gerichtsfest um die Ohren geschlagen werden kann.
Je weiter ich als Projektleiter also kurzfristige Kosten und damit Qualität nach unten drücken kann, um so erfolgreicher bin ich betriebswirtschaftlich als Projekthaus. Allerdings werden dabei die Kosten nicht wirklich reduziert, sondern nur vom Auftragnehmer zum Auftraggeber verlagert: Der Auftragnehmer spart vor der Produktionssetzung Kosten ein, indem er weniger in Qualität investiert, der Auftraggeber muss ein Mehrfaches dieser Kosten hinterher aufbringen, um die Fehler zu beheben, mit den Fehlerfolgen umzugehen und das verkorkste Design weiter zu entwickeln. In der Rechtstheorie könnte er dafür zwar den Auftragnehmer in Mängelhaftung nehmen, in der Praxis ist das jedoch nicht nachzuweisen.
Rob Austin bezeichnet diese Konstellation in einem meiner Lieblingsbücher „Measuring and Managing Performance in Organizations“ als „Measurement Distortion“: Wenn ein System (oder Vertrag) von vier Parametern bestimmt wird (Termin, Umfang, Kosten und Qualität) und ich kann nur drei von ihnen einigermaßen messen (Termin, Umfang und Kosten), so werden diese auf Kosten des schlecht messbaren vierten Parameters (Qualität) optimiert. Wie das im Projektalltag dann aussieht, beschreibt Felix sehr richtig und treffend.
Die Schlussfolgerung ist aber nicht, dass Agilisten „das Thema ‚Kosten‘ gerne verdrängen“ würden, sondern dass Werkverträge nicht geeignet sind, betriebswirtschaftlich sinnvoll ein Softwaresystem zu erstellen: Hier geht es ja nicht nur um Entwicklungskosten (die der Auftragnehmer eines Werkvertrages optimiert), sondern um die Gesamtkosten („Total Cost of Ownership“) des Systems, zu denen unter anderem auch Betriebs-, Wartungs-, Weiterentwicklungs- und Stilllegungskosten gehören. Die Rechnung wird also am Ende der Lebenszeit der Software aufgemacht, nicht zu Produktionsstart. Um die Tatsache abzubilden, dass bei den Kosten auch der Zeitfaktor mitspielt, arbeiten Betriebswirtschaftler mit Abzinsungsmodellen, die ein guter Product Owner meines Erachtens kennen und soweit sinnvoll berücksichtigen sollte. Mike Cohn beschreibt solche Modelle sehr gut in seinem Buch „Agile Estimating and Planning„, Kapitel 10.
Die agile Sicht stellt also dem traditionellen Projekt „Software bis zur Produktionsreife entwickeln“ eine Produktsicht gegenüber: Der Return-on-Investment über den gesamten Lebenszyklus muss optimiert werden. Ich habe diesen Gedanken 2005 einmal in dem Artikel „Projektdämmerung“ weiter ausgeführt. Es geht also um eine globale Optimierung statt einer lokalen, bzw. um eine ganzheitlichere Sicht auch in der betriebswirtschaftlichen Steuerung. In Scrum ist genau das die Aufgabe des Product Owners.
Mit anderen Worten: Die Abkehr vom Werkvertrag ist für den Auftraggeber wichtig und sinnvoll. Die Auftragnehmer haben sich mit Werkverträgen arrangiert, vom meist agilen, kundenorientierten Softwarehaus, das sich bemüht, das Spannungsfeld für alle Seiten einigermäßen erträglich auszubalanzieren bis zum eiskalten Homo Ökonomicus im Großkonzern, für den nur noch Termine und Kostenminimierung zählen und die nicht vertraglich fixierten Interessen des Kunden keine Rolle mehr spielen. Der Auftraggeber liefert sich in beiden Fällen ohne Not dem Auftragnehmer aus, seine Interessen kommen dabei in der Regel unter die Räder.
Den folgenden Text hat Robin Dymond heute auf der Mailingliste für Retrospektiven herumgeschickt. Ich fand ihn so lesenswert — bis zum Ende — dass ich mich entschlossen habe, ihn zu bloggen:
Washington DC Metro Station on a cold January morning in 2007. He played six Bach pieces for about 45 minutes. During that time approx 2 thousand people went through the station, most of them on their way to work. After 3 minutes a middle aged man noticed there was a musician playing. He slowed his pace and stopped for a few seconds and then hurried to meet his schedule.
4 minutes later:
the violinist received his first dollar: a woman threw the money in the till and, without stopping, continued to walk.6 minutes:
A young man leaned against the wall to listen to him, then looked at his watch and started to walk again.10 minutes:
A 3 year old boy stopped but his mother tugged him along hurriedly, as the kid stopped to look at the violinist. Finally the mother pushed hard and the child continued to walk, turning his head all the time. This action was repeated by several other children. Every parent, without exception, forced them to move on.45 minutes:
The musician played. Only 6 people stopped and stayed for a while. About 20 gave him money but continued to walk their normal pace.
He collected $32.1 hour:
He finished playing and silence took over. No one noticed. No one applauded, nor was there any recognition.No one knew this but the violinist was Joshua Bell, one of the best musicians in the world. He played one of the most intricate pieces ever written, with a violin worth $3.5 million dollars. Two days before Joshua Bell sold out a theater in Boston where the seats averaged $100.
This is a real story. Joshua Bell playing incognito in the metro station was organized by the Washington Post as part of a social experiment about perception, taste and people’s priorities. The questions raised: in a common place environment at an inappropriate hour, do we perceive beauty? Do we stop to appreciate it? Do we recognize talent in an unexpected context?
One possible conclusion reached from this experiment could be:
If we do not have a moment to stop and listen to one of the best musicians in the world playing some of the finest music ever written, with one of the most beautiful instruments ….
How many other things are we missing?
Einen ausführlichen Bericht inklusive zweier Videos bietet die Washington Post auf ihrer Web-Seite.