Schenkt man den Maya Glauben, müssen wir dieses Jahr bereits am 21.12. mit allen Projekten fertig sein. Das bedeutet, dass uns 10 Tage in diesem Jahr fehlen. Zeit also, schneller und besser zu werden. Denn, glaubt man den Maya weiter, werden wir anschließend keine Gelegenheit für Korrekturen und Bugfixes haben. Schauen wir uns zum einen an wie man diese Deadline halten kann und zum anderen ob die Entwicklungsmethode des Mayakalenders als adäquat angesehen werden darf.
Wenige Softwareprojekte schaffen die Vorgaben
Diversen Studien zufolge überschreiten über 90% aller IT-Softwareprojekte ihr Budget und nahezu alle Projekte sprengen den geplanten Zeitplan. Nur knapp die Hälfte aller IT Projekte werden überhaupt erfolgreich abgeschlossen und 20% der Projekte werden bereits vor ihrem Abschluss komplett abgebrochen. Als zentralen Punkt identifizieren die Studien eine nicht adäquate Entwicklungsmethode von Software, neben üblichen Management-, Planungs- und Steuerungsfehlern. Da fragt man sich unweigerlich zum Mayakalender-Ende “21.12.2012”: ist es ein Bug oder ein Feature? Oder wird der Kalender ab diesem Datum einfach nicht mehr supportet? Kommt anschließend Mayakalender 2.0? Wie auch immer, wir müssen erst mal davon ausgehen, dass der 21.12.2012 eine unverschiebbare Deadline für alle Projekte darstellt – getestet, bugfrei und abgenommen. Das bedeutet natürlich ebenfalls, dass eher das Budget als der Zeitrahmen überschritten werden darf. (Notiz an mich selbst: Weihnachtsgeschenke dieses Jahr erst nach dem 21.12. kaufen)
Scrum gegen die Maya – schneller, besser, budgettreu
Lange und komplexe Softwareprojekte bieten jede Menge Potential für Fehler in Anforderungen und in der Entwicklung. Gleiches gilt natürlich für die Entwicklung eines langfristigen Kalenders. Klassische Projektmanagementmethoden verhindern meist ein rechtzeitiges Gegensteuern oder das Implementieren neuer Ideen. Liegt hier der Mayahase im Pfeffer? Im Gegensatz zu den klassischen Methoden ist Scrum ein agiles Managementframework und Vorgehensmodell zur Entwicklung von Software. Scrum ist dabei ein empirischer Prozess, ohne starre Templates oder Verfahrensanweisungen. Das heißt, Prozesse und Arbeitsweisen werden in Reviews und Retrospektiven immer wieder begutachtet und bei Bedarf angepasst, um Verbesserungen zu erreichen. So hochentwickelt wie die Mayakultur war, wundert es, dass sie nicht selbst drauf gekommen sind. Vielleicht hielt man aber auch zu lange an der Vorstellung fest, dass Hierarchie wie eine Stufen-Pyramide zu sein hat.
Iteration und Konvergenz für bessere Ergebnisse
In fest definierten Zyklen (sog. Sprints) werden iterativ auslieferbare Produkt-Inkremente erstellt. Auch der Mayakalender arbeitet mit Zyklen aber vielleicht zu lang? Wie auch immer, sie waren also dicht dran, denn die Vorteile liegen auf der Hand: überschaubarere Entwicklungseinheiten und flexiblere Produktion lassen Raum für schnelle Feedbacks und Optimierungsmöglichkeiten. Die Qualitätskontrolle sichert jedes Iterations-Ergebnis bereits am Sprintende ab, verzichtet dafür aber auf rituelle Blutopfer. Schnellere “Time to Market” zieht früheres Break-Even und Return on Investment (ROI) nach sich. Wobei das Problem des Mayakalenders nicht in der Time-to-Market sondern in dem automatisierten Ende des Mayakalender-Produktlebenszyklus zu sehen ist. Vielleicht hätte man das Risiko des missglückten Projekts durch permanente Anpassungsmöglichkeit minimieren können.
Scrum rettet unsere Projekte
Ein optimal implementiertes Risikomanagement sollte das Ende der Welt 2012 unbedingt berücksichtigen. Letztendlich liegt die Wahrscheinlichkeit hierfür bei 50%. Nehmen wir an, dass ca. 96% der Projekte über dem Zeitplan liegen, sollten wir uns dieses Mal anstrengen, die Timeline absolut einzuhalten. Dass Scrum hierfür ein adäquates Mittel ist, haben wir schon gesehen. Sicher ist sicher, denn wenn die Maya Recht haben, haben wir sonst ein Problem. Oder möchte irgendeiner während eines unfertiges Projekts, im Büro sitzend, abtreten? Wäre es nicht viel schöner, das Projekt rechtzeitig abgeschlossen zu haben und zum großen Knall mit einem Cocktail im Liegestuhl zu sitzen und sich das Feuerwerk live anzuschauen? Nun mag jemand sagen, dass es völlig egal ist, weil nächsten Tag weder das Büro steht noch der Chef da ist und die Projektergebnisse prüft. Aber was, wenn die Maya sich geirrt haben? Dann steht das Büro nächsten Tag noch da und der Chef… mit ein bisschen Glück ist “jemand” dann nur gefeuert und nicht, wie bei den Maya üblich, geopfert.
Kalenderende 21.12.2012 – Bug oder Feature?
Ja was denn nun… mag sich mancher Fragen. Bisher bin ich davon ausgegangen, dass das Ende entweder konstruiert ist, um Maya 2.0 Platz zu machen oder aber es ist ganz einfach ein vermeidbarer Bug. Dass es sich um einen Bug handelt, liegt nahe, wenn man sich die Chronik der (verpassten) Weltuntergänge vor Augen hält. An die 100 Weltendszenarien und -termine wurden von der Erde einfach ignoriert. (Das Riskmanagement fordert trotzdem ein Projektende im Dezember 2012!) Nehmen wir also eine Eintrittswahrscheinlichkeit von 50% an und multiplizieren das ganze mit bisher 100% nicht-eingetretenen Weltuntergangsprophezeihungen und zusätzlich mit der permanenten 10% Wahrscheinlichkeit, dass irgendein Drittewelt-Staat beim Spielen mit Atombomben einen Fehler macht. Ich komme dann auf eine Die-Welt-dreht-sich-Weiter-Wahrscheinlichkeit von ca. 2/3. Das reicht mir, um den 21.12.2012 als Deadline in meine Planung aufzunehmen aber mit einer 2/3 Wahrscheinlichkeit damit zu rechnen, am 22. zur Arbeit erscheinen zu müssen.
Schlussfolgernd muss man also annehmen, dass es einen Fehler im Maya-Kalender oder seiner Interpretation gibt. Punkt 1. wäre mit Scrum vermeidbar gewesen und Punkt 2. deutet auf eine sauschlechte Dokumentation hin – auch mit Scrum übrigens vermeidbar.
Was ist denn nun passiert?
Ich habe in großen Konzernen gearbeitet. Was ich dort erlebt habe… die würden heute noch einen solchen Kalender entwickeln. Nicht fertig und undokumentiert. Das Schlimme bei gefrickelten Projekten ist, dass sie qualitativ schlecht sind, nicht skalierbar, nicht erweiterbar und unwartbar, ohne Dokumentation dahinvegetieren. Bei meinen Konzern-Projekten war das größte Problem, dass nicht nur nichts dokumentiert war sondern, dass die Leute, die’s entwickelt haben, den Konzern längst samt Spezialwissen verlassen haben. Hätte es schon Scrum gegeben, wäre eine Weiterentwicklung der Systeme dank Pairprogramming, Modularisierung und Dokumentation möglich gewesen. Ich denke exakt das gleiche Problem finden wir bei den Maya: Ein Kalender wird per Wasserfallmodell von einem Team entwickelt und nicht dokumentiert. Fehler werden vielleicht gesehen, sind aber irgendwann zu aufwändig zu eliminieren. Man konzentriert sich drauf, dass das System lange genug hält, bis alle weg sind. 2012 schien diesbezüglich als Laufzeit auszureichen. Aber wo sind die Teams hin? Warum wurde die Entwicklung des Mayakalender 2.0 nicht an die Spanier übergeben? Fakt ist jedenfalls, dass keine Hinweise entdeckt wurden, die auf den Beginn einer neuen Schöpfung im Jahr 2012 hindeuten. Mangelnde Dokumentation oder keine Lust gehabt, weiterzuarbeiten?
Mayakalender-Entwicklerteams gesucht!
Ob die Maya erblindungsbedingt gemeinschaftlich von der Pyramide fielen, als sie ohne geeignete Schutzbrille in die Sonnenfinsternis schauten, oder einfach zu viele Kollegen den Sonnen-Göttern geopfert haben… man weiß es nicht. Doch auch diese beiden mayaesquen Endzeitszenarien wären mit Sicherheit bei einer ordentlichen Nutzung von Scrum rechtzeitig aufgefallen. Dass die Entwickler das Team gemeinschaftlich verlassen haben, als der Kahn von den Spaniern übernommen wurde, ist eine andere Möglichkeit. Analogien zur letzten Version finden wir nach Übernahmeszenarien der heutigen Geschäftswelt zuhauf.
Und, so wie der Mayakalender kaum zu knacken ist, sind auch moderne Systeme gewollt verbarrikadiert. Angesichts dieser Tatsache würde ich sagen, die Maya wohnen heute vielleicht in Cupertino.