Die agile Kolumne

CMMI Miami

Arne Roock

Das Setting: Ein verlassenes Großraumbüro mit umgekippten Stühlen. Flackernde Neonlampen. Auf Whiteboards und Flipcharts wurden Unmengen von Diagrammen und Skizzen gemalt. Eine Ampel, die an der Wand montiert ist, taucht die Szene in rotes Licht. Die Tische sind mit Stiften, Karteikarten und Haftnotizen übersät. Auf einem Monitor ist zu lesen: „Build failed!“

Zwei Agenten betreten den Tatort. Sie tragen Metallkoffer, auf denen mit großen Buchstaben „CMMI Miami“ steht.

Horatio (nimmt seine Sonnenbrille ab): „Ich sehe sofort: Hier ist ein Projekt gestorben!“

Calleigh: „Die Frage ist nur: War es Mord oder ein Unfall?“

Horatio: „Ich schwöre dir, dass ich das herausfinden werde! In diesem Raum wimmelt es nur so von Beweisen. Die werden uns bald die gesamte Geschichte verraten.“

Calleigh (sammelt einige Karteikarten auf): „Sieh mal hier: Anforderungen wurden per Hand auf Karteikarten geschrieben. Oben sind kreisrunde Abdrücke zu sehen. Ich gebe das zur Sicherheit ins Labor. Aber ich wette, die Abdrücke passen zu den Magneten dort. Also hingen die Karten an diesem Whiteboard und wurden mehrmals umgehängt.“

Horatio: „Gut beobachtet, Calleigh! In der Zwischenzeit habe ich eben mal kurz dieses Notebook ausgelesen. Darauf befindet sich eine Excel-Liste mit priorisierten Anforderungen. Daraus wurden offenbar die Karteikarten erstellt. Außerdem gibt es da verschiedene Diagramme zur Releaseplanung.“

Calleigh: „Dort drüben hängen handgemalte Burndown- und Velocity-Diagramme. Und hier liegen Planning-Poker-Karten. Dann ist eins jetzt klar: Das Projekt wurde nach Scrum durchgeführt!“

Horatio (setzt sich langsam seine Sonnenbrille auf): „Ja, richtig. Aber nicht nur das. Sieh mal, in welchem Winkel Mäuse und Tastaturen zueinander liegen. Fällt dir dabei etwas auf?“

Calleigh: „Klarer Fall: Hier wurde im Paar programmiert!“

Horatio: „Genau. Und die Ampeln da drüben sind mit dem Integrationsserver verbunden und geben den aktuellen Build-Status wieder. Außerdem hat die Auswertung des Codeschnipsels, den ich sicherstellen konnte, ergeben, dass das Team testgetrieben vorgegangen ist. Die Ausrichtung des Beamers legt weiterhin nahe, dass regelmäßig gemeinsame Coding-Dojos oder Katas durchgeführt wurden. Eric soll sich das noch mal genauer mit dem Schwarzlicht-Scanner ansehen.“

Calleigh: „Dann hat das Team also auch verschiedene agile Entwicklungspraktiken verwendet, die aus XP und der Clean-Code-Offensive bekannt sind. Das sieht mir doch wie ein solider CMMI-Level 3 aus. Wieso konnte das Projekt dann so grausam scheitern?“

Horatio (kaut nachdenklich am Bügel seiner Sonnenbrille): „Wir sind ganz nah an der Lösung. Aber ein wichtiges Puzzleteil übersehen wir. Denk nach, Calleigh!“

Calleigh: „Vielleicht sieht es auch nur aus wie Level 3. CMMI schreibt ja nicht vor, dass man bestimmte Praktiken einsetzen soll, sondern dass sie auch zu den jeweiligen Geschäftszielen und organisatorischen Eigenheiten passen müssen. Was wäre, wenn wir es hier mit einem Projekt zu tun haben, das sich nicht für Scrum eignete?“

Horatio: „Du hast es! Zusätzlich kann es auch sein, dass Scrum zwar in diesem Team gelebt wurde, aber nicht richtig in der übrigen Organisation verankert war. Auch das kann einem Projekt den Todesstoß verpassen. Eine Deadline im wahrsten Sinne des Wortes!“

Calleigh (lacht): „Wieder einmal hast du dein Versprechen gehalten und den Fall gelöst, Horatio! Die Projektmörder sollen sich warm anziehen!“

CMMI Miami am Tatort
Perspektivenwechsel

Das Reifegradmodell CMMI (Capibility Maturity Model Integrated) ist in der agilen Community eher unbekannt und unbeliebt. Das liegt zum einen daran, dass das SEI (Software Engineering Institute), das hinter CMMI steht, nicht gerade als agiler Vordenker bekannt ist. Zum anderen drehen sich die Diskussionen über CMMI häufig nur um einen einzigen Aspekt: die Zertifizierung auf einen bestimmten Reifegradlevel. Diese Zertifizierungen (SCAMPI Appraisals) sind in der Tat nicht ganz ohne. Denn es ist ein erheblicher Aufwand nötig, um Nachweise unterschiedlicher Art zu erbringen (was in der Regel durch Berge von Dokumenten geschieht). Das ist für kleine und mittelgroße Unternehmen kaum zu leisten.

Sinn und Unsinn von Zertifizierungen soll an dieser Stelle nicht das Thema sein. Aber wenn wir Zertifizierung einmal beiseitelassen, bietet CMMI einige interessante Aspekte.

Da ist zunächst die Grundidee, dass nicht einfach bestimmte Praktiken eingeführt werden sollen, sondern dass die Geschäftsziele und organisatorischen Gegebenheiten auch dazu passen müssen. In diesem Sinne gibt es zwar Best Practices, die sich im Laufe der Jahre oftmals bewährt haben, aber diese Praktiken sind nicht für jede Organisation gleich gut geeignet.

Auf einer abstrakteren Ebene kann auch Scrum als so eine Best Practice angesehen werden. Ich bin großer Fan von Scrum und überzeugt davon, dass man mit Scrum in sehr vielen Fällen schneller bessere Produkte entwickeln kann. Aber es gibt auch Konstellationen, in denen Scrum keine gute Wahl ist, z. B.

  • wenn teambasiertes Arbeiten nicht sinnvoll ist, etwa weil die Tätigkeiten vergleichsweise anspruchslos sind.
  • wenn Mitarbeiter so unglaublich teuer sind, dass Auslastung wichtiger wird als die Durchlaufzeit (dann kann man durch Auflösung von Sprints und Teams wahrscheinlich eine bessere Auslastung erreichen).
  • wenn man Routineaufgaben wie Maintenance erledigt. Dann kann es mitunter sinnvoll sein, auf bestimmte Elemente wie Sprints zu verzichten.
  • wenn alles prima läuft und man eigentlich gar nichts ändern will.

Dann führt vielleicht nicht Scrum zum Erfolg, sondern eher Kanban. Oder „Entwickeln-auf-Zuruf“. Oder sogar Wasserfall! Scrum nur deshalb einzuführen, weil es alle anderen auch tun, ist sicher keine gute Idee.

Als zweiter Punkt ist an CMMI bemerkenswert, dass hier großer Wert darauf gelegt wird, die für gut befundenen Praktiken fest in der gesamten Organisation zu verankern. Hier legt CMMI den Finger auf einen wunden Punkt von Scrum. Denn häufig lässt sich beobachten, dass einzelne Scrum-Teams zuerst zwar durchaus erfolgreich arbeiten, aber mit der Zeit von ihrer Organisation ausgebremst werden. Bestimmte Vertragsmodelle mit Kunden und Zulieferern können einer nachhaltigen Scrum-Einführung ebenso entgegenstehen wie Karrieremodelle oder individuelle Prämiensysteme für die Mitarbeiter (die so die Teamarbeit im Scrum-Sinne behindern). Und oft genug werden Produkte ja nicht von einem einzelnen Team entwickelt, sondern es ist die Zusammenarbeit verschiedener Teams notwendig. Letztlich muss also die Ebene der Gesamtorganisation betrachtet werden, wenn Scrum dauerhaft etabliert werden soll. Natürlich ist es in Ordnung, mit einem Pilotprojekt zu starten, um hieraus wichtige Lernerfahrungen zu ziehen. Aber nach ersten Erfolgen sollte bald darüber nachgedacht werden, wie Scrum hochskaliert werden kann.

Und schließlich gibt es in CMMI einen weiteren interessanten Aspekt, der dann doch wieder mit den 5 Reifegrad-Leveln zu tun hat (aber nicht unbedingt etwas mit Zertifizierung). Sieht man sich die hohen Level 4 und 5 an, dann wird klar, dass sich wirklich reife Teams und Organisationen dadurch auszeichnen, dass sie nicht nur reproduzierbar gute Ergebnisse liefern, sondern dass sie darüber hinaus quantitatives Management verwenden (Level 4) und ihren Prozess immer weiter optimieren (Level 5). Quantitatives Management ist ein spannendes Feld, das sich rudimentär zwar auch in Scrum findet, jedoch in Kanban wesentlich ausgeprägter ist. Dabei ist entscheidend, dass nicht um jeden Preis möglichst viele Metriken erfasst werden, sondern dass man sich Gedanken darüber macht, welche Messwerte einem helfen, den Prozess tatsächlich zu verbessern. CMMI sieht für quantitatives Management in erster Linie vor Statistic Process Control (SPC) vor. Aber auch Metriken wie die Durchlaufzeit (Lead Time), die Termintreue (Due Date Performance) oder die Anzahl an Bugs im Produktivsystem können wichtige Anhaltspunkte zur Verbesserung geben. Natürlich gilt auch hier, dass der Aufwand in einem vernünftigen Verhältnis zum Nutzen stehen muss. Wenn man irgendwann feststellt, dass zwar massenhaft Metriken erstellt werden, aber niemals mehr angesehen werden, dann ist es Zeit für Anpassungen.

Bleibt noch der Aspekt der kontinuierlichen Verbesserung, der eine wichtige Rolle in allen agilen Methoden spielt. Wir sollten uns immer wieder vor Augen führen, dass wir niemals stehen bleiben dürfen, wenn wir nicht gut, sondern ausgezeichnet werden wollen. Dazu kann es dann auch gehören, wieder von seiner gewählten Methode (etwa Scrum nach Lehrbuch) abzuweichen und sie für sich selbst anzupassen. Die Kunst besteht darin, nicht einfach die unbequemen Aspekte wegzulassen und sich damit herauszureden, dass man genau diesen Aspekt ja sowieso nicht benötigt. In der Regel ist es tatsächlich zu empfehlen, eine Methode so lange in Reinform anzuwenden, bis man sie wirklich verstanden hat. Erst dann können (und sollten) Anpassungen vorgenommen werden.

Fazit: CMMI ist bei weitem nicht so schlimm, wie wir es uns vielleicht vorstellen, und enthält abseits der Zertifizierung viele interessante Aspekte, über die es sich auch in agilen Kontexten nachzudenken lohnt.

Arne Roock arbeitet bei der it-agile GmbH in Hamburg. Als studierter Germanist interessiert er sich für informative, leicht verständliche und kooperative Kommunikation. Außerdem beschäftigt er sich seit Längerem mit den Themen Selbstorganisation und Zeitmanagement in der IT.
Geschrieben von
Arne Roock
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.