Scrum und CMMI (Teil 1/2)

Eines der Probleme bei der Einführung agiler Methoden, so haben wir schon ab und zu gehört, ist ihre Integration in bereits vorhandene Frameworks und Referenzmodelle. Eines dieser Modelle ist CMMI.

CMMI, bzw. das Vorgängermodell CMM, ist ein 1986 von der Carnegie Mellon University im Auftrag des US-Verteidigungsministeriums entwickeltes Reifegradmodell.

Es wurde entwickelt, als sich im Rahmen des SDI-Programms (Strategic Defense Initiative, im Volksmund auch als “Star-Wars-Projekt” bekannt) herausstellte, daß es bei der Implementierung hochkomplexer Software durch externe Lieferanten zu vielfältigen Arten von Problemen kommen kann. Oftmals entsprachen Liefertermin, Umfang und Qualität nicht den vertraglichen Abmachungen.

Um diese Probleme einzudämmen verpflichtete das Ministerium alle potentiellen Auftragnehmer, sich nach dem CMM-Modell zu zertifizieren. So konnte eine bessere Risikoeinschätzung bei der Projektvergabe erfolgen.

Anfangs setzen deswegen auch nur solche Firmen das CMM ein, die vom US-Verteidigungsministerium dazu gezwungen wurden. Es stellte sich aber bald heraus, daß auch die Auftragnehmer einen Nutzen davon hatten, und so begannen in der Folgezeit immer mehr Firmen damit, CMM “freiwillig” zur Verbesserung der eigenen Prozesse zu nutzen. Heute ist CMM (bzw. das Nachfolgemodell CMMI) in einigen Bereichen zum Standard geworden. So verlangen z.B. einige Automobilhersteller von ihren Zulieferern im Vorfeld einer Auftragsvergabe den Nachweis eines bestimmten Reifegrades.

Die Frage ist nun: Welchen Reifegrad können Organisationen erreichen, die agile Vorgehensmodelle einsetzen, bzw. passen Scrum und CMMI eigentlich zusammen?

Die (kurze) Antwort gleich vorab: Ja, es passt zusammen! Reifegrad 3 ist dabei noch mit Scrum-“Bordmitteln” zu erreichen. Für Level 4 und 5 muß man zusätzlichen Aufwand treiben, aber auch dies ist möglich.

Wenn man sich die in CMMI enthaltenen Forderungen zum ersten Mal durchliest, so stellt man schnell fest, daß sich der Großteil davon relativ unspektakulär liest und in erfolgreichen Projekten eigentlich selbstverständlich sein sollte. Die Herausforderung stellt sich jedoch trotzdem recht bald ein: Es gilt nämlich, alle diese Ziele gleichzeitig zu erreichen.

Die Umsetzung von Reifegrad 1 ist noch relativ einfach. Er besteht lediglich aus den beiden Zielen “Spezifische Ziele erfüllen” und “Basispraktiken umsetzen”.

Reifegrad 2 steht dann schon unter der Überschrift “Einen gemanagten Prozess institutionalisieren”. Wie der Prozess genau aussieht ist dabei zuerst einmal relativ egal (ein agiler Prozess ist also definitv erlaubt).

Dazu muß man folgende 10 generische Praktiken implementieren:

• 2.1 Erstellen einer organisationsweiten Strategie Festlegen, wann und unter welchen Umständen agile Methoden in der Organisation eingesetzt werden sollen.
• 2.2 Prozess planen Hier wird gefordert, einen Plan für die Umsetzung von Scrum zu erstellen und zu pflegen.
• 2.3 Ressourcen bereitstellen Um den angedachten Prozeß durchzuführen müssen Ressourcen bereitgestellt werden. Dies könnten etwa Mitarbeiter sein, aber auch benötigte Software und Tools. In Scrum werden Ressourcen z.B. in der Sprintplanung bereitgestellt, aber auch im Sprint Review.
• 2.4 Verantwortlichkeit zuweisen Basierend auf der Prozessplanung werden hier zu den einzelnen Prozessgebiete verantwortliche Personen genannt. Bei Scrum gilt es also hier, die drei Rollen Scrum Master, Product Owner und Team zu besetzen (die Rolle “Team” kann natürlich auch mit mehreren Personen besetzt werden)
• 2.5 Personen schulen Sollten die für das Projekt ausgewählten Mitarbeiter die für ihre Position notwendigen Qualifikationen noch nicht aufweisen, so müssen sie noch dafür geschult werden. Dies kann etwa eine Scrum Master- oder Product Owner-Zertifizierung sein, aber auch jede andere denkbare Variante des Trainigs. So ein Teammitglied z.B. noch Schwächen bei der Programmierug hätte würde hier auch Pair Programming noch unter Schulungsmaßnahmen fallen.
• 2.6 Konfigurationen managen Jedes Projekt wird irgendwann mal ein Ergebnis liefern (bei Scrum üblicherweise am Ende jeder Iteration). Darunter zählt nicht nur Quellcode, sondern etwa auch Handbücher, Pläne, Build-Dateien usw. .Diese Projektergebnisse gilt es ordentlich zu managen. Üblicherweise wird man hier deswegen irgendeine Art von Versionskontrolle einführen.
• 2.7 Relevante Betroffene identifizieren und einbeziehen Hier wird eine klassische Stakeholderanalyse durchgeführt. Dieser Punkt findet sich in Scrum direkt wieder durch die Unterteilung in “Pigs” (=die, deren Job vom Projekterfolg abhängt) und “Chickens” (Sonstige). Eine weitere Stärke agiler Methoden ist die direkte Einbeziehung des Kunden (als relevanten Stakeholder) in das Projekt.
• 2.8 Prozess überwachen und steuern Diese Forderung beinhaltet die Messung des tatsächlichen Projektfortschritts gegen den Projektplan, und bei Bedarf das Einleiten von Gegenmaßnahmen. Auch dies ist eine der großen Stärken von Scrum gegenüber traditionellen Vorgehensweisen, da dank dem täglichen Statusmeeting und dem täglich aktualisierten “Sprint Burndown Chart” immer ersichtlich ist, wie das Projekt gerade steht. Liegt man zurück, so wird dies unmittelbar bemerkt werden, was es wesentlich erleichtert, steuernd einzugreifen.
• 2.9. Einhaltung objektiv überwachen Natürlich bringt es nur dann etwas, einen Prozess festzulegen, wenn er auch umgesetzt und eingehalten wird. Die Erfahrung zeigt außerdem, daß die Beteiligten immer gerne zu dieser Behauptung neigen, auch wenn dies in Wahrheit gar nicht der Fall ist. Man benötigt also eine unabhängige Überprüfung durch jemanden außerhalb des Teams. In Scrum-Projekten ist dafür in erster Linie natürlich der Scrum-Master zuständig. Er ist nicht mehr Teil des Teams, und auch kein formaler Projektleiter mehr, der den einzelnen Personen Aufgaben zuweist (das Team ist ja selbst-organisierend), sondern dafür zuständig, daß der Prozess in Gang bleibt und auch eingehalten wird. Außerdem muß er noch Probleme aus dem Weg räumen, den Projektfortschritt beobachten oder Personalprobleme lösen. Einen Teil dieser Aufgabe übernimmt auch der Product Owner: Er sorgt dafür, daß das Projekt den Anforderungen des Kunden entspricht und von hoher Qualität ist.
• 2.10 Status mit höherem Management einem Review unterziehen Ziel dieser Forderung ist es, dem höheren Management einen guten Einblick in das Projekt zu geben, um aus den Problemen und Erfolgen die notwendigen Schlüsse zu ziehen und zu lernen. Scrum hat, wie alle agilen Methoden, einen hohen Anteil von Kommunikation und Interaktion (Sprintplanung, tägliches Statusmeeting, Reviews und Retrospektiven). Damit verbunden ist aber auch ein hohes Maß an Transparenz. Für das Management relevant sind hier vor allem das Sprint Burndown Chart und das “Impediment Backlog” (die Liste der aktuellen Probleme bei der Projektumsetzung). Problembeseitigung ist nämlich eine der Hauptaufgaben des höheren Managements in einer Scrum-Organisation. Natürlich steht es auch jedem Manager frei, eines der verschiedenen Scrum-Meetings zu besuchen und einen Blick auf die Statustafel zu werfen. Ein, zwei Besuche bei einem täglichen Statusmeeting sollten für eine vernünftige Einschätzung des Projekts ausreichen.

Soweit die für CMMI Level 2 geforderten Ziele. Wenn man sie mit einer Übersicht über Scrum vergleicht stellt man fest, daß man die meisten davon quasi mit “Bordmitteln” erreichen kann. D.h., wenn man Scrum so einsetzt wie es gedacht ist (ganz oder gar nicht), dann wird man diese Ziele relativ leicht erreichen können.

In der Fachliteratur ist oft davon die Rede, daß der Schritt auf Level 2 derjenige ist, der mit dem meisten Aufwand verbunden ist. Dies liegt aber nicht nur an den evtl. notwendigen Änderungen am bisherigen Prozess, sondern vor allem an den meistens ebenfalls anfallenden kulturellen Änderungen. Diese durchzusetzen kann jedoch durchaus eine langwierige und schwierige Aufgabe sein. Bei einer Scrum-Organisation scheint mir dieser kulturelle Unterschied jedoch nicht ganz so groß zu sein. Die kulturelle Anpassung sollte daher, so sie denn überhaupt notwendig ist, relativ gering ausfallen.

CMMI-Level 3 steht unter dem Motto “Einen definierten Prozess institutionalisieren”. Diesmal sind damit aber lediglich 2 generische Praktiken damit verbunden, die umgesetzt werden müssen:

• 3.1. Einen definierten Prozess aufstellen Dies ist eine Verfeinerungvon GP2.2 (siehe oben). Der Unterschied besteht hauptsächlich darin, daß nun die aufgestellte Definition unternehmensweite Gültigkeit haben soll. Wenn man also in einem Projekt Scrum einsetzen will, so gibt es jetzt dafür eine unternehmensweit einheitliche Definition, an die man sich zu halten hat. Auf diese Weise soll die Vergleichbarkeit zwischen einzelnen Projekten erhöht werden.
• 3.2 Verbesserungsinformationen sammeln Ziel hier ist es, quer überalle Projekte hinweg zu lernen, indem die Ergebnisse der einzelnen Projekte sammelt und miteinander vergleicht. Die Lehren hieraus könnte man in Scrum z.B. während der Sprint-Retrospektive wieder in die einzelnen Projekte zurückfliessen lassen.

Soweit die Übersicht darüber, wie sich auch mittels Scrum CMMI-Level 3 erreichen lässt. Doch dies ist natürlich nicht das Ende der Fahnenstange. Es lässt sich nämlich durchaus auch Level 5 erreichen (der höchste mögliche Level). Das soll jedoch Inhalt des nächsten Artikels werden…

BFE