Publikationen › CMMI › CMMI und Scrum

Scrum zur Umsetzung von CMMI

Für Unternehmen, die CMMI zur Verbesserung und Orientierung nutzen, kann Scrum agile Lösungen zum Management komplexer Projekte bereitstellen. Dieser Artikel beschreibt, wie Sie beides zusammen nutzen können.

CMMI und Scrum sind eine starke Verbindung

Wie Scrum und CMMI zusammen passen

CMMI ist eine Sammlung guter Praktiken, die eine professionelle Entwicklungsorganisation typischerweise lebt. CMMI beschreibt aber nur, "Was" zu tun ist – das konkrete "Wie" der Umsetzung gestaltet jede Organisation selbst. Dieses Finden des eigenen Weges ist gerade der Punkt, um den es CMMI geht. Warum? Weil die Arbeitsweise jeder Organisation auf der Kultur und den Werten der Organisation fußen muss, um funktionieren zu können. CMMI ist ein Gestaltungs-Coach, der einer Organisation genau die Fragen stellt, damit sie zu guten und zu ihrer Kultur passenden Lösungen kommt, bei denen an alles Wichtige gedacht ist.

So passen Scrum und CMMI nahtlos zusammen. Während CMMI z.B. gute Pratiken beim Projektmanagement aufführt, stellt Scrum konkrete Techniken bereit, um dies konkret zu tun. Scrum gehört zu den agilen Rahmenwerken und fußt auf agilen Werten. Scrum ist eine konkrete Umsetzung für die Punkte, die CMMI empfiehlt, für eine Organisation, die auf agilen Werten fußt.

Scrum und CMMI bringen sich gegenseitig weiter

Grundsätzlich sind agile Werte, Scrum und CMMI eine hervorragende Ergänzung zueinander. Im Disziplinanspruch von Scrum und im Professionalitätsanspruch von CMMI überschneiden sich beide. Agile Organisationen können die Gestaltung des Unternehmens neben der Projektarbeit mit agilen Werten und mit Hilfe von CMMI weiterdenken. Umgekehrt können Organisationen mit einer eher klassischen Umsetzung von CMMI durch Scrum agile und leichtgewichtige Lösungen etablieren. Lesen Sie dazu mehr in unserem Artikel "Scrum und CMMI – wie passt das zusammen?"

In diesem Artikel: Mapping von Scrum und CMMI

In diesem Artikel beschreiben wir, welche Punkte von CMMI durch Scrum konkret umgesetzt werden: wer macht es, wie wird es umgesetzt, was ist das Ergebnis, wann wird es gemacht. Der Artikel ist eine Anleitung für die Organisationen, die Scrum als eine agile Arbeitsweise bei sich nutzen und gleichzeitig die Orientierung von CMMI schätzen.

Anforderungsmanagement (REQM) in Scrum

Scrum bietet ein effizientes und leichtgewichtiges ("lean") Anforderungsmanagement, das alles umsetzt, was man von einem guten Anforderungsmanagement erwartet. Auch wenn es nach weniger aussieht, als man es aus klassischen Projekten gewöhnt ist: der Check gegenüber CMMI zeigt, dass alle Praktiken des Anforderungsmanagements (REQM) durch Scrum vollständig umgesetzt sind.


CMMI "Was"	Scrum "Wie"	Umsetzungsgrad
REQM.SP 1.1 Obtain an understanding of requirements	The Product Owner writes and prioritizes the Product Backlog items (user stories) according to their business value continuously. The Product Owner and Team discuss Product Vision, Sprint Goal, Product Backlog items (user stories) and their prioritization in Release Planning and Sprint Planning meetings. The Product Owner and the Team agree on the Definition of Done in Release Planning and Sprint Planning. The Definition of Done contains non-functional requirements, quality requirements, organizational constraints and functional requirements that apply to every Product Backlog item.	Fully
REQM.SP 1.2 Obtain Commitment to Requirement Changes	The Team agrees to the Selected Product Backlog (which it can commit to deliver in the next Sprint, based on the Definition of Done) in the Sprint Planning meeting.	Fully
REQM.SP 1.3 Manage requirements changes	The Product Owner adds, reprioritizes or drops items (user stories) to the Product Backlog continuously. The Product Owner can also change the Definition of Done. The Team suggests Product Backlog items (user stories) to the Product Owner (or changes to the Definition of Done) continuously. The Product Owner agrees to neither change the Selected Product Backlog nor the Definition of Done during the Sprint. Product Owner and the Team discuss the changes to the Product Backlog (or the Definition of Done) in the Sprint Planning meeting.	Fully
REQM.SP 1.4 Maintain bidirectional traceability	The Product Owner maintains the Product Backlog items in a hierarchy of epics and user stories (vertical traceability). The Team maps each task to a Product Backlog item (horizontal traceability).	Fully
REQM.SP 1.5 Identify inconsistencies between project work and requirements	The Team presents for each Selected Product Backlog item (user story) whether the Potentially Shippable Product Increment meets the requirements according to the Definition of Done. The Product Owner reviews each item and accepts it. This is performed in the Sprint Review. The Team works only on tasks that are in the Sprint Backlog and that map to a Selected Product Backlog item during the Sprint. The Team monitors the fulfillment of the Selected Product Backlog items by monitoring the remaining effort shown in the Sprint Burndown Chart during the Sprint.	Fully

Projektplanung (PP) in Scrum

Scrum setzt die meisten bewährten Praktiken der Projektplanung um. Scrum setzt dabei an vielen Stellen auf verblüffend einfache Lösungen, bei denen die Einfachheit durch intelligente Lösungen ensteht, und nicht etwa durch Weglassen.

Ein Beispiel dafür ist die Work Breakdown Structure (Projektstrukturplan): hier nutzt Scrum die Anforderungen als die oberste Ebene der Planung. Dadurch löst Scrum auf elegante Weise die klassische Herausforderung, nämlich Anforderungen und Projektplan zu synchronisieren. Dies vereinfacht außerdem die Verfolgung der Pläne, weil es schlichtweg weniger zu verfolgen gibt. Darüber hinaus helfen einfache Lösungen, die Planungsdisziplin im Team zu wahren, weil es weniger Planungsaufwand gibt.

Der Vergleich mit CMMI zeigt zwei Punkte auf, die durch Scrum nicht direkt adressiert werden. Dies sind Risiken und die Verwaltung der Daten. Wenn beides wichtig ist (was es vermutlich ist), dann sollte ein Team das Scrum Framework um zwei Lösungen ergänzen, die Risiken und die Handhabung der Daten im Sinne der agilen Werte ergänzen. Die folgende Aufstellung macht dazu einen konkreten Vorschlag.

Es gibt einige Punkte, bei denen Scrum keine "vollumfängliche" Lösung bietet. So gibt es z.B. einen Projektplan, aber kein explizites Budget. Hier ist Scrum in vielen Fällen sicherlich völlig ausreichend, allerdings gibt es ebenso Fälle, in denen der Product Owner auch die anderen Ergebnisse wie z.B. das Budget oder die Planung anderer Ressourcen (außer Personen) benötigen wird. In diesem Fall müssen Team, Product Owner und ScrumMaster eine zum Scrum Framework passende Umsetzung finden.

Schätzung in Scrum


CMMI "Was"	Scrum "Wie"	Erfüllungsgrad
PP.SP 1.1 Estimate the Scope of the Project	The Product Owner maintains the Product Backlog with User Stories continuously.	Fully
PP.SP 1.2 Establish Estimates of Work Product and Task Attributes	The Team estimates Story Points (relative effort) for every user story in Sprint Planning or in Release Planning.	Fully
PP.SP 1.3 Define Project Lifecycle	In Scrum the phases are a regular sequence of Sprints. The Team and the Product Owner plan the amount of Sprints needed and the releases of the product during Release Planning.	Fully
PP.SP 1.4 Determine Estimates of Effort and Cost	The Team calculates the Team’s effort for each User Story based on the current velocity, multiplied by the Story Points (relative effort) in Sprint Planning I or in Release Planning. The Scrum framework does not explicitly address calculation of costs.	Largely

Projektplan in Scrum


CMMI "Was"	Scrum "Wie"	Erfüllungsgrad
PP.SP 2.1 Establish and maintain the project’s budget and schedule.	The Team establishes a short-term schedule in the Sprint Backlog, which contains the Selected Product Backlog and the Tasks, during Sprint Planning II. The Product Owner establishes and maintains a long-term schedule in the Release Plan. The Team maintains the Sprint Backlog daily during the Sprint. The Scrum framework does not explicitly address a budget.	Largely
PP.SP 2.2 Identify Project Risks	The Scrum framework does not explicitly address risks. A possible solution within the framework could be: Team and Product Owner identify chances and risks in the Sprint Retrospective. In the starfish diagram, the section “what was good” is extended by “what chances do we have”, and the section “what was bad” is extended by “what risks do we have”. The “do more, do less, try out” section will now also contain risk mitigation actions. Additionally, the understanding of impediments could be extended by a little foresight. In this case the Team answers during Daily Scrum meeting the question “What impediments do I have or see at the horizon?”	Not Addressed -> Fully
PP.SP 2.3 Plan for Data Management	The Scrum framework does not explicitly address data management. A possible solution within the framework could be: Product Owner and Team agree on the data and configuration management requirements in the Definition of Done during Sprint Planning I.	Not Addressed -> Fully
PP.SP 2.4 Plan for Project Resources	The Team decides how much User Stories can be delivered with given resources and skills in the next Sprint in Sprint Planning I. Team members decide by themselves which tasks they pick from the Sprint Backlog every day during the Sprint. In Scrum, resources with their skills, and the time, are given and the amount of work is adapted to that. The Scrum framework does not explicitly address resources other than people.	Largely
PP.SP 2.5 Plan for Needed Knowledge and Skills	In Scrum, resources with their skills, and the time, are given and the amount of work is adapted to that. Interdisciplinary teams are used so that team members can learn from each other while they do the work.	Fully
PP.SP 2.6 Plan Stakeholder Involvement	In Scrum, there is general definition of three stakeholder roles and their involvement in the project (Team, Scrum Master, Product Owner). During any meeting (except: Sprint Retrospective) anyone (chickens) can participate and listen, but not talk. The Team decides on stakeholder involvement tasks during Sprint Planning II.	Largely
PP.SP 2.7 Establish the Project Plan	Team and Product Owner keep Sprint Backlog and Product Backlog synchronized through the Selected Product Backlog. Any task in the Sprint Backlog belongs to an item of the Selected Product Backlog, which has been taken from the Product Backlog during Sprint Planning I. No other planning documents are maintained.	Fully

Commitment in Scrum


CMMI "Was"	Scrum "Wie"	Umsetzungsgrad
PP.SP 3.1 Review Plans That Affect the Project	In case of one single team, Product Owner and Team maintain all requirements in one single Product Backlog and one single Sprint Backlog. In a Scrum of Scrum environment, the Product Owner can maintain several Product Backlogs and Teams. In this case the Product Owner ensures the integration of the Product Backlogs such that the teams can work with maximum independence.	Fully
PP.SP 3.2 Reconcile Work and Resource Levels	The Team balances work and resources by only committing to those items of the Product Backlog, which it can deliver during the next Sprint. The Scrum framework does not explicitly address resources other than people.	Largely
PP.SP 3.3 Obtain Plan Commitment	The Team commits to deliver the User Stories of the Selected Product Backlog in Sprint Planning I. The Product Owner commits to no change of the Selected Product Backlog during the Sprint.	Fully

Projektverfolgung und -steuerung (PMC) in Scrum

Die Projektverfolgung ist eine der klaren Stärken von Scrum. Es ist ein Grundprinzip von Scrum, den Plan zeitnah und diszipliniert zu verfolgen und daraus Konsequenzen zu ziehen (inspect and adapt). Die Verfolgung vom Sprint Backlog und Impediment Backlog erfolgt im Daily Scrum. Dies wird zusätzlich unterstützt durch das Sprint Burndown Chart. Die Ergebnisse des Sprints insgesamt werden im Sprint Review, und die Arbeitsweise wird in der Sprint Retrospektive verfolgt. Impediments (Arbeitshindernisse) werden durch den Scrum Master im Impediment Backlog verfolgt. Für alle Punkt setzt Scrum damit genau den "Plan-Do-Check-Act" Cycle konsequent um, den CMMI als gute Praktik vorschlägt.

Allerdings adressiert Scrum Risiken und Datenmanagement nicht explizit (siehe oben) – daher werden sie logischerweise nicht erfaßt. Beides fügt sich aber mit kleinen Änderungen nahtlos in Scrum ein – und in diesem Fall greifen auch hier Daily Scrum, Sprint Review und Sprint Retrospektive voll.

Verfolgung des Plans


CMMI "Was"	Scrum "Wie"	Umsetzungsgrad
PMC.SP 1.1 Monitor Project Planning Parameters	The Team maintains the Sprint Backlog and the Sprint Burndown daily. The Team maintains the Release Burndown in the Sprint Review.	Fully
PMC.SP 1.2 Monitor Commitments	The Team monitors the commitment of the team members during Daily Standup.	Fully
PMC.SP 1.3 Monitor Project Risks	The Scrum framework does not explicitly address risks. However, the Team could extend the understanding of impediments to also include possible future problems. Also, the retrospective could be extended to include risks (see PP.SP 2.2).	Not Addressed -> Fully
PMC.SP 1.4 Monitor Data Management	The Scrum framework does not explicitly address data management. If Product Owner and Team include data management requirements in the Definition of Done, the tasks addressing data management are part of the Sprint Backlog and monitored with all other tasks.	Not Addressed -> Fully
PMC.SP 1.5 Monitor Stakeholder Involvement	The Team monitors the commitment of the team members during Daily Standup. If specific tasks for stakeholder involvement are needed, they are part of the Sprint Backlog and the Team tracks them with all other tasks.	Fully
PMC.SP 1.6 Conduct Progress Reviews	The Team monitors the progress of the work during Daily Standup.	Fully
PMC.SP 1.7 Conduct Milestone Reviews	The Team and the Product Owner review the Potentially Shippable Product during the Sprint Review. The Team and the Product Owner review the way of work during the Sprint Retrospective.	Fully

Verfolgung offener Punkte


CMMI "Was"	Scrum "Wie"	Umsetzungsgrad
PMC.SP 2.1 Analyze Issues	Team, Product Owner and ScrumMaster identify issues (in Scrum they are called “impediments”) during Daily Standup, Sprint Review and Sprint Retrospective.	Fully
PMC.SP 2.2 Take corrective action	The ScrumMaster maintains the Impediments in the Impediment Backlog. The ScrumMaster takes the necessary actions to remove the impediments throughout the Sprint.	Fully
SP 2.3 Manage corrective actions to closure.	The ScrumMaster tracks the Impediments in the Impediment Backlog.	Fully

Warum Scrum und CMMI?

Wie dieser Artikel zeigt, stellt Scrum einen guten und leichtgewichtigen Rahmen bereit, um alle Punkte für ein gutes Projektmanagement voll und ganz umzusetzen. Der besondere Charme der Leichtgewictigkeit liegt in den intelligenten Lösungen, und in der Machbarbeit bei der Planung wie der Verfolgung. Der Nutzung von CMMI zur "Hinterfragung" von Scrum zeigt aber auch den Nutzen von CMMI auf: es hat uns auf zwei Punkte gestoßen, die wir so vielleicht nicht gesehen hätten. So aber haben wir z.B. Risiken ohne Mehraufwand in Scrum integriert - und das ist vermutlich ganz gut so.

Zu den Autoren

David Croome und Malte Foegen nutzen seit Jahren Scrum für das Management von Projekten. Ebenso kennen Sie CMMI aus der Praxis. Malte Foegen ist zudem SEI Certified Lead Appraiser. David Croome und Malte Foegen haben Scrum wie CMMI lieben gelernt, da sie gesehen haben, welchen Nutzen es Organisationen bringen kann, wenn es richtig angewendet wird. Mit diesem Artikel wollen sie Menschen, die agile Lösungen in einem CMMI Umfeld nutzen wollen, eine Anleitung geben, wie gut dies zusammen passt. Es zeigt aber auch, dass Scrum konsequent gelebt werden muss, damit Scrum effektiv funktioniert.