Kundennutzen in Agilen Projekten

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.

Buchtipp: Sam Kaner et.al. „Facilitator’s Guide to Participatory Decision Making“

Meine Moderationsausbildung ist jetzt über 15 Jahre her und ich habe seitdem ein paar hundert Workshops, Meetings und Retrospektiven geplant und moderiert; von Routinemeetings bis hin zu emotional und politisch hochbrisanten Konfliktmeetings. Dass ich mir Sam Kaners Buch bestellt habe, lag eher daran, dass Diana Larsen ihn empfohlen hatte: Da musste ja was dran sein. Und es ist etwas dran, sogar sehr viel! Es ist tatsächlich das beste Buch zur Moderation, das ich bisher in der Hand hatte.

Kaner führt in einem sehr kurzen Theorieteil ein in die Gruppendynamik von gemeinsamen Entscheidungsprozessen, stellt dann alle möglichen Werkzeuge und Techniken für die Moderation vor, die jeweils mit Anwendungsbereich, Durchführung und Konsequenzen beschrieben werden, gibt Hinweise, wie man nachhaltige Übereinstimmung herstellt und stellt schließlich Techniken vor, um verbindliche Abschlüsse zu erreichen. Etwa 70-80% der Techniken waren mir bekannt, die anderen sind interessante Variationen, von denen ich sicher das eine oder andere in mein Portfolio aufnehmen werde. Anders formuliert, inhaltlich leistet das Buch das, was geleistet werden muss.

Begeistert hat mich aber die Präsentation: Jede Seite kann für sich stehen, man kann das Buch ebenso als Nachschlagewerk verwenden, wie zum Durchlesen. Jedes Kapitel gibt eine ein- bis zweiseitige Einführung in die Theorie des Themas, dann kommen Praktiken. So enthält alleine das Kapitel „Alternatives to Open Discussion“ zwölf Varianten für Meetingformate:

  • Small Groups
  • Jigsaw
  • Multi-Tasking
  • Fishbowls
  • Scrambler
  • Roleplays
  • Tradeshows
  • Open Discussion
  • Individual Writing
  • Listing Ideas
  • Presentations and Reports
  • Structured Go-Arounds

Jedes einzelne Format wird mit Empfehlungen über den Einsatzbereich, genauen Anweisungen zur Durchführung und Variationen beschrieben, in der Regel inklusive der Auswirkungen auf die Gruppendynamik. Da gibt es sowohl für Neueinsteiger als auch für alte Hasen einiges zum Lesen und Nachschlagen. Er spart auch „heiße“ Themen wie den Umgang mit „diverse communication behaviour“ nicht aus.

Einziger Wermutstropfen, den ich bisher gefunden habe: Zu den Übungen sind praktisch keine Zeitangaben enthalten. Wenn man ein wenig Erfahrung hat, lässt sich das sicher verschmerzen, aber ich empfinde nach wie vor die Zeitangaben in Esther Derbys und Diana Larsens „Agile Retrospectives“ als sehr hilfreich bei der Vorbereitung. Zur Ehrenrettung muss man allerdings auch erwähnen, dass Kaner natürlich viel breiter ansetzt und auf jede Form des Workshops anwendbar ist. Das macht Zeitangaben schwierig.

Kurz und gut: Eines der besten Bücher, die ich die letzten Jahre in die Finger bekommen habe und das sicherlich noch viele Stunden auf meinem Schreibtisch vor sich haben wird, auf einem Ehrenplatz neben dem Buch von Esther Derby und Diana Larsen.


Sam Kaner with Lenny Lind, Catherine Toldi, Sarah Fisk, and Duane Berger: „Facilitator’s Guide to Participatory Decision Making“, 2nd edition, Jonny-Bass/Wiley, 2007, ISBN 978-0-7879-8266-9
, 341 Seiten

Agile Planung und Vorhersagen

Nachdem ich mich in meinem Beitrag „Was ist anders bei agiler Planung“ mit den grundlegenden Mechanismen agiler Planung beschäftigt habe, stellte Maximilian Scherf die Frage, „Wie kann ich denn so beurteilen zu welchem Zeitpunkt ich was fertig haben werde?“ Die Frage ist sehr berechtigt, aber nicht so einfach zu beantworten, so dass ich hier in einem eigenen Eintrag darauf antworten möchte – zumindest grob.

Grundsätzlich muss man sich darüber im klaren sein, dass eine Terminaussage in einem Softwareprojekt die Vorhersage eines chaotischen Systems ist und damit der Wettervorhersage ähnelt (ich rede hier von chaotischen Systemen im Sinne der Theorie komplexer Systeme, nicht aus der Perspektive von Eltern, die in das Kinderzimmer schauen). Chaotische Systeme zeichnen sich dadurch aus, dass ihr Verhalten umso schwerer vorhersagbar ist, je weiter man in die Zukunft schaut: Die Wettervorhersage für die nächsten fünf Minuten bekommt auch der Laie üblicherweise korrekt hin, für den nächsten Tag müssen selbst Profis erheblichen Aufwand treiben und für mehr als eine Woche sind seriöse Vorhersagen derzeit nicht möglich.

Im Projektmanagement sind die planbaren Zeithorizonte zum Glück deutlich länger: Eine Woche ist meist kein Problem, einen Monat bekommt man auch noch ganz gut hin, ab einem Quartal wird es eng. Eine „genaue“ Vorhersage ist daher unmöglich, bei einer „verbindlichen“ Zusage muss man schon relativ vorsichtig sein, was man unter welchen Voraussetzungen verspricht. Erlaubt ein Planungsverfahren nur digitale Aussagen darüber, was „geschafft wird“, ist es also unrealistisch und nur wenig brauchbar. Statt dessen braucht man ein Verfahren, das einem zumindest ungefähre Aussagen zur Wahrscheinlichkeit ermöglicht: „So wie dieses Feature derzeit priorisiert ist, wird es mit 80% Wahrscheinlichkeit im nächsten Release enthalten sein“. Genügen einem diese 80% nicht, muss man es eben höher priorisieren – auf Kosten anderer Features, die dadurch weniger wahrscheinlich werden.

Wie kommt man auf Basis agiler Planung zu einer solchen Aussage? Die Basis sind die Schätzungen und die Erfahrungswerte aus den vorigen Iterationen. Die Grafik unten stammt von einem meiner Kunden, also aus einem real existierenden Projekt. In ihr sieht man die aus der Häufigkeitsverteilung abgeleitete Wahrscheinlichkeit, dass innerhalb einer Iteration mindestens n Aufwandspunkte abgeschlossen werden. Man kann aus dieser Kurve zum Beispiel ablesen, dass in mehr als 50% der Fälle mindestens 21 Punkte abgeschlossen wurden, in mehr als 80% der Fälle mindestens 13 Punkte und so weiter. Mit anderen Worten: Ist eine Aufgabe so hoch priorisiert, dass ihr eigener geschätzter Aufwand und der aller höher priorisierten Aufgaben in Summe weniger als 13 Punkte ausmacht, so wird sie in dieser Iteration mit mindestens 80% abgeschlossen werden. Oder noch anders formuliert: Ich kann Aufgaben für bis zu dreizehn Punkte Aufwand für diese Iteration zusagen, wenn mir 80% Erfüllungswahrscheinlichkeit ausreichen. Brauche ich 90%, sollte ich mich auf 10 Punkte beschränken, mit (fast) 100% erreiche ich 8 Punkte und reichen mir 50% so kann ich munter 21 Punkte „versprechen“. Unabhängig von dem, was man versprochen hat, zeigt diese Grafik aber auch, dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen, auch wenn man ziemlich sicher weiß, dass man das kaum erreichen wird (Die Grafik stammt übrigens aus meinem Vortrag für die OOP 2009).

Verteilung der Velocity

Kann ich für eine gegebene Aufgabe sagen, mit welcher Wahrscheinlichkeit sie innerhalb der nächsten Iteration fertig wird, so kann ich daraus auch längerfristige Vorhersagen ableiten, allerdings erstmal nur unter der — reichlich unrealistischen — Annahme, dass sich die Priorisierung in der Zwischenzeit nicht ändert. In der Regel ist das aber schon mehr als ausreichend, um zum Beispiel den Umfang des nächsten Releases kommunizieren zu können, ohne sich hinterher zu blamieren.

Für längerfristige Vorhersagen wird aber auch eine solche wahrscheinlichkeitsbasierte Technik zu unrealistisch. Hier kann man wieder Anleihen in der Meteorologie nehmen, diesmal in der Klimavorhersage. Dort wird nicht mit einem Modell gearbeitet, sondern es werden verschiedene Szenarien unter verschiedenen Annahmen berechnet, aus denen sich ein Korridor ergibt. Aber das würde jetzt den Umfang eines Blogeintrags endgültig sprengen.

Aufmerksame Leser werden jetzt anmerken, dass ich Maximilian Scherfs Frage eigentlich gar nicht beantwortet habe: Mit diesen Techniken kann man nämlich erstmal nur Vorhersagen darüber treffen, welche Features ich zu einem gegebenen Zeitpunkt wahrscheinlich fertig haben werde, nicht aber, wann ein gegebenes Feature fertig sein wird. Auch wenn der Unterschied subtil ist (und in den meisten Kontexten ohne Bedeutung), reflektiert das eine Grundidee iterativer Entwicklung: Die Termine stehen fest, gedreht wird am Umfang.

Das ist zwar unbequemer, als das übliche „Termine und Umfang stehen fest“, aber dafür erspart man sich das ebenfalls übliche Drehen an der Qualität, um die Zusage einzuhalten. Schlechte Qualität ist schließlich ein Selbst- und Fremdbetrug, der für alle Beteiligten sehr teuer ist. Zwar kann man auch bei agiler Planung darauf bestehen, dass bestimmte Features zu bestimmten Terminen fertig sind, aber eben nicht mehr, als erfahrungsgemäß realistisch sind. Also in unserem Beispiel für nicht mehr als 8 Punkte pro Iteration. Das ist zwar nicht immer bequem für die Verantwortlichen, aber realistisch. Und Management auf Basis unrealistischer Annahmen sollte angesichts der derzeit in der Weltwirtschaft zu besichtigenden Folgen nur noch von wenigen mit „durchsetzungstarkem Management“ verwechselt werden und damit verdienter Maßen und endgültig wieder aus der Mode kommen.

Was ist anders bei agiler Planung?

Ein Thema, das meiner Meinung nach oft bei der Ausbildung von Coaches und Scrum Mastern und bei der Einführung von Agilität zu kurz kommt, ist agile Planung. Ich erlebe immer wieder Projektleiter und Scrum Master, die verzweifelt versuchen, ihre Teamplanung in MS Project zu gießen, „weil das hier so gefordert wird“. Das ist in etwa, als würden Sie Spikes unter Ihre Ski montieren, „weil das so gefordert wird“. Machbar, aber sicher keine gute Vorbereitung für außergewöhnlich gute Leistung. Was ist also anders bei agiler Planung?

Um den Eintrag in Grenzen zu halten, möchte ich mich auf die reine Planungstechnik beschränken, also Team- und Kooperationsaspekte außer Acht lassen. Schließlich kann ein Team auch kooperativ Gantt-Diagramme malen, nur es ist eben nicht sonderlich sinnvoll. Warum? Ein wesentlicher Unterschied zu traditioneller Projektplanung ist, dass bei der Agilität nicht die Auslastung der einzelnen „Ressourcen“ (dieser Ausdruck lässt so schön vergessen, dass wir über vernunftbegabte Menschen reden!) optimieren, sondern den Durchflussgeschwindigkeit und Durchsatz von neuen Fähigkeiten des Systems. Wir versuchen also, so viel zusätzliche Wertschöpfung fertig zu stellen, wie in guter Qualität möglich, nicht so viel zu arbeiten, wie möglich.

Schlüssel zu diesem Ziel ist die Erkenntnis, dass in der DV-Entwicklung ja keine Maschinen verplant werden, sondern in der Regel hoch qualifizierte Experten, die durchaus in der Lage sind, sich um ihre eigene Auslastung zu kümmern. Die Planung dient also der Koordination und Fokussierung, nicht der der Arbeitszuweisung. Etwas weniger abstrakt wird festgelegt, was zu tun ist, nicht wer etwas tun soll. Die nächste Person, die frei ist, bzw. das nächste freie Paar kümmert sich dann um die nächste Aufgabe, die ansteht. Das wird üblicherweise als „Pull-Prinzip“ bezeichnet, oft auch (nicht ganz korrekt) als Kanban.

Dieses System hat Vor- und Nachteile. Zum einen ist es wesentlich flexibler, als eine Zuteilungsplanung, die nur dann gut funktioniert, wenn die Bearbeitungsdauer pro „Ressource“ gut vorhergesagt werden kann, aber sehr empfindlich auf Schätzfehler reagiert. Das lässt sich mathematisch mit Hilfe der dabei konstruierten gekoppelten Warteschlangen begründen, die ein chaotisches System darstellen, aber das würde hier zu weit führen. Intuitiv kann das jeder Projektleiter bestätigen, der einmal versucht hat, sein Gantt-Diagramm durchzuhalten oder auch nur aktuell zu halten. Das Pull-Prinzip hingegen reagiert sehr gutmütig auf Schätzfehler und Veränderungen in den Vorgaben, was ebenfalls warteschlangentheoretische Gründe hat.

Der Nachteil ist, dass das Verfahren einen Generalistenansatz im Team benötigt. Teams, in denen jedes Mitglied genaustens seinen „Claim“ abgesteckt hat, in dem nur diese eine Person arbeiten darf („Code Ownership“) bauen trotz Pull-Prinzips genau das gleiche fragile Warteschlangensystem auf, das die Auslastungsplanung schon instabil macht. In der agilen Planung erkennt man diese Situation normalerweise daran, dass an niedrig priorisierten Aufgaben gearbeitet wird, obwohl noch höher priorisierte Aufgaben anstehen, weil „das nur die Eva machen kann“.

Dieser Nachteil ist aber verschmerzbar, weil er ohnehin keine erstrebenswerte Situation darstellt: Wird Eva krank, kann daran das ganze Projekt scheitern. Zudem sind in meiner Erfahrung Kopfmonopole eine der wichtigsten Ursachen für verpasste Termine. Sicherlich wird es immer Aufgaben geben, die Eva effizienter erledigen kann, als Adam. Aber das spielt erst dann eine Rolle, wenn beide auch gleichzeitig anfangen könnten. Bei der Optimierung des Durchsatzes spielt nämlich die Wartezeit auch eine Rolle, anders als bei der Optimierung der Auslastung. Oder, wie Alistair Cockburn formuliert, „Effizienz wird zur Dispositionsmasse abseits des kritischen Pfades“.

Darf man also noch Gantt-Diagramme malen? In seiner Freizeit natürlich. Für ein agiles Projekt spielen sie aber keine Rolle, es gibt keine Entscheidungen, die auf ihnen basieren und sie sind daher Zeitverschwendung. Fortschritt wird mit Hilfe von Burnup bzw. Burndowncharts gemessen und mit lauffähiger Software. Das ist aussagekräftiger, als ein Balken im Gantt-Diagramm, der zu 80% fertig ist, weil 80% der Zeit vergangen sind. Diese Instrumente sind einfacher, effektiver und effizienter, als die beeindruckende Kombinatorik von Ressourcen bei Werkzeugen zur auslastungsbasierten Planung, die von der Realität in der Regel schneller überholt werden, als man sie an der Wand aufhängen kann.

Teamdynamik und Psychologie

Auf den XPDays in Hamburg stellte die Pychologin Maud Winkler das Tuckman-Modell der Teamentwicklung vor (genau genommen, das erweiterte Tuckman-Modell von Eberhard Stahl, das dieser in seinem Buch „Dynamik in Gruppen“ vorstellt):

  • Forming
  • Storming
  • Norming
  • Performing
  • Reforming

Die vierte Phase ist die produktivste Phase (wobei man hier vorsichtig sein muss, diese Phase nicht als konfliktfrei zu verstehen, nur werden hier Konflikte produktiv genutzt). Das Durchleben der anderen Phasen ist jedoch notwendige Voraussetzung dafür, dass das Team bei Performing gut arbeitet. Nicht erledigte Aufgaben aus den vorigen Phasen bleiben als Störfaktoren liegen und behindern das Team in der Arbeit. Um das Modell halbwegs realistisch zu gestalten, hat Eberhard Stahl das ursprüngliche Modell um eine iterative Komponente erweitert, die von Frau Winkler sehr betont wurde.

Dieses Modell erlaubt einen interessanten Blick auf agil geführte Teams. In diesen Teams werden regelmäßig Retrospektiven abgehalten, in denen sich das Team in eine Reflexionsphase begibt. Im Sinne des erweiterten Tuckman-Modells wird das Team also in regelmäßigen Abständen wieder in die Reformingphase „gestürzt“, die im Rahmen der Retrospektive bis zum Norming geführt wird. So werden sachliche und zwischenmenschliche Probleme auf einen klaren Zeitpunkt konzentriert, statt ständig im Untergrund zu rumoren.

Das bedeutet aber auch besondere Anforderungen an die Kompetenz des Moderators einer Retrospektive: Wer hier die Teamsituation falsch einschätzt oder angezeigte Interventionen unterlässt oder überspitzt, bewirkt bestenfalls, dass die „unproduktiven“ Phasen während der Retrospektive nicht abgeschlossen werden und das Team weiter behindern. Schlimmstenfalls wird das Team gesprengt. Hier hilft ein erfahrener externer Moderator, der auch über den dafür notwendigen psychologischen Werkzeugkasten verfügt.

(Um einer Kritik an dem Modell zuvorzukommen, die Joseph Pelrine auf der Konferenz geäußert hat: Das Modell versucht weder einen Prozess zu beschreiben, noch erhebt es den Anspruch auf einzige Wahrheit. Es dient lediglich dazu, Anhaltspunkte für geeignete Intervention eines Leiters oder Moderators zu geben. Es ist also kein „RUP der Teamdynamik“, sondern eben „nur“ ein psychologisches Modell, das ähnlich wie die einschlägigen Kommunikationsmodelle in bestimmten Situationen helfen kann, die aktuelle Situation zu verstehen. Zudem scheint mir das erweiterte Tuckman Modell wesentlich realistischer, als das recht lineare Original, auf das sich Joseph bezog).

Wie Unternehmen die Krise überleben

Roland Berger hat in der Studie „Be flexible – How engineered products companies prepare for the downturn“ 500 Maschinen- und Anlagenbauer untersucht, wie sie mit wirtschaftlichem Abschwung umgehen und Krisen überleben. Als zyklische Branche ist gerade die Investitionsgüterindustrie besonders anfällig für konjunkturelle Schwankungen. Das Resümee: Die besten Unternehmen können so flexibel auf die Krise reagieren, dass sie Konjunktureinbrüche sogar als Chance nutzen können, ihre eigene Marktposition zu stärken.

Wie die meisten anderen Sparten steigt der Anteil der IT an der Wertschöpfung auch im Maschinen- und Anlagenbau stetig. Die von Berger postulierte Flexibilität setzt unter anderem auch entsprechende Flexibilität in Forschung und Entwicklung voraus, nicht nur, aber auch bei der IT. Verfahren und Vorgehensmodelle, die zu Laufzeiten von vielen Jahren führen, können da schnell zum Ballast werden.

Agile Verfahren erlauben hier viel größere Flexibilität. Agile Planungstechniken fügen sich elegant und nahtlos in eine szenariobasierte Unternehmensplanung ein, wie sie Berger bei den erfolgreichen Unternehmen beobachtet. Zu Beginn der Rezession könnte noch ausreichend Zeit bleiben, flexibler zu werden.

„Machen Sie Flexibilität zur Sache des Top-Managements“ zählt Roland Berger als einen der fünf strategischen Bausteine auf, um die Krise zu überleben. Diese Forderung dürfte nicht nur für den Maschinenbau gelten.

PS: Mehr über agile Planungstechniken erzähle ich u.a. auf den XPDays 2008 in Hamburg oder auf der OOP 2009 in München

Ist Agile Entwicklung billiger II

Felix Rüssel schreibt in seinem „Armer Kater“ Blog zu meinem Artikel „Ist Agile Entwicklung billiger?“:

Jens schreibt jedoch auch, dass Kundenzufriedenheit das Primärziel bei jedem Projekt sein sollte. Dem kann ich nicht zustimmen, da dies eine verkürzte Sicht darstellt, v.a. wenn es sich um Unternehmen handelt, die mit Projekten Geld verdienen müssen.

Primärziel einer Unternehmung ist es weiter zu existieren und dabei möglichst Gewinn zu erwirtschaften.

Die Kundenzufriedenheit ist in den meisten Fällen ein wichtiger Faktor, um diese Ziele in einem umkämpften Markt zu erreichen – nicht jedoch das Primärziel!

Um diesen Widerspruch aufzulösen, könnte es helfen, drei Ebenen zu differenzieren:

  • Das Ziel eines (Wirtschafts-)Unternehmens ist es natürlich, am Markt zu bleiben und möglichst auch noch Gewinn abzuwerfen (in dieser Reihenfolge! Wozu die umgekehrte Priorisierung führt, erleben wir gerade recht schmerzhaft). Es gibt natürlich auch noch Organisationen, die andere Ziele verfolgen, z.B. öffentlicher Dienst, gemeinnützige Organisationen, Parteien, usw.
  • Der Existenzgrund einer Organisation muss aber deutlich spezifischer sein — ein Apsekt, den viele Unternehmensberater und Anleger und leider auch manche Manager gerne übersehen. Der Existenzgrund eines Unternehmens ist das, was in den USA gerne in möglichst blumige „Mission Statements“ gepackt wird. Wenn das nicht nur hohle Phrasen sind („Wir wollen unseren Kunden den besten Service liefern zwischen hier und und dem Neptun…“), drückt sich in ihm die Klammer über die langfrsitigen Strategien aus. Gute Existenzgründe beziehen das Zusammenspiel zwischen Kunden und Unternehmen mit ein. Schöne Beispiele für Existenzgründe sind „Wir wollen unsere Kunden mit Lebensmitteln versorgen, die so billig sind, wie möglich“ oder „Wir wollen eine Lebensmittelversorgung sicher stellen, die unserer Verantwortung gegenüber Kunden, Produzenten und Lieferanten gerecht wird.“ Wie man leicht sieht, sind das zwei völlig unterschiedliche, gegensätzliche Geschäftskonzepte, aus denen sich trotz Gewinnabsicht auf beiden Seiten völlig unterschiedliche Unternehmen und Kundenkreise ergeben.
  • Das Projektziel, über das ich geschrieben habe, bezieht sich auf ein konkretes Vorhaben. Der Kunde kann hier ein Vertragspartner sein, wie bei Softwarehäusern, oder eine andere Abteilung, wie bei interner Entwicklung (auch beides gleichzeitig ist möglich, wenn auch oft nicht so wahnsinnig zielführend). Man kann jetzt den Projekterfolg sehr unterschiedlich sehen: „Umfang, Budget, Termin und Qualität erreicht“ ist die traditionelle Definition, „Kunde mit dem Ergebnis hochzufrieden“ ist die agile Definition. Dass die traditionelle Definition besser zu Werkverträgen passt und daher ungeachtet der Probleme mit ihr populär ist, ist schon häufig diskutiert worden.

Der von Felix angesprochene vermeintliche Widerspruch kommt als daher, dass wir über völlig unterschiedliche Ebenen gesprochen haben. Allerdings sind diese Ebenen natürlich gekoppelt. Wenn ich ausschließlich auf kurzfristige Gewinnmaximierung ziele, werde ich versuchen, aus einem Projekt so viel Geld herauszuschlagen, wie möglich, zum Beispiel indem ich es immer weiter aufblase, bis ich 200 billige „Juniorberater“ möglichst mit Tagessätzen erfahrener Leute beim Kunden im Einsatz habe. Für solche Organisationen ist Kundenzufriedenheit in der Tat sekundär, sie akquirieren dann oft eher über Beziehungen (sog. Alumni-Netzwerke, was nicht bedeutet, dass jede Firma, die ein solches Netzwerk betreibt, in diese Kategorie gehört!). Unternehmen, die langfristige Kundenbeziehungen aufbauen, werden allerdings den Kundenutzen sehr hoch priorisieren. „Mir ist relativ egal, ob wir in diesem Projekt rote oder grüne Zahlen schreiben, wenn wir hier erfolgreich sind, stehen wir im gesamten Marktsegment sehr gut da“ ist eine häufige Aussage von Managern, die so denken. Ich glaube, die zweite Sorte von Organisationen wird eher einen Vorteil aus agilen Verfahren ziehen.

Einer anderen Aussagen von Felix möchte ich aber ganz klar widersprechen:

Für die Erreichung der Primärziele Existenzsicherung/Rentabilität sind die Kosten der entscheidende Faktor

Das ist eine zwar sehr moderne aber dennoch fatale Einengung des unternehmerischen Handlungsspielraums. Eine rigide Kostenkontrolle ist dann sinnvoll und notwendig, wenn ich eine Kostenstrategie fahre. Wer eine Differenzierungsstrategie fährt, oder eine Nischenstrategie, kann oft mit seinen internen Kosten deutlich entspannter umgehen (siehe dazu Buchtipp unten). Gerade wegen der von Felix angesprochenen Probleme, Motivätion und Qualität in die Kostenrechnung zu integrieren, ist es bei solchen Unternehmen oftmals kontraproduktiv, zu sehr auf der Kostenbremse zu stehen. Tom DeMarco diskutiert das ausführlich in seinem „Peopleware“ und leitet die Diskussion ein mit einem Memo, das der Vizepräsident von Xerox einst an seine Mitarbeiter verschickte: „It has come to my attention, that some of you, when traveling on expenses, have been traveling economy class. This is a first-class organisation. When you fly on business from now on, you fly first class.“ (s. 153) Gut das war in den frühen Siebzigern. Andererseits war genau das die Zeit, in der Xerox die besten Beiträge zur Software geleistet hat (Smalltalk, Maus, Fensteroberfläche,…).

Ist das Zufall? Ich denke, es hat etwas mit Attitüde zu tun. Wer sich nur auf die Kosten konzentriert, bringt damit ein klares Wertesystem zum Ausdruck. Wer, wie der Chef bei Xerox, klar macht, dass ihm die Arbeitsbedingungen der Mitarbeiter so wichtig sind, dass er bereit ist, dafür Geld auszugeben, ebenfalls. Zur Kostenführerschaft passt das erste Wertesystem, zu den anderen Strategien eher das zweite. Leider sind viele erstklassige Unternehmen von ihrem Management in die Mittelmäßigkeit gedrängt worden, indem sie diesen Unterschied nicht beherzigt haben.

Auf die Gefahr hin, mit Standardlektüre zu langweilen, noch schnell die zwei Quellenangaben dazu:

Ist agile Entwicklung billiger?

Eine der Standardfragen zu agiler Entwickung lautet: „Können Sie denn nachweisen, dass das billiger ist, als traditionelle Vorgehensweise?“

Der Frage liegt ein interessantes Bild zugrunde, nämlich dass es auf der einen Seite ein Projekt gäbe, also ein definiertes Ergebnis, auf der anderen Seite einen Prozess, der auf einer völlig anderen Dimension steht und das Ergebnis nicht beeinflusst.

Dieses Bild spiegelt die Realität der Softwareentwicklung leider nicht so ganz vollständig wider: Agile Teams entwickeln die fachliche Lösung in enger Zusammenarbeit mit den Fachexperten. Das tun sie nicht, weil sie zu faul oder unfähig wären, Pflichtenhefte, Lastenhefte und Spezifikationen zu schreiben (die meisten Agilisten, die ich kenne, können das deutlich besser, als der Durchschnitt), sondern weil sie überzeugt sind, auf diese Weise ein fachlich und wirtschaftlich besseres Ergebnis zu erhalten.

Das bedeutet auf jeden Fall, dass das Ergebnis anders sein wird, als mit traditioneller Vorgehensweise. Nur die Kosten zu vergleichen, vergleicht also Äpfel mit Birnen. Wer noch dazu Schätzungen vergleicht, statt der Gesamtkosten über die Lebenszeit des Softwaresystems, vergleicht auch noch mit Birnen, deren Bäume noch nicht einmal gepflanzt sind — in der Regel auf Böden, von denen man nicht einmal weiß, ob da Obstbäume überhaupt gedeihen.

Ist das jetzt der Versuch, sich einem „objektiven“ Vergleich zu entziehen? Ganz im Gegenteil, wir sollten nur die richtigen Parameter vergleichen: Kundenzufriedenheit, weil das das Primärziel jedes Projekts sein sollte, und Motivation des Teams, weil damit die Investition in Ausbildung und Aufbau des Teams, der Kundenbeziehung und des Wissens geschützt wird. Bei beiden Kriterien schneidet agile Entwicklung in allen mir bekannten Untersuchungen signifikant besser ab, als traditionelle Verfahren (auch wenn es natürlich Ausreißer gibt).

Wem das zu „unwissenschaftlich“ ist, der wird nicht um die Mühe herum kommen, zwei Teams an die gleiche Aufgabe zu setzen und unter wirklich vergleichbaren Bedingungen Kosten und Nutzen zu vergleichen. Leider habe ich bisher noch niemanden gefunden, der es dann doch so genau wissen wollte und bereit gewesen wäre, das Geld dafür in die Hand zu nehmen. Und das wäre natürlich auch nur ein einzelnes Projekt, das nicht repräsentativ wäre, und keinerlei „wissenschaftlich fundierte“ Aussage zulassen würde…