Es ist zwar noch ein wenig hin bis Weihnachten, aber trotzdem lohnt es sich, auf Obie Fernandez‘ Blog „Explain Variable Scope with Ponies“ zu schauen: Er vergleicht in einer netten Analogie die Preisfindung in einem agilen Projekt mit den Weihnachtseinkäufen von Eltern. Einziger Haken an der Analogie: In agilen Projekten stellt der Kunde die Wunschliste auf und ist an der Auswahl der konkreten „Geschenke“ (=Features) beteiligt, was Kindern sicherlich einen erheblichen Teil des Spaßes an Weihnachten rauben würde.
Archiv der Kategorie: Kunden
Agil und V-Modell XT
Krishan Mathis fasst in seinem Beitrag „Scrum and the German V-Model XT“ das Ergebnis einer Diskussion auf dem letzten Agile Tuesday in München zusammen. Der Beitrag enthält eine sehr lesenswerte Kurzfassung des V-Modell XT und geht auch auf die „Agile Durchführungsstrategie“ ein: „There is very little overlap between this ‚agile‘ model and how Scrum structures activities“. Die Aussage lässt sich durchaus auf die meisten agilen Verfahren übertragen.
Krishan kommt zu dem Schluss, dass man den Product Owner als „Schnittstelle“ zwischen den Welten „missbrauchen“ kann, aber nicht ohne eine Warnung: „It puts however a high degree of tension on the product owner and an associated risk of project failure.“
Ich denke, für alle agilen Verfahren ist die „mechanische“ Kopplung beider Welten über eine „Schnittstelle“ eine mögliche Lösung, nicht nur für Scrum. Man sollte sich dabei aber auch darüber im klaren sein, dass man sich damit auf sehr dünnes Eis begibt. Wird vom Auftraggeber das V-Modell XT verlangt, hat das normalerweise einen von zwei Gründen:
- Der Auftraggeber ist gesetzlich und per Ausschreibungsrichtlinie gezwungen, das zu verlangen
- Der Auftraggeber hat sich bewusst für ein hoch-zeremonielles Verfahren wie das V-Modell XT entschieden
In beiden Fällen ist der Schluss naheliegend, dass die interne Kultur des Auftraggebers so gestaltet ist, dass Mechanismen und Ideen des V-Modell XT zur Kultur passen. So kann zum Beispiel die Einhaltung von Vorschriften und unveränderten Verträgen wichtiger sein, als ein schneller RoI, selbst wenn sich das als projektgefährdend herausstellen sollte. Auch kann die Bereitschaft, individuell Verantwortung zu übernehmen, deutlich geringer sein, als zum Beispiel bei einem Startup.
Ist das der Fall, ist die Wahrscheinlichkeit hoch, dass weder Auftraggeber noch Auftragnehmer glücklich werden mit agilen Ansätzen. Der Wunsch, hinter einer V-Modell-Fassade agil zu arbeiten, sollte meines Erachtens also vom Auftraggeber ausgehen, und dieser sollte auch in der Lage sein, die notwendigen Entscheidungen zeitnah zu treffen — und später auch die Verantwortung dafür zu übernehmen. Zudem sollte man sorgfältig abgewogen haben, ob die Fassade wirklich sein muss, oder ein offener Ansatz möglich ist und man sollte sich ggf. auch mit Hilfe eines Spezialisten für Ausschreibungsrecht absichern und mit der zuständigen Innenrevision gesprochen haben.
Das klingt jetzt zwar alles wenig agil, aber man sollte sich auch im Klaren sein, dass die freundliche Gruppenleiterin, mit der man gerade verhandelt, wenig zu melden hat, wenn sich die Herrschaften des Rechnungshofes ankündigen. In diesem Sinne muss man sich nicht nur prozesstechnisch anpassen, sondern eben auch kulturell.
Aber um auch mal etwas positives zu sagen: Verglichen mit dem V-Modell 92 und 97 ist das V-Modell XT bereits ein riesiger Schritt in die richtige Richtung und hat bereits so manche Kritik an den alten Modellen aufgegriffen. Ich glaube, dass sich die Lücke in den nächsten Jahren weiter schließen wird, nachdem die Diskussion, ob agile Entwicklung überhaupt „echtes Software-Engineering“ sei zugunsten der agilen Verfahren ausgestanden sein dürfte.
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:
- Michael Porter: Wettbewerbsvorteile, Campus 1996, ISBN 3-593-34144-1 gilt als das Standardwerk zu Marktstrategien
- Tom DeMarco, Timothy Lister: Peopleware, Dorset House 1987, ISBN 0-932633-05-6 sollte man zumindest einmal in seinem Leben gelesen haben
Surftipp: Der Procuct Owner in größeren Teams
Einen sehr schönen Beitrag zur Agile 2007 haben Mike Lowery und Marcus Evans von der BBC zum Thema „Scaling Product Ownership“ verfasst. Sie beschreiben die Schwierigkeiten, die ihr 90-köpfiges Team durchlitt, bevor es die richtige Organisation für ihren fachlich Verantwortlichen („Product Owner“) gefunden hatte. Nicht nur die Ergebnisse sind interessant; auch der Weg ist typisch für agile Teams: Ausprobieren, scheitern, anders probieren, besser scheitern und schließlich doch einen guten Weg finden. Zwanzig Leseminuten, die sich lohnen.
Warum Auftraggeber agil sein sollten
Wenn ich Vorträge oder Workshops zu agilen Geschäftmodellen gebe, lautet eine meiner ersten Fragen an das Publikum „Wer von Ihnen ist eher Auftraggeber?“ Meist haben sich ein oder zwei Auftraggeber in das Publikum verirrt, der Rest stammt aus Softwarehäusern, die gerne agil arbeiten wollen, aber „nicht wissen, wie ich meinen Kunden dazu bringe“.
Das erstaunt: Es sollten eigentlich die Auftraggeber sein, die agile Entwicklung einfordern. Sie haben den wesentlichen Nutzen aus den Techniken:
- Sie erhalten regelmäßig lauffähige Software, die bereits früh eingesetzt werden kann. Das verringert das Risiko eines Totalausfalls erheblich und bietet zudem die Chance, bereits während der Entwicklung umzusteuern
- Sie müssen nicht alle fachlichen Inhalte ganz am Anfang festlegen, sondern können sich Optionen offen lassen, bis die Entwicklung an dieser Stelle angekommen ist
- Fachliche Diskussionen laufen am konkreten Beispiel. Ihre Fachexperten müssen nicht in abstrakten Methoden geschult werden, um eingesetzt werden zu können
- Das Controlling ist wesentlich verbessert: Statt vieler grüner Ampeln, die acht Wochen vor Systemstart „überraschender Weise“ auf rot schalten, wird Fortschritt in abgenommener Funktionalität gemessen – ein wesentlich zuverlässigeres Maß
- Sie erhalten die aus Ihrer Sicht wichtigsten Teile zuerst und behalten über die gesamte Laufzeit die Kontrolle über das, was als nächstes angegangen wird
- Sie können das Projekt beenden, wenn Sie feststellen, dass die bisher erreichte Funktionalität ausreicht; nicht erst, wenn alles implementiert ist, was Sie sich zu Anfang einmal ausgedacht haben. Das kann die Kosten schon mal um 60 oder 80 Prozent reduzieren
Warum sind dennoch eher wenige Auftraggeber an agile Konzepten interessiert? Ich denke, da kommen verschiedene Gründe zusammen:
- Die Macht der Gewohnheit führt dazu, dass sich viele Auftraggeber längst mit Prozessen arrangiert haben, die sie eher knebeln, als ihnen die nötige Freiheit zu geben. Die internen Strukturen sind an Werkverträge zum Festpreis angepasst. Andere Formen benötigten andere Strukturen, die erst aufgebaut werden müssten
- Die Vorstellung, Individualsoftware sei als „Gewerk“ behandelbar, das einmal spezifiziert nach definierter Zeit „frei Bordsteinkante“ geliefert wird, hält sich hartnäckig vor allem unter fachfremden Entscheidern, wie Juristen und Betriebswirtschaftlern. Hier ist es uns noch nicht gelungen, das notwendige Problembewusstsein zu schaffen. Zudem fehlen bisher Standard-Vertragsmodelle, um agile Entwicklung abzudecken — auch wenn es durchaus vielversprechende Ansätze gibt
- Gängige Risikobewertungen unterschätzen häufig die enorme Kosten, die von scheiternden strategischen Projekten ausgehen ebenso, wie die Wahrscheinlichkeit, dass der GAU eintritt. Zur Risikoabwehr werden Vertragsklauseln bemüht. Das verkennt, dass solche Klauseln höchstens die direkten Kosten auf den Vertragspartner abwälzen — kein Trost, wenn man selbst wegen Softwareproblemen Konkurs geht oder man den Vertragspartner schon mit einem Bruchteil des Schadens ruinieren würde
- Agile Entwicklung verlangt Entscheidungsfähigkeit auf Seite des Auftraggebers. Nicht jede Organisation kann das gewährleisten
- Last but not least: Wir haben bisher versäumt, auch nicht-technischen Auftraggebern die Ideen agiler Entwicklung nahe zu bringen.
Fazit: Agile Entwicklung ist vor allem für die Auftraggeber interessant, denen am Erfolg ihres Auftrages gelegen ist. Dann lassen sich auch organisatorische Hürden schleifen und Vertragsmodelle gestalten, die die benötigte Flexibilität aufweisen ohne beide Seiten unnötig einzuschränken.