Release-, Change- und Configuration-Management in (agilen) Projekten?

Auf der Suche nach Prozessen, die grundlegend sind und in ähnlicher Form in mehreren IT-Frameworks oder Vorgehensmodellen auftauchen, stößt man unweigerlich auch auf das Dreieck aus

Release-Management [RLM] <> Change Management [CHM] <> (SW-) Configuration Management [(S)CFM]

Es gibt wohl keinen Zweifel daran, dass diese Prozesse im ITSM von grundlegender Bedeutung als Kontrollprozesse sind. Sie sind ferner engstens miteinander verflochten. Das gilt für ihre Beschreibung in ITIL V3 genauso wie für die Behandlung im Rahmen der ISO/IEC 20000 Series.

Nun ist mir im Rahmen von Beratungsjobs immer wieder die Aussage von Projekt-Managern begegnet, dass sie diese Prozesse ja auch aus dem Kontext des Projektmanagements gut kennen würden. Leser des letzten Artikels werden vermuten, dass ich dem nur eingeschränkt zustimmen würde. Hierfür gibt es drei Gründe:

  1. Im Projektmanagement bewegen wir uns im Normalfall auf einer taktischen Ebene der IT-Steuerung. RLM, CHM und CFM haben in IT-Projekten von vornherein einen begrenzten zeitlichen Horizont. Im ITSM spielen jedoch auch strategische Aspekte eine Rolle, die den gesamten Lifecycle von IT-Services betreffen. Getrieben werden die langfristigen, strategischen Anforderungen dabei u.a. vom Business und dem Produkt-Management. Das gilt im Besonderen für das Release-Management.
  2. Die drei genannten Prozesse sind im ITSM-Kontext dadurch gekennzeichnet, dass sie auch mit eng mit Prozessen anderer Prozessgruppen verbunden sind – etwa mit den Resolution-Prozessen. Mindestens im Detail ergeben sich dadurch Unterschiede gegenüber korrespondierenden Prozessen im Umfeld von Projekten. Die Ausprägung der Prozesse und zugehöriger Rollen wird im Detail daher für das Projektgeschäft anders ausfallen als für ITSM-Bedarfe.
  3. In agilen Steuerungsverfahren wie SCRUM tauchen die Begriffe Release-, Change- und Konfiguration-Management als explizit benannte Sub-Prozesse gar nicht auf.

Den ersten Punkt werde ich schon im nächsten kommenden Beitrag wieder aufgreifen. Bzgl. des zweiten Punktes sollten wir nicht zu kleinlich sein; gute Projektmanager werden gerade in längerfristigen SW-Projekten ein ausgefeiltes Change Management und auch Configuration Management betreiben. Auf die Gründe komme ich gleich zu sprechen. Der dritte Punkt ist schon ein wenig heikler.

Alle diese Punkte werden uns in diesem Blog immer wieder beschäftigen. Dennoch ist an dem Gedanken, dass größere IT- und SW_Projekte ein begrenztes RLM, CHM, CFM betreiben, natürlich etwas dran. Ich möchte nachfolgend daher einen ersten groben Blick auf die Existenz und Ausprägung der genannten Prozesse in klassisch und agil gesteuerten Projekten werfen.

Change Management in klassisch gesteuerten Projekten

Ich denke, hier können wir getrost einen Haken setzen: Jeder klassische Projekt-Manager, der etwas auf sich hält, wird in seinem Projekt ein „Change Management“ aufsetzen. Dies dient dazu, zusammen mit dem Steering Committee die Kontrolle über die Erweiterung des Arbeitsspektrums, erforderliche Ressourcen, Zeit etc. zu behalten. Stichwort ist hier das klassische PM-Dreieck aus Zeit, Ressourcen/Kosten und Qualität des Sachziels. Requests for Change [RfCs] sind auch in Projekten über Tools zu erfassen und hinsichtlich Bewertung, Genehmigung wie Umsetzung zu verfolgen. Die Toolpalette hierfür ist der im ITSM zumindest bzgl. der angebotenen Funktionalität sehr ähnlich.

Change Management im Kontext von SCRUM

Hmmm …, hier sieht es schon ein wenig schwieriger aus. Ein spezieller Sub-Prozess Change Management findet sich weder im agilen Manifest noch in den grundlegenden Schriften zu SCRUM. Dennoch gilt: SCRUM dreht sich insgesamt auf verschiedenen Ebenen um nichts anderes als die Bewältigung von „Change“-Anforderungen:

Gewünschte Anforderungen an neue oder modifizierte Produkt-Eigenschaften werden unter Kontrolle des Product Owners im Product Backlog erfasst und priorisiert. In Form von „User Stories“ werden die Anforderungen inhaltlich aufbereitet und systematisch in Richtung Umsetzungsreife gebracht. Das SCRUM-Team entscheidet schließlich, ob und wann die Anforderungen in einem Sprint umgesetzt werden. Hinzu kommen eine paar Besonderheiten, die aus dem expliziten Schutz des Sprint Scopes resultieren.

Das bedeutet Kontrolle über Änderungsanforderungen zu Produkt-Features auf verschiedenen Ebenen und über verschiedene Rollen hinweg – die ineinander greifenden Verfahren des SCRUM-Frameworks stellen im Endeffekt aber sicher ein ausgefeiltes Management von Changes dar!

Release-Management in klassisch gesteuerten Projekten

Wie sieht es mit dem Release-Management in Projekten aus? Jeder, der einmal klassisches Projektmanagement in der SW-Entwicklung betrieben hat, weiß, dass man gut daran tut, auf dem Weg zu komplexen Systemen Zwischenstufen in Form von Prototypen oder Zwischenprodukten einzuziehen. Das ist in inkrementell oder evolutionär arbeitenden Vorgehensmodellen sowieso Standard; man kann hier durchaus von der Verwaltung von Sub-Releases auf dem über Inkremente unterteilten Weg zu einem zu liefernden Haupt-Release sprechen. Dynamische und anpassbare Vorgehensmodelle wie das V-Modell XT sind damit kompatibel.

Aber auch in Vorgehensmodellen, die sich am alten V-Modell orientieren (müssen), kann man wenigstens in der Entwicklungsphase Meilensteine zu abnehmbaren Prototypen definieren, die bestimmte Funktionskreise abdecken. Dadurch lässt sich ein kontinuierliches Qualitätsmanagement betreiben, und die bösen Überraschungen kulminieren nicht in einem QA-Gau am Ende der Entwicklung.

Fazit: In gut geführten IT-Projekten sollte ein Management von Zwischen-Releases zu bestimmten Meilensteinen – soweit technisch und fachlich irgend möglich – zum guten Arbeitsrepertoire zählen. Man wird es entsprechend häufig antreffen.

Release-Management im Kontext von SCRUM

Wieder ein nicht ganz trivialer Punkt, über den schon viel geschrieben wurde. Ein Release ist kein als solches bezeichnetes Artefakt des SCRUM Frameworks. Dennoch taucht der Begriff „Release“ als Substantiv und Verb an einigen wenigen Stellen des „Scrum Guide“ (TM) von Jeff Sutherland und Ken Schwalbe aus dem Jahre 2016 auf:

Z.B. bei der Erläuterung von Sprint Reviews als „marketplace for the next anticipated release of the product„. Bei der Erläuterung des Product Backlogs: „The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.“ Im Zusammenhang mit dem Begriff Increment: „It must be in useable condition regardless of whether the Product Owner decides to actually release it.“ In ähnlicher Weise schließlich auch bei der Erläuterung „Definition of Done“.

Meine Haltung zu dem Thema ist die, die u.a. etwa von K.S. Rubin in seinem Buch „Essential SCRUM“ (mitp-Verlag, 2014) vertreten wird:

Der Release-Begriff wird im Sinne des SCRUM-Guides eng an ein Produkt geknüpft. Product Releases können einerseits einerseits über definierte Schnitte im Product Backlog definiert werden. Andererseits muss jedes Sprint-Ergebnis selbst zumindest release-fähig sein – egal, ob der Product Owner [PO] es nun faktisch für einen bestimmten Anwenderkreis freigibt oder nicht.

Ähnlich wie beim Change Management gilt also: Das SCRUM Framework entfaltet sich rund um Releases. Die Bündelung von Product Backlog Items zu kundenfähigen, strategisch wichtigen Releases ist hierbei ein wichtiger Schlüssel zum Verständnis. In hoch-dynamischen Fällen führt ggf. die Increment-Umsetzung in jedem Sprint zu einem neuen publikationsfähigen „Release“ eines Produkts. Release-Management ist also ein inhärenter Bestandteil des SCRUM-Frameworks, auch wenn es nicht so bezeichnet wird.

Configuration Management in klassisch gesteuerten Projekten

Dass System- oder SW-Releases, die in einem Projekt erzeugt werden, auf verschiedenen Ebenen dokumentiert, versioniert und paketiert werden sollten, ist ein Gebot der Vernunft. Typische Dokumentationen, die in SW-Projekte zu erstellen sind, betreffen etwa fachliche Konzeptionen, User Handbücher, technische Spezifikationen, Installationshandbücher, Adnministrationshandbücher, etc.. Auch hier gilt wieder, dass ein inkrementelles Vorgehensmodell, welches definierte Zwischenergebnisse zeitigt, diese Zwischenergebnisse mit der notwendigen Dokumentation und Versionierung von Artefakten (u.a. Installationsmedien) versehen wird. Ferner wird man eine Liste bekannter Fehler und zugehöriger Workarounds führen.

Die entscheidenden Stichworte, die ein Configuration Management für Zwischen- oder End-Produkte in IT-Projekten nach sich ziehen, sind: Nachvollziehbarkeit und Nachhaltigkeit.

Dabei ist nicht zu vergessen, dass die im Projekt erzeugten CFM-Artefakte (CIs; Configuration Items) am Ende eines Projektes an den operativen Betrieb bzw. ITSM-Verantwortliche übergeben werden müssen. Eine Known Error Database ist dort z.B. essentielle Grundlage des Incident- und des Problem-Managements. Ebenso stellt eine paketierte „Definitive Media Library“ die Wiederherstellung von Installationen sicher. Ein Unternehmen, dass eine System- oder SW-Entwicklung beauftragt, wird daher im Interesse nachfolgender ITSM-Prozesse ein gerüttelt Maß an (S)CFM während des oder der IT-Projekte anfordern.

Configuration Management in SCRUM?

Hier wird es wieder unangenehm: Weder das agile Manifest, noch der SCRUM Guide, noch viele Bücher zu SCRUM erwähnen ein Configuration Management explizit. In der Praxis kommt es aber als Brückenschlag zwischen schneller und nachhaltiger SW-Entwicklung aber sehr wohl zum Tragen. Nachhaltigkeit und Nachvollziehbarkeit werden im agilen Prozess nicht aufgegeben und können u.a. Gegenstand einer „Definition of Done“ werden.

Dass man in agilen Verfahren ggf. die Verantwortung für ein nachhaltiges (System- und SW-) Configuration Management beim gesamten Team sieht und Formalismen zugunsten eines pragmatischen Wissenstransfers zwischen Sprints abgebaut werden, ändert daran nichts. SCRUM produziert Ergebnisse, die allesamt validiert werden müssen, mit einer ggf. hohen Taktung (begrenzte Time-Boxes). Die relativ kontinuierliche Integration, Implementierung und Qualitätssicherung erfordert dabei einige Klimmzüge. Probate Techniken wie Testautomatisierung, Continuous Integration and Deployment z.B. in der SW-Entwicklung setzen funktionierende CFM-Verfahren [SCM; Software Configuration Management] voraus – zumindest auf der technischen Ebene.

Manche Autoren kommen deshalb gar zum Schluss, dass schlanke und automatisierte CFM-Methoden agile Projektmethodik erst ermöglichen. Siehe hierzu auch einige Links und einen Buchtipp am Ende diese Beitrags.

Fazit

Nimmt man die obigen Erläuterungen ernst, so kann man sagen, dass klassisch wie agil gesteuerte IT- oder SW-Projekte nur selten keine Form von Change-, Release- und Configuration Management zur Begleitung der notwendigen Entwicklungsarbeiten aufweisen werden. Steuerungs-, Kontroll- und Nachhaltigkeits-Anforderungen zwingen dazu, adäquate Prozesse/Verfahren in Begleitung der notwendigen Entwicklungsarbeiten zu etablieren. Dass ein agiles Framework wie SCRUM hierbei pragmatische statt formalistischer Wege wählt, ändert daran nichts. Ebensowenig wie der starke und kontinuierliche Produktbezug, der SCRUM auszeichnet.

Wir finden also Äquivalente zu den drei grundlegenden ITSM-Prozessen – Release-, Change- und Configuration-Management – im Prinzip auch auf der Ebene von Projekten vor – selbst, wenn zu konstatieren ist, dass Zielsetzung und Ausprägung dort oft anders als im ITSM ausfallen. Sieht man von den prozessualen Eigentümlichkeiten unter SCRUM einmal ab, so führt das zur nebenstehenden naiven Abbildung. Wir werden u.a. die starke Produktausrichtung von SCRUM aber zum Anlass nehmen, diese Grafik im nächsten Beitrag wieder in Frage zu stellen.

Links

https://www.cmcrossroads.com/article/agile-change-management-first-principles-best-practices
How is Change management embedded into the Scrum Framework?

https://www.cmcrossroads.com/article/applying-configuration-management-agile-teams
Doktorarbeit „SCM in Scrum Projects“ von AndreasBergström, 2008, Department of Computer Science Lund Institute of Technology Sweden
http://www.methodsandtools.com/archive/archive.php?id=62
Config management: Enemy of agile approach or the reason it WORKS?

Buchtipp: „Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed“, Mario E. Moreira, Wiley verlag, 2009

Schreibe einen Kommentar

Dieser Blog verwendet Cookies. Bei weiterer Nutzung gehen wir von Ihrem Einverständnis aus. Optionen/Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen