oder
Kapitel 1: Der Schock
Es war einmal ein Software Team, das bestand aus vielen engagierten und motivierten Softwareentwicklern und Testern. Das Team gehörte dem König, seine Mitglieder kamen aus aller Herren Länder. Die Menschen hatten schon seit mehr als einer Dekade erfolgreich in diesem Team zusammengearbeitet um Software für den RoboRitter des reichen Kaiser zu entwickeln.
Der Kaiser war war immer sehr glücklich gewesen über seinen RoboRitter. Immer hatte er alle Software Funktionen erhalten, die er sich gewünscht hatte. Zwar hatte das immer wieder sehr lange gedauert, weil der Kaiser nicht wirklich wusste, was er wollte. Das Team half ihm jedoch immer dies herauszufinden. Sie lieferten alle 2 – 3 Jahre neue Software und erfuhren so, was der große Kaiser nicht wollte. So korrigierten sie die Software Jahr für Jahr und am Ende war alles gut.
Der König, dem das Software Team gehörte, verdiente gutes Geld und der Kaiser erhielt immer wieder ein Softwareupdate für seinen RoboRitter.
Da begab es sich, dass sich der Kaiser neue Berater an seinen Hof holte:
…zu teuer, zu teuer, zu teuer, zu teuer, zu teuer….,
… zu schlecht, zu schlecht, zu schlecht, zu schlecht….
flüsterten sie ihm ins Ohr. Und so kam was kommen musste. Der Kaiser ließ den König und den Teamleiter an seinen Hof rufen und ließ verkünden: „Wenn ihr es nicht schafft die Softwarekosten um 50% zu reduzieren und doppelt so schnell zu liefern, dann werde ich die Softwareentwicklung in den mittleren und fernen Osten vergeben.
Zwar argumentierten König und Teamleiter, dass die hohen Kosten wohl offensichtlich dadurch entstünden, dass der Kaiser selbst nicht wüsste, was er wollte und die ständigen Requirement Changes und Korrekturen diese Kosten verursachen würden. Doch anstatt auf Verständnis hoffen zu können, wurde der Kaiser nur noch ärgerlicher. Er glaubte nicht was er hörte und war sicher dass der König sein Geld verprasste, anstatt es in die Softwareentwicklung zu stecken.
Kapitel 2: Die Strategie der Mäuse
Betrübt zogen König und Teamleiter ab.
Zuhause angekommen jammerten Sie, sie hätten immer alles gemacht, was der Kaiser forderte. Er habe immer alles bekommen, jeden Wunsch hätten Sie ihm erfüllt, jeden Requirement Change akzeptiert. Sie hätten 24/7 an der Software gearbeitet, hätten Urlaub der Untertanen verfallen lassen. Immer hätten sie die Software ausgeliefert, die sie Jahre zuvor vertraglich festgelegt hätten. Und jetzt sollen sie alles verlieren an ein Königreich im weiter Ferne, das zuvor nie etwas für den Kaiser getan hätte.
Während alle im Team noch jammerten kamen plötzlich zwei Mäuse daher und führten ein lustiges Tänzchen auf. Die Menschen im Team hielten inne und waren umso erstaunter, als die Mäuse zu sprechen begannen: „Warum schaut ihr denn so bedröppelt daher?“ Also erzählte der Teamleiter die ganze Geschichte. Schnüffel und Wusel – so hießen die beiden Mäuse [Quelle: die Mäusestrategie von Spencer Johnson] – begannen zu lachen. „Ihr Menschen seid schon komisch, anstatt etwas zu ändern, jammert ihr und habt Angst. Wie könntet Ihr eure Situation denn verbessern? Wie könntet Ihr denn auch künftig euer Brot verdienen? Was sind denn die Ursachen für die hohen Kosten? Wieso weiß euer Kaiser nicht was er will? Was könntet Ihr tun um ihm dabei zu helfen? Warum seid ihr so unflexibel?
Dann erzählten Sie, dass in Ihrer Welt die Menschen und die Mäuse von Käse lebten, der immer da gewesen sei. Plötzlich sei er weg gewesen. Die Menschen hätten zu jammern begonnen. Sie, die Mäuse, hätten es aber angepackt und seinen ausgezogen um neuen Käse zu suchen. Heute hätten Sie besseren Käse als je zuvor, während Grübel – so hieß ein Mensch aus Ihrer Welt – wahrscheinlich verhungert wäre.
Kapitel 3: Wir werden agil
Von den Mäusen zum nachdenken gebracht, setzten sich der König, der Teamleiter und sein Team zusammen und reflektierten, was sie erlebt hatten. Was war schief gelaufen:
- Kaiser und König waren tagelang zusammen gesessen, um in einem umfangreichen Vertrag detailliert festzuschreiben, welche Fähigkeiten seine RoboRitter haben sollten.
- Der König trug die Erkenntnisse in sein Königreich und diskutierte diese mit dem Teamleiter. Es ergaben sich neue Fragen, denn…
- … es war aber immer wieder zu Verständnisschwierigkeiten und Missverständnissen zwischen Kaiser und König gekommen, die erst sehr viel später bemerkt worden waren.
- Es mussten wieder Gesandte zum Kaiser geschickt werden, um die Missverständnisse zu klären. Dieser Prozess wiederholte sich einige Monate. Dann wurde der Vertrag unterschrieben.
- Der Teamleiter und sein Team hatten jetzt eine Grundlage Ihre Arbeit zu beginnen.
- Just als Sie beginnen wollten, kamen Boten vom Kaiser mit Änderungswünschen…
Die Mäuse hatten recht, sie mussten ihr Vorgehen anpassen. So konnte es nicht weitergehen. Das Team setzte sich zusammen und brütete….
Was ist für den Kaiser wichtig? Wie können sie ihn auch künftig zufriedenstellen?
- Der Kaiser will immer etwas zum spielen habe, er wollte nicht 2 Jahre auf einen neuen RoboRitter warten. Wenn er seine Software schneller haben wollte, so müssten sie das hinkriegen.
- Der Kaiser hatte nur eine Schatulle von Talern, die er ausgeben konnte. Die Taller mussten für alles reichen was er wünschte.
- Der Kaiser sollte seine Wünsche jederzeit einbringen können, und dafür keinen neuen Vertrag aufsetzen und ohne dass dies die Softwareauslieferung verzögern würde.
- Sie müssten also dem Kaiser regelmäßig funktionierende Software mit kleinen Funktionsupdates schicken, so dass er damit spielen konnte und sehen ober er das bekam was er wollte.
- Sie schlugen vor, dass Gesandte des kaiserlichen Hofstaates im Team mitarbeiteten, um die Ergebnisse der Entwicklung wöchentlich bewerten zu können. Dazu würden Sie vom Kaiser eine Kopie des RoboRitters ins Team abgestellt bekommen, den sie kontinuierlich mit der aktuellsten Software ausstatten würden.
- So konnten auch alle Entwickler und Tester, sowie die Gesandten des Kaisers mit dem RoboRitter spielen und früh testen..
- Der König setzt sich regelmäßig mit dem Team und den Gesandten des Kaiserhofes zusammen, um den Fortgang des Projekts zu besprechen und gegebenenfalls Probleme und offene Fragen schnell zu klären.
- Kaiser und König würden so nicht lange an Verträgen sitzen, sondern das Team begänne mit der Softwareentwicklung, sobald der König die ersten auslieferbaren Funktionen verstanden und definiert hätte.
- Die Fähigkeiten des RoboRitters würde so Schritt für Schritt kontinuierlich wachsen.
- Um die Kosten zu kontrollieren, würde der Funktionszuwachs in ÄquivalenzTalern gemessen, zB. so: eine neue Muskelbewegung des RoboRitters entspräche einem Taler, eine neue Beinbewegung 3 Talern, das Erkennen von neuen Objekten 10 Talern. Die Bewertung würden Sie gemeinsam mit den Gesandten des Kaisers treffen. Sie würden zuvor sich auf eine Maximalanzahl von Talern einigen.
- Der König würde sich dann nicht mehr in die Arbeit seines Teams einmischen.
- Dafür würde das Team lernen und seine Vorgehensweise regelmäßig anpassen und verbessern.
- Durch die Anwesenheit der Hofgesandten im Team würde auch das Vertrauen zwischen Kaiser und König kontinuierlich wachsen
Mit diesem Vorschlag reiste der König zum Kaiser. Der Kaiser erkannte als wesentlichen Vorteil die enorme Flexibilität der Vorgehensweise. Er konnte mit den kontinuierlichen Produktupdates spielen, und schnell erkennen, wenn ihm etwas nicht gefiel. Das Team konnte sofort starten, ohne dass lange Verträge ausgehandelt werden mussten.
Aber das ursprüngliche Thema Kosten machte dem Kaiser nach wie vor Kopfzerbrechen. Der König erklärte dem Kaiser jedoch das System der ÄquivalenzTaler. Gemeinsam würden sie abschätzen, wieviele neue Funktionen, also wieviel ÄquivalenzTaler der Kaiser in den letzten 2 Jahren wohl erhalten hätte. Dann versprach der König, dass sein Team die gleiche Menge an Talern in einem Jahr liefern könnte und dies auch noch zum halben Preis.
Das machte den Kaiser sehr glücklich. Er verbannte die Berater von seinem Hofe, hatten Sie ihn doch mehr Geld gekostet als die gesamte Softwareentwicklung.
So liefert der König und sein Softwareteam nunmehr seit vielen Jahren Software für des Kaiser RoboRitter und alle seine neuen Spielzeuge. Und wenn sie nicht gestorben sind…
Dichtung oder Wahrheit….
…diese Frage mögen Sie, verehrter Leser mir nun vielleicht stellen.
Die Geschichte ist wahr. Es handelte sich zwar nicht um einen Kaiser, sondern um einen europäischen öffentlichen Auftraggeber, der König war der Programmleiter eines sehr großen Konzerns, der Team- und Projektleiter, das war ich. Wir entwickelten Software für ein Flugzeug. Wir standen vor dem Problem, nicht schnell genug neue Funktionen in Form von Software zur Verfügung stellen zu können, weil es in der komplexen Systementwicklung einfach zu viele Unbekannte gab und weil an vielen Stellen parallel entwickelt wurde.
Der erste Schritt bestand damals darin, zuerst mein Team und die Programmleitung dafür zu begeistern, etwas völlig neues auszuprobieren (Haben wir schon immer so gemacht !)
Ich habe damals jedem Mitarbeiter eine Kopie der Mäusestrategie von Spencer Johnson zukommen lassen. Und wir haben es geschafft. Wir nannten die Vorgehensweise damals Flexibe Software Development FSD. Dafür wurden wir am Ende sogar mit einem Kunden Award ausgezeichnet.
Flexibe Software Development = Agile Software Entwicklung
Die Geschichte begann übrigens im Jahre 2000. Ich bedanke mich an dieser Stelle bei meinen damaligen Teamkollegen aus dem MST, meinen damaligen Chefs, meinem damaligen Programmleiter (WGN ;-)), meinen Sparringpartnern PK, JK, PL, OO, MN, sowie bei all den Ansprechpartnern beim Kunden, vor allem JB, und allen die uns vertraut haben und mitgezogen sind.
Im Rahmen meiner Vorlesung Einführung ins Projektmanagement habe ich mit Prof. Dr. Ing. Roland Greule das obige Beispiel quasi als Best Practice besprochen.
Bildnachweis auf dieser Seite: Bild 1: Urheber alga38 © 123rf.com , Bild 2: Urheber Oleg Zhevelev © 123rf.com , Bild 3: Arthur Wendelgaß
