Blue Scrum Prozessmodell

Transcription

Damit Software-Entwicklung richtig Spaß macht!
Blue Scrum
Das Prozessmodell
Dipl.-Inform. (FH) Rainer Eschen
V 0.1 / 30.09.2013
Wir brauchen Ihre Ideen für das nächste
Update dieses Buchs. Diskutieren Sie mit unter
blog.rainwebs.net/blue-scrum-prozessmodell
Rainer Eschen
blog.rainwebs.net
google.com/profiles/rainwebs
twitter.com/rainwebs
Rainer arbeitet als agiler Coach im IT-Projekt-Management. Ein Schwerpunkt seiner
Tätigkeit ist die Entwicklung eines vollständig auf agilen Grundsätzen aufbauenden
Projekt-Management-Ansatzes, in dessen Zentrum das Scrum Framework steht. Er
greift hierbei auf jene Teile der klassischen DIN 69901-2 bzw. IPMA Competence
Baseline 3.0 zurück, die es erlauben ein vollständiges Projekt-Management nach
modernen Gesichtspunkten zu beschreiben. Seine bisherigen Erkenntnisse hat er in
den Ausarbeitungen zur Blue Scrum Buch Reihe zusammengefasst.
Rainer ist Diplom-Informatiker (FH), zertifizierter Professional Scrum Master I
(scrum.org), zertifizierter Projektmanagement-Fachmann (GPM, IPMA Level D) und
Mitbegründer von openPM. Seit Mitte der 1990er Jahre hat er im Wechsel in
folgenden Rollen gearbeitet: Unternehmensberater, Software-Entwickler, SoftwareArchitekt, Teamleiter, Systems Engineer, Java-Architekt, Projekt-Manager, Scrum
Master und Agiler Coach. Seit 2000 arbeitet er im JEE-Umfeld, u.a. war er drei Jahre
bei Sun Microsystems, Deutschland, tätig.
Rainer ist auch Autor des Buchs „ICEfaces 1.8: Next Generation Enterprise Web
Development“, Packt Publishing, 2009.
Copyright © 2013 by Rainer Eschen. Alle Rechte vorbehalten.
Dieses Dokument darf im kommerziellen Umfeld genutzt werden. Eine Weitergabe
oder ein zur Verfügung stellen jeglicher Art ist nicht erlaubt. Ein persönliches
Exemplar kann zur Nutzung jederzeit unter folgender URL heruntergeladen werden:
blog.rainwebs.net/blue-scrum-prozessmodell
Inhaltsverzeichnis
Die Blue Scrum Buchreihe.....................................................................................5
Über dieses Buch ...................................................................................................8
Das Blue Scrum Prozessmodell ..............................................................................11
Das agile Wertesystem .....................................................................................11
Das Agile Manifests ...............................................................................12
Prinzipien des Lean Software Developments..........................................13
Scrum Grundwerte................................................................................16
Zentrale Werte des Extreme Programmings ...........................................19
Die agilen Werkzeuge......................................................................................20
Scrum Framework .................................................................................21
Extreme Programming Engineering Practices.........................................21
Feature Driven Development.................................................................21
Kanban für Software-Entwicklung.........................................................22
Das agile Projekt-Management........................................................................22
DIN 69901-2........................................................................................23
IPMA Compentence Baseline 3.0..........................................................23
Zusammenfassung...........................................................................................24
Der Blue Scrum Projekt-Rahmen ..........................................................................25
DIN 69901-2..................................................................................................25
Agiles Projekt-Management.............................................................................28
Agile Projekt-Management-Prozess-Untergruppen ..........................................28
Agile Projekt-Management-Prozesse ................................................................31
Agile Projekt-Management-Phasen..................................................................33
IPMA Competence Baseline 3.0......................................................................36
Mapping zwischen DIN 69901-2 und ICB 3.0...............................................39
Agile Elemente der PM-technischen Kompetenz .............................................41
Das Blue Scrum Vorgehensmodell .........................................................................43
Das Feature als fachliche Erweiterung des Systems...........................................43
Anforderungsbeschreibungen.................................................................43
Implementierung...................................................................................43
Integrationstest ......................................................................................44
Von der Anforderung zur Implementierung...........................................44
Das Scrum Framework als Entwicklungsrahmen .............................................44
Meetings................................................................................................46
Blue Scrum Das Prozessmodell
iii
Rollen....................................................................................................46
Artefakte................................................................................................47
Customer...............................................................................................47
User.......................................................................................................47
Management..........................................................................................47
Agiler Projekt-Manager..........................................................................48
Agiler Architekt .....................................................................................49
Agiler Test-Manager...............................................................................49
Agiler Build-Manager ............................................................................49
Chief Product Owner ............................................................................49
Chief Scrum Master...............................................................................50
Herausforderungen................................................................................50
Die XP Engineering Practices für die konkrete Implementierung ....................51
Hauptpraktiken.....................................................................................51
Begleitpraktiken ....................................................................................54
Software Kanban für die nachgelagerte Wartung .............................................57
Literaturverzeichnis ...............................................................................................58
Abkürzungsverzeichnis...........................................................................................61
iv
Die Blue Scrum Buchreihe
Als ich am 11.11.2011 bei Stefan Hagen im PM-Blog meine erste öffentliche Anfrage
zur Integration von IPMA und Scrum stellte [Eschen 2011], hatte ich noch keine
Vorstellung davon, was daraus einmal werden könnte. Nach einer ganzen Reihe - teils
kontroverser - Diskussionen auf openPM und mehrjährigen Gehversuchen in
größerem Projekt-Kontext, liegt nun die Blaupause für einen standardisierten Hybrid
aus agilen und klassischen Projekt-Management-Ansätzen für die SoftwareEntwicklung vor: Die Blue Scrum Buchreihe.
Blue Scrum definiert ein auf agilen Grundsätzen aufsetzendes Projekt-Management
für Software-Entwicklungs-Projekte ab drei Scrum Teams. Im Mittelpunkt der
Definition steht das Scrum Framework. Dieses wird zum Einen ergänzt um agile
Ansätze, wie etwa die XP Engineering Practices, und zum Anderen durch den
klassischen Projekt-Management-Standard International Project Management
Association (IPMA) Competence Baseline (ICB 3.0), der es erlaubt eine moderne
Variante von Projekt-Management auf Basis agiler Grundsätze zu definieren.
Die Ausarbeitungen dieser Buchreihe sind als Work-in-Progress zu verstehen. Sie
versuchen Ansätze aus verschiedenen agilen bzw. klassischen Projekt-ManagementIdeen zu einem praxisnahen Modell zu vereinen, in das kontinuierlich Erfahrungen
aus realen Projekten eingearbeitet werden. Die Vision hierbei ist, ein vollständiges
agiles Projekt-Management für die Software-Entwicklung zu definieren. Dies
bedeutet bisherige agile Ansätze im Sinne eines umfassenden Projekt-Managements
zu vervollständigen bzw. klassische Ansätze auf das Fundament eines agilen Mindsets
zu stellen [Raitner 2013].
Der in dieser Buchreihe vorgeschlagene Ansatz für ein agiles Projektmanagement
kann als Blaupause für Ihre zukünftigen Projekte dienen. Das Blue(print) in Blue
Scrum soll diesen Umstand zum Ausdruck bringen. Die Inhalte der Blue Scrum
Buchreihe stehen zur Diskussion, damit weitere Erkenntnisse aus der (agilen) ProjektManagement-Community kontinuierlich einfließen können. Jeder ist aufgerufen sich
an dieser Diskussion zu beteiligen und seine Erfahrungen mit einzubringen.
Der goldene Kreis
Als ich das erste mal das Video von Simon Sinek über das Erfolgsmodell von Apple
gesehen habe [Sinek 2010], hatte ich eine plausible Erklärung dafür, warum Kunden
Apple Produkte kaufen, die technisch scheinbar weniger bieten als jene der
Mitbewerber. Simon‘s Modell, der goldene Kreis, sieht folgendermaßen aus:
Das Warum beschreibt die Philosophie, die hinter jedem Handeln von Apple steckt.
Das Wie definiert, wie ein Apple Produkt erstellt wird. Mit dem Warum und mit dem
Wie identifiziert sich der Kunde letztendlich. Beide bestimmen, ob der Kunde das
5
Apple Produkt (Was) tatsächlich kaufen
wird.
Diese Entscheidung ist immer emotional.
Rationale Merkmale, also der Vergleich von
Features eines Apple Produkts mit denen
eines Mitbewerbers spielen kaum eine
Rolle. Dies funktioniert bei jedem Produkt,
das Apple am Markt anbietet, auf die
immer gleiche Weise, ist also unabhängig
davon, was für ein Produkt gerade
betrachtet wird (iPod, iPhone, iPad, ...).
Warum?
Wie?
Was?
Wäre ich einer von Apple‘s Mitbewerbern,
würde ich wohl folgende Argumente des Was aufzählen um Blue Scrum anzupreisen:
• Fertig anwendbares Modell für agiles Projekt-Management
• Steigerung der Effektivität und Effizienz durch Einsatz des Modells, z.B. bei
• Mitarbeiterzufriedenheit
• Kundenzufriedenheit
• Rentabilität
• Das Beste, was gerade angeboten wird ;-)
Letztendlich würde das nur für den Feature-Vergleich mit anderen Modellen reichen.
Die anderen Modelle werden aber an der einen oder anderen Stelle mehr „Features“
bieten, also etwa mehr Lösungsmuster zu gängigen Problemstellungen haben.
Den Feature-Vergleich kann Blue Scrum nicht gewinnen, weil Blue Scrum dafür gar
nicht ausgelegt ist. Es liefert nicht zu jeder Fragestellung eine Antwort. Es bietet
vielmehr einen philosophischen Entwurf, der es erlaubt, ein Scrum Team die
Antworten selbst finden zu lassen.
Blue Scrum - Warum?
Credo: Nur Mitarbeiter die jeden Tag mit einer freudigen Erwartung zur Arbeit
kommen, die sich darauf freuen können, dass sie ihr kreatives Potential jeden Tag neu
entdecken und für die gemeinsame Vision des Teams entfalten können, sind in der
Lage durch die entstehenden Produkte Kundenerwartungen zu übertreffen. Eine
derartige Zufriedenheit der Mitarbeiter ist ein Garant für kontinuierliche
Kundenzufriedenheit und Rentabilität.
Aufforderung: Schaffen Sie ein humanes, kooperatives Arbeitsumfeld für all die
intelligenten, selbständig denkenden Erwachsenen in Ihrer Organisation und lassen
Sie sie dann in Ruhe arbeiten. Respektieren Sie ihre Einzigartigkeit, vertrauen Sie
6
ihnen, geben Sie ihnen so viele Freiräume wie nur möglich und lasse sie Sie Fehler
machen und daraus lernen.
Helfen Sie Ihren Mitarbeitern schnell und unbürokratisch, wenn sie Probleme haben,
die sie selbst nicht aus dem Weg räumen können. Freuen Sie sich auf das kreative
Potential, das sich entfalten wird, die positiven Veränderungen und die Freude, die
Mitarbeiter und Kunden empfinden werden über die geschaffenen Produkte.
Kurz um: Lassen Sie uns alle jeden Tag auf‘s Neue daran arbeiten, dass die Arbeit
mehr (Lebens-)Freude erzeugt - bei Kollegen wie bei Kunden.
Blue Scrum - Wie?
Wesentlicher Aspekt bei der Erfüllung des Blue Scrum Credos ist das Zurückgreifen
auf das erprobte Wertesystem der agilen Community, allen voran die esen des
Agilen Manifests. Aufsetzend auf diesem Wertesystem definiert Blue Scrum einen
vollständigen Projektrahmen. Blue Scrum ist als Work-in-Progress selbst einer
kontinuierlichen Verbesserung durch die (agile) Projekt-Management-Community
unterworfen (frei nach dem Motto: „Eat your own dog food“).
Sind Sie dabei?
Wenn Sie selbst schon darüber nachgedacht haben, wie Ihre eigene und die Arbeit
Ihrer Kollegen (mehr) Freude erzeugen könnte, dann sollten Sie die Blue Scrum
Buchreihe genauer unter die Lupe nehmen und so bald wie möglich an deren
Weiterentwicklung mit diskutieren. Nähere Details hierzu finden Sie unter
blog.rainwebs.net/blue-scrum.
Rainer Eschen (rainwebs), September 2013
7
Über dieses Buch
Wie führt man größere agile Projekte durch? Dies ist keine leicht zu beantwortende
Frage. Die agile Community gibt hierzu nämlich noch keine umfassende Antwort. Es
gibt einige vielversprechende Ansätze, deren Anpassung an die eigene Projektsituation
aber längst nicht so einfach ausfällt.
Mit dem Blue Scrum Prozessmodell versuche ich der Diskussion einen weiteren
Anstoß zu geben. Hervorzuheben bei Blue Scrum ist die Herangehensweise, mit der
ich es entwickelt habe. Da meine Wurzeln im agilen Projektumfeld zu finden sind
und ich mich erst später als Projekt-Manager im klassischen Projekt-Management
bewegt habe, hat Blue Scrum primär agile Wurzeln.
Die meisten mir bekannten Vorschläge aus der Projekt-Management-Community
haben einen klassischen Focus. Dieser Ansatz steigert aber die Effizienz lediglich um
wenige Prozent. Wer die erwartbaren Effizienzsteigerungen agiler Ansätze erreichen
will, kommt nicht um einen disruptiven Ansatz herum.
Das Blue Scrum Prozessmodell ist disruptiv
Henry Ford hat es einmal sinngemäß so formuliert:
Hätte ich meine potentiellen Kunden gefragt, was sie gerne als
Nächstes kaufen würden, so hätten sie gesagt: schnellere Pferde.
Im klassischen Projekt-Management möchte man analog hierzu ein präziseres
Controlling, um bei Abweichungen schneller Maßnahmen einleiten zu können. Man
glaubt, trotz der weiterhin unsicheren Basis, über noch mehr Kalkulation, Risiken
und Realität besser Herr werden zu können.
Blue Scrum fordert genau die im Zitat angedeutete und notwendige disruptive
Veränderung ein. Dies allerdings nicht ohne Bewährtes aus dem klassischen ProjektManagement - im agilen Sinne - zu übernehmen, um das Scrum-Framework zu
einem vollwertigen Werkzeug für agiles Projekt-Management zu machen. Dies ist ein
wichtiger Aspekt, wenn Scrum im Großen eingesetzt wird. Das Scrum Framework
konzentriert sich lediglich auf bestimmte Aspekte des Prozesses und des Teams. Der
Projekt-Kontext kommt kaum vor (z.B. die Projekt-Initialisierung). Dafür
konzentriert sich das Scrum Framework z.B. auf eine kontinuierliche Verbesserung
oder selbstverantwortliches Handelns.
Agiles Vorgehen ist bereits eine ernstzunehmende Alternative zum klassischen
Vorgehen, auch wenn sie sich noch nicht flächendeckend durchgesetzt hat. Aber der
Einsatz agiler Projekt-Management-Ansätze wird sicherlich nur ein erster Schritt sein.
Im Sinne von Ken Schwaber, einem der Scrum Erfinder, sollte also immer auch über
8
die Frage nachgedacht werden: "Was kommt als nächstes nach Scrum?" [Schwaber
2012] Wer Blue Scrum in diesem Sinne einsetzt und im eigenen Projekt
weiterentwickelt, der wird einen echten Vorteil aus Blue Scrum ziehen.
Blue Scrum = Agile Werte + Projekt-Management
IT-Projekte werden zunehmend agil durchgeführt. Im Vergleich zu klassisch
geführten Projekten weisen diese z.B. Verbesserungen bei Kundenzufriedenheit,
Produktqualität und Produktivität der Mitarbeiter auf. Insgesamt lässt sich feststellen,
dass die agil durchgeführten Projekte drei Mal erfolgreicher sind [Schwaber 2012
(2)].
Der mittlerweile bekannteste agile Vertreter ist das Scrum Framework. Das
Framework definiert lediglich Rahmenparameter für ein agiles Vorgehen, stellt aber
selbst kein Vorgehensmodell dar. Somit wird bei Einsatz von Scrum das
Projektvorgehen individuell gestaltet und kann z.B. durch Hinzunahme von
Engineering Praktiken aus dem Extreme Programming zu einem vollständigen
Vorgehensmodell ausgebaut werden.
Dieses ist bereits gängige Praxis. Was allerdings fehlt, ist die Betrachtung eines
größeren Projektrahmens, wie er in klassischen Projekten beispielsweise bei
Großkunden vorkommt. Hierbei geht es nicht nur um die Verwaltung von mehreren
Scrum Teams und die aus Sicht der Software-Entwicklung notwendigen
Verwaltungsstrukturen, wie es etwa der Scrum of Scrums Ansatz beschreibt, sondern
vielmehr um die vollständige Abbildung eines Projekts - allerdings auf Basis agiler
Grundwerte. Man könnte auch sagen, das Agile Manifest hält Einzug in das ProjektManagement.
Einige Fragen, die das Scrum Framework völlig unbeantwortet lässt, sind z.B.
• die Projekt-Initialisierung
• die Betreuung des Kunden aus projekttechnischer Sicht, etwa im Rahmen eines
Berichtswesens für den Kunden
• die Unterstützung des eigenen Managements im Rahmen eines Controllings der
Organisation
• der Projekt-Abschluss
Der in diesem Buch vorgestellte hybride Ansatz berücksichtigt genau diesen
fehlenden Projektrahmen.
9
Inhalt
Das Buch teilt sich in folgende Kapitel auf (die nacheinander studiert werden
sollten):
• Das Blue Scrum Prozessmodell - Ein erster Überblick über die agilen Grundwerte,
die eingesetzte agilen Werkzeuge und das Prinzip eines agilen Projekt-Managements
• Der Blue Scrum Projektrahmen - Über die Nutzung der in der DIN 69901-2
definierten Projekt-Management-Prozesse und der ICB 3.0 Elemente in agilen
Umgebungen
• Das Blue Scrum Vorgehensmodell - Die Ausgestaltung der agilen SoftwareEntwicklung im Detail
10
Das Blue Scrum Prozessmodell
Blue Scrum ist ein agiles Prozessmodell für die Software-Entwicklung in
(mittel)großen Projekten (3 - 9 Scrum Teams). Basis sind agile Grundwerte, die über
die Kombination verschiedener agiler Werkzeuge im Kern eines umfassenden, agilen
Projekt-Managements verankert sind. Das Modell wirkt disruptiv auf die
Organisation und erfordert einen Mindset-Wechsel.
Das
agile
ProjektManagement
ICB
3.0
DIN
69901-2
XP
Practices
Die
agilen
Werkzeuge
FDD
Kanban
Scrum
Framework
Lean
Software
Das
agile
Wertesystem
Scrum
XP
Agiles
Manifest
Das agile Wertesystem
Entscheidend für den erfolgreichen Einsatz von Blue Scrum ist dessen Basis: das agile
Wertesystem. Bisherige hybride Ansätze im Projekt-Management haben den
klassischen Ansatz im Zentrum stehen lassen und diesen um einige agile Konzepte
ergänzt. Dieses Vorgehen bringt aber nur eine marginale Verbesserung des
Ergebnisses.
Erst wenn wir das zugrundeliegende Mindset der Beteiligten über das Prozessmodell
neu definieren, also eine disruptive Lösung etablieren, kann tatsächlich ein erkennbar
verbessertes Ergebnis entstehen. Würde dies nicht empirisch bereits belegt sein, sollte
das gar nicht erst versucht werden. Denn in dem angedachten Mindset-Wechsel
steckt gleichzeitig die größte Herausforderung: Wer die Welt derart verändern will,
muss mit nicht unbeträchtlichem Widerstand rechnen und sehr viel Durchhaltevermögen mitbringen. Wir werden uns im Buch Blue Scrum - Die Organisation noch
ausführlich mit dem dafür notwendigen Change Management auseinandersetzen.
11
Das Agile Manifests
Das Agile Manifest für Software-Entwicklung [Beck 2001] wurde von führenden
agilen Methodikern im Jahre 2001 formuliert und beschreibt die Glaubenssätze, die
allen agilen Werkzeugen gemeinsam sind:
• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als Befolgen eines Plans
Die Werte auf der rechten Seite, wie es im Manifest formuliert wird, werden
weiterhin als wichtig angesehen, die auf der linke Seite aber als wesentlich wichtiger
für den Erfolg eines Projekts eingeschätzt.
Individuen und Interaktionen
Bei diesem Grundwert geht es darum, dass die Menschen im Mittelpunkt aller
Betrachtungen stehen. Es braucht Prozesse und auch Werkzeuge, diese sind aber nicht
der Erfolgsgarant für die so wichtige Kommunikation im Projekt. Die Leute müssen
miteinander von Angesicht-zu-Angesicht reden und je nach Situation auch neu
definieren können, wie genau das passieren soll.
Diese Sicht wird nachvollziehbar, wenn man einen Projekt-Mitarbeiter nicht länger
als Ressource betrachtet, der man etwa sagen muss, wie sie arbeiten soll, woran sie
denken muss, und in welcher Art sie sich in die Organisation des Projekts
einzuordnen hat. Selbstverantwortliches Handeln auf direktem Wege, in direkter
Ansprache anderer Projekt-Mitglieder ist die effektivste Form des Informationsaustausches.
Funktionierende Software
Klassisches Projekt-Management neigt dazu übermäßig viel zu dokumentieren und
einen Großteil der sowieso schon kostbaren Zeit in etwas zu investieren, von dem der
Anwender später nichts hat. Überspitzt gesagt betrachten gerade Projekte in
Schieflage exessive Dokumentation als gutes Investment, damit man abgesichert in
das regelmäßige Finger-Pointing gehen kann. Aus Anwendersicht ist das pure
Verschwendung.
Was für Anwender zählt ist funktionsfähige Software. Wobei man hinzufügen muss:
in der erwarteten Qualität. Das Entwickler-Team sollte bei jeder Entscheidung, die
nicht direkt zur Erweiterung des potentiell-auslieferbaren Codes führt genau darauf
schauen, ob sich die investierte Zeit in Dokumentation später für den Anwender
auszahlt.
12
Zusammenarbeit mit dem Kunden
Hier geht es um einen vertrauensvollen Umgang zwischen Entwicklung und Kunde.
Die Entwicklung muss ein starkes Interesse an der Bedürfnisbefriedigung des Kunden
haben, der Kunde ein ausgeprägtes Vertrauen darin, dass die Entwicklung ihm so
helfen wird wie erwartet. Ausgeprägte Kommunikation und enge Zusammenarbeit
sind wichtige Bausteine, um ein entsprechendes Vertrauensverhältnis entstehen zu
lassen.
Beide Parteien müssen in der Lage sein in schwierigen Situationen partnerschaftlich,
vertrauensvoll, schnell und pragmatisch eine Lösung zu finden. Dann braucht es auch
keine komplizierten Verträge, die künstlich Vertrauen über Paragraphen in das
Projekt hinein definieren.
Reagieren auf Veränderung
Gerade in klassisch geführten Großprojekten wird viel Zeit in die
Anforderungsanalyse investiert, bevor die erste Zeile Code entsteht. Leider sind die
Märkte, für die entwickelt wird, so schnell geworden, dass die erstellten Dokumente
nach ihrer detaillierten Ausarbeitung nicht selten bereits in Teilen veraltet sind.
Dies wird aber meist erst klar, wenn der Anwender die Implementierung das erste mal
anschauen kann, meist im letzten Drittel der Projektlaufzeit. Dann folgt ein
aufwendiges Change Management, evtl. zu späte Änderungsversuche kurz vor der
Auslieferung, so dass die Qualität und letztendlich die Kundenzufriedenheit gefährdet
sind.
Besser wäre es, nur soweit zu planen wie tatsächlich abgeschätzt werden kann, ob man
Implementierungskapazitäten verschwenden würde. Hierzu braucht es kürzere
Iterationen, die zudem erst dann ausgeplant werden, wenn sie tatsächlich zur
Implementierung anstehen.
Prinzipien des Lean Software Developments
Für den Projektalltag gibt das Agile Manifest die Grundrichtung vor. Die Prinzipien
des Lean Software Developments [Poppendieck 2003], die, wie das Scrum
Framework, angelehnt sind an das Toyota-Produktionssystem [Ohno 2013],
konkretisieren die gewünschten Denkweisen der Projektmitglieder noch ein wenig.
Wir unterscheiden folgende Prinzipien (zusammengefasst in der Auffassung "ink
big, act small, fail fast; learn rapidly"):
• Verschwendung vermeiden
• Lernen verstärken
• So spät wie möglich entscheiden
13
• So schnell wie möglich ausliefern
• Dem Team Entscheidungsbefugnis geben
• Integrität im System verankern
• Das Ganze betrachten
Verschwendung vermeiden
Dies ist das wesentliche Grundprinzip aus dem Toyota-Produktionssystem.
Verschwendung wird vor allem dadurch vermieden, dass alle Zwischenergebnisse, bei
Scrum sind es die potentiell-auslieferbaren Sprint Ergebnisse, von hoher Qualität
sind. Der komplette Erstellungsprozess ist auf die Bedürfnisse der Anwender
ausgerichtet, wodurch nur die Funktionalität erstellt wird, die hinterher in der
Produktion auch wirklich von den Anwendern genutzt wird.
Lernen verstärken
Das Prinzip der selbstlernenden und sich ständig verbessernden Organisation nach
William Edwards Deming [Aguayo 2010] ist zentral verankert im ToyotaProduktionssystem. Wir können es im Umfeld der Software-Entwicklung ein
bisschen wie ein kontinuierliches Try-and-Error verstehen, das in einem Regelkreis
(dem Deming Kreis mit den Schritten Planen - Ausführen - Überprüfen - Verbessern)
zu einer Verbesserung von Vorgehen und Qualität führt. Man spricht hier auch von
„Inspect and Adapt“, oder bezogen auf die konkrete Auslieferung von Code von
„Deliver - Learn - Adapt“.
Hinzu kommt das bewusste Eingehen von Risiken, die zu Fehlern führen können.
Man folgt hier der Erkenntnis, dass nur aus Fehlern gelernt werden kann. Das Prinzip
„Fail early - fail fast“ erlaubt einen schnelleren Erkenntnisgewinn. Zum einen in
Bereichen, in denen Wissen erst erarbeitet werden muss, zum anderen um
herauszufinden, was der Anwender tatsächlich meint, wenn er Aussagen trifft
(beispielsweise im Rahmen von iterativer, prototypischer Implementierung von
Benutzeroberflächen).
So spät wie möglich entscheiden
Je genauer ich definieren kann, was wirklich gebraucht wird, desto besser das
Ergebnis und desto niedriger die Verschwendung. Vielfach ist aber erst sehr spät klar,
was gebraucht wird. Deshalb hat man im agilen Umfeld aufgegeben weit nach vorne
zu schauen (bei Planung, Architektur, etc.), um nicht Gefahr zu laufen Funktionalität
zu produzieren, die lediglich auf Basis von Annahmen definiert ist, die sich später als
unzureichend erweisen könnten.
14
Grundsätzlich wird erst dann mit der Implementierung begonnen, wenn sich
Entwickler-Team und Anwender im Klaren darüber sind, was geliefert werden soll.
Im Umkehrschluss bedeutet dies, das ich im zeitlichen Verlauf dafür sorgen muss,
dass ich zu Beginn der Implementierung detailliert genug im Verständnis der
benötigten Funktionalität bin, um überhaupt anfangen zu können mit der
Implementierung.
So schnell wie möglich ausliefern
Um möglichst schnell zu erkennen, ob die tatsächliche Implementierung den
Erwartungen der Anwender entspricht, hilft es, wenn diese frühzeitig einen Blick auf
den fertiggestellten Zwischenstand werfen können. Wir folgen hier dem iterativinkrementellen Vorgehen, aber mit sehr kurzen Zyklen, die potentiell auslieferbaren
Code erzeugen.
Der Anwender muss in der Lage sein, sich ein konkretes Bild von der funktionalen
Erweiterung des Systems auf Produktionsniveau zu machen. Das Entwickler-Team
bekommt so wertvolles Feedback und kann sich dann auf die Bedürfnisse des
Anwenders entsprechend (neu) ausrichten.
Dem Team Entscheidungsbefugnis geben
Die Verantwortung in jene Hände zu legen, deren Köpfe über die Details im
Vorgehen, in den Anforderungen an das Ergebnis und den Problemen bei der
Ausführung am besten Bescheid wissen, ist der Erkenntnis geschuldet, dass alle
anderen Personen im Entwicklungsumfeld nur mit „schlechteren“ Annahmen steuern
würden und damit unnötigerweise Verschwendung entstehen könnte.
Im Vergleich zum klassischen Projektmanagement wird bei Scrum deshalb auch die
Verantwortung für das Micro-Management in die Hände des Entwickler-Teams
gelegt. Die Entwickler sind nahe genug dran, um die beste Entscheidung über
Machbarkeit und Umsetzungsweg zu treffen.
Integrität im System verankern
Die größte Herausforderung für die klassische Software-Entwicklung ist die
Integration separat voneinander entwickelter Teile eines Systems. Selbst vorab im
Detail geplante Absprachen bei Schnittstellen und Funktionalität gewährleisten nicht,
dass sich die einzelnen Teile nahtlos ineinander fügen.
Im agilen Umfeld hat sich deshalb die Idee durchgesetzt, dass so schnell wie möglich
und so oft wie nötig integriert wird. Im Rahmen des Continuous Integration werden
bei einer Erweiterung der Code-Basis ab dem Zeitpunkt des Eincheckens in die
Quellcode-Verwaltung entsprechende Prozesse gestartet, die schnell Feedback darüber
geben, ob der Code überhaupt zusammenarbeitet mit dem bereits vorhandenen.
15
Zusätzlich muss auch die Funktionalität des Systems abgeprüft wird. Test Driven
Development mit Test-First-Strategie und automatisierten Test auf Unit-Ebene sorgen
für eine kontinuierliche Überprüfung. Meist werden die automatisierten Test im
Anschluss an die Überprüfung der Integrierbarkeit des Codes ausgeführt. Dieses
schnelle Feedback hilft den Entwicklern zu erkennen, ob ihre Annahmen darüber,
wie das System zu erweitern ist, tatsächlich funktioniert haben.
Das Ganze betrachten
Auch wenn wir im Kleinen an Teilen eines Systems entwickeln, muss in jeder
Entscheidung das Ganze mit berücksichtigt werden. Dies wird um so wichtiger, je
mehr Fremdsysteme im Verbund des eigenen Systems zu betrachten sind.
Intensive Absprachen und ständiger Abgleich in den Sichten bei der Entwicklung der
verschiedenen Teilsysteme hilft Fehlentwicklungen schnell aufzudecken. Ganz
besonders wichtig in diesen komplexen Konstellationen ist es, von Angesicht-zuAngesicht zu kommunizieren und sich nicht auf Dokumente zu verlassen.
Scrum Grundwerte
Im Prinzip kann man die Grundwerte, die das Scrum Framework einführt, als
Ergänzung der Grundwerte des Lean Software Developments betrachten, da sie sich
auf ähnlicher Betrachtungsebene bewegen. Der Focus liegt hierbei noch ein bischen
mehr auf dem Team und dem Vorgehen. Da Scrum wie Lean Software von den
selben Prinzipien, also dem Toyota-Produktionssystem und dem agilen Manifest
inspiriert sind, ergänzen sie sich prima.
Zu den Grundwerten des Scrum Frameworks zählen:
• Respekt
• Offenheit
• Engagement (Commitment)
• Focussierung
• Mut
Respekt
Das Scrum Framework stellt den Menschen und die Interaktion in den Mittelpunkt
der Betrachtung. Dies gilt für alle Rollen des Frameworks: Product Owner,
Entwickler, Scrum Master, bzw. in der erweiterten Sicht für Management, Kunde,
Anwender. Hierfür ist ein respektvoller Umgang miteinander essentiell.
16
Besonders deutlich wird dies in der Sprint Retrospektive, die im Sinne folgender
Aussage von Norman Kerth durchgeführt wird:
Regardless of what we discover, we understand and truly believe that
everyone did the best job they could, given what they knew at the time, their
skills and abilities, the resources available, and the situation at hand.
Man könnte auch sagen: vermute immer das Gute in dem Anderen. Letztendlich geht
hier der Blick ganz klar nach vorne. Es gibt keine Schuldzuweisung an Einzelne,
lediglich die Möglichkeit Vergangenes mit dem neuen Kenntnisstand zu reflektieren
und sich letztendlich als Team zu verbessern [Gloger 2012].
Offenheit
Man verwendet hier auch gerne den Begriff Transparenz. Im Vorgehen werden also
alle Fakten auf den Tisch gelegt und alle Interessierten am Status Quo beteiligt. Dies
gelingt natürlich nur, wenn eine vertrauensvolle Umgebung existiert, in der man frei
kommunizieren kann, ohne in die Falle des Finger-Pointings klassischer Projekte zu
geraten, oder gar persönliche Nachteile zu erleiden.
Transparenz ist ein zentraler Ansatz im Scrum Framework, da er die Grundlage für
die kontinuierliche Verbesserung ist. Ein "Inspect" ohne Transparenz bringt wenig.
Ein "Adapt" gelingt nur, wenn das "Inspect" mit der Realität in Verbindung steht,
sonst werden zwangsläufig die Weichen so gestellt, das die Maßnahmen nicht die
Ursache angehen.
Engagement
Sich für etwas engagieren zu wollen setzt voraus, dass man gestalterischen Einfluss auf
etwas hat. Sonst würde man sich lediglich für die Ideen anderer einsetzen. Dies ist auf
Dauer aber wenig motivierend. Dementsprechend sind die klassischen Ansätze, bei
denen ein Projektleiter die Richtung vorgibt, nur bedingt effizient, besonders wenn
das Team einen anderen Weg für sinnvoller erachtet.
Das Scrum Framework definiert selbstorganisiertes, eigenverantwortliches Handeln
als wesentliche Eigenschaft eines Entwickler-Teams. Innerhalb eines Sprints sind die
Entwickler diejenigen, die sagen wie etwas gemacht wird. Damit existiert ein großer
Raum an Entfaltungsmöglichkeiten, in dem sich die Entwickler entsprechend
engagieren für "ihre" emen.
Die Sache hat noch einen zweiten Aspekt. Es geht auch darum, hinter der eigenen
Entscheidung zu stehen (Sprint Planning 1), und dafür zu sorgen, dass die
angekündigten Ergebnisse eintreffen (Sprint Review). Kurz gesagt: alles dafür zu tun,
dass das fertig wird, zu dem man sich mal "commited" hat.
17
Der Scrum Guide [Sutherland 2013] hat diese und andere Forderungen mittlerweile
etwas aufgeweicht [Katzenberger 2013], indem jetzt eine Art Forecast "zu dem was
fertig werden könnte" vom Entwickler-Team gegeben wird. Das mag besser mit den
Risiken der Realität zusammenpassen. Es bleibt aber zu hoffen, dass das EntwicklerTeam dies nicht zum Anlass nimmt, weniger forsch voranzugehen in seinem
Bestreben hartnäckig zu bleiben, das angekündigte fertig zu machen.
Focussierung
Das Entwickler-Team konzentriert sich mit allen Mitgliedern zu einem Zeitpunkt auf
nur eine Sache, nämlich die gemeinsame Umsetzung eines Product Backlog Items.
Wann was gemacht wird, wird hierbei durch den Product Owner bestimmt, wie es
gemacht wird und von wem durch das Entwickler-Team.
Dieses Vorgehen hilft Verschwendung zu vermeiden, Risiken schneller zu erkennen
und die Fertigstellung nicht "zu verschleppen". Ganz nebenbei stehen die Ergebnisse
dem Anwender früher zur Verfügung, um wertvolles Feedback für die nächste Runde
zu geben.
Mut
Die Software-Entwicklung nach den Regeln des Scrum Frameworks sorgt für eine
kontinuierliche Verbesserung des Vorgehens und der Anpassung an die realen
Gegebenheiten. Das Entwickler-Team verbessert auch kontinuierlich seinen eigenen
Wissensstand. Somit kann es über die Sprints hinweg mehr und mehr Sicherheit
gewinnen, sowohl im Umgang mit den fachlichen wie den technischen emen, und
natürlich auch den sich aus diesen emen ergebenen Risiken.
Je mehr Sicherheit das Team hat desto wahrscheinlicher ist, dass das Entwickler-Team
auch mehr Fachlichkeit schneller umsetzen kann. Die einzige Bedingung dafür ist,
dass es sich nach den einführenden Sprints des Projekts von Sprint zu Sprint ein
wenig mehr emen für die Umsetzung zutraut, um das tatsächliche Potential des
Teams zu entdecken.
Zu entdecken, was tatsächlich alles möglich ist, ist für alle eine wunderbare
Erfahrung. Oft beschränken wir uns nämlich gedanklich selbst zu sehr, um in diesen
Zustand zu gelangen. Deshalb gehört Mut zu einer der wesentlichen Tugenden des
Scrum Frameworks, um erfahren zu können, was wir tatsächlich als Team alles leisten
können.
18
Zentrale Werte des Extreme Programmings
Die Werte des Extreme Programming ergänzen jene des Scrum Frameworks um eine
noch intensivere Ausrichtung auf das Team. Hierbei wird Kommunikation als der
Erfolgsfaktor angesehen.
Folgende Werte werden als zentral betrachtet:
• Kommunikation
• Einfachheit
• Rückmeldung (Feedback)
• Mut
• Respekt
Kommunikation
Die Kommunikation ist offen, findet regelmäßig statt, wird auf gleicher Ebene
geführt und verläuft in alle Richtungen. Dies schließt, gemäß Agilem Manifest,
besonders den Kunden mit ein. Hieraus leitet sich eine entsprechende Transparenz im
Projekt ab. Wesentliches Merkmal der Projekt-Mitglieder ist eine hohe
Kommunikationsbereitschaft.
Einfachheit
Es wird die einfachste aller möglichen Lösungen gesucht und implementiert, die
genau das aktuelle Problem löst und nicht mehr (dem Prinzip "You aren't gonna need
it" folgend). Dies beugt der Verschwendung vor, die entsteht, wenn auf nicht
validierten Annahmen allgemeinere Lösungen angestrebt werden, die für zukünftige
mögliche Anforderungen gewappnet sein sollen.
Sollte sich später einmal herausstellen, dass die aktuelle Architektur für kompliziertere
fachliche Anforderungen nicht ausreicht, so findet eine Erweiterung oder ein
entsprechendes Refactoring statt.
Rückmeldung (Feedback)
Dieser Aspekt ist Teil der intensiven Kommunikation und betrachtet die Kontexte:
• System
Unit Tests bzw. das Continuous Integration geben dem Entwickler Feedback
darüber, ob das getestete System durch zusätzliche Änderungen instabil wird. Dies
soll helfen, dass dieser Zustand zeitnah erkannt und beseitigt werden kann.
19
• Kunde
Akzeptanz-Tests, die die Fachlichkeit abprüfen, liefern dem Kunden Feedback
darüber, ob das getestete System durch Änderungen in seiner Funktionalität
beeinträchtigt ist. Auch dies dient dazu, dass eine Inkonsistenz zeitnah erkannt und
beseitigt werden kann.
• Team
Das Team gibt bei neuen funktionalen Anforderungen durch den Kunden direktes
Feedback zu den zu erwartenden Aufwänden während der Planung.
Mut
Mut wird hier im Sinne der Bewusstseinshaltung von Entwicklern verstanden.
Entwickler sollen den Mut haben, sich nur auf den heutigen Tag zu konzentrieren,
auch auf die Gefahr hin, dass aufgrund erweiterter Anforderungen ein Refactoring
notwendig werden könnte. Sie sollen sich ebenfalls zutrauen bereits erstellten Code
wegzuwerfen, wenn dieser nicht mehr gebraucht wird, und zwar unabhängig davon
wie viel Aufwand und Herzblut zuvor in diesen gesteckt wurde.
Respekt
Respekt schließt ein sowohl sich selbst als auch andere zu respektieren. Entwickler
sollen auf keinen Fall so handeln, dass andere in ihrer Arbeit behindert werden (z.B.
beim Einchecken von Code, der den Build oder die Tests bricht). Sie sollen selbst
immer bestrebt sein eine hohe Qualität in ihren Arbeitsergebnissen zu erreichen.
Die anderen vier Werte zu befolgen führt dazu, dass jeder im Team Respekt erfährt.
Die agilen Werkzeuge
Agile Grundwerte verändern das Denken der Projekt-Mitglieder. Allerdings braucht
es auch entsprechende agile Werkzeuge, mit denen man Taten folgen lassen kann. In
der agilen Community haben sich in der letzten Decade sehr interessant Ansätze
etabliert. Deren Wirksamkeit ist empirisch bewiesen und sie lassen sich auch noch
wunderbar miteinander kombinieren.
Zentral hierbei ist das Scrum Framework, auf dessen vollständige Umsetzung nicht
verzichtet werden kann. Es dient dazu Blue Scrum mit einem agilen Kern
auszustatten, der dafür sorgt, dass die agilen Grundwerte etabliert und gelebt werden.
20
Scrum Framework
Das Scrum Framework lässt sich auf eine Idee zurückführen, die im Umfeld des
Toyota-Produktionssystems entstanden ist [Takeuchi 1986]. Jeff Sutherland und Ken
Schwaber haben diese Grundprinzipien für die Software-Entwicklung zu einem
agilen Werkzeug weiterentwickelt, das heute unter den eingesetzten agilen
Werkzeugen die größte Verbreitung gefunden hat.
Das Scrum Framework ist ein Rahmenwerk, das es erlaubt mit komplexer
Produktentwicklung fertig zu werden [Sutherland 2013]. Es beschreibt aber nicht,
wie ein solches Produkt entwickelt wird. Es muss somit erweitert werden, um einen
vollständigen Entwicklungsprozess zu erhalten. Blue Scrum tut genau das, im Sinne
einer Blaupause, und definiert für größere Projekte zusätzlich ein vollständiges auf
agilen Grundwerten basierendes Projekt-Management.
Wesentliche Grundpfeiler des Scrum Frameworks sind: Transparenz und
Überprüfung und Anpassung ("Inspect and Adapt"). Sie sorgen für eine
kontinuierliche Verbesserung beim Vorgehen und bei der Definition und Erstellung
des Produkts im Sinne der Anwender.
Extreme Programming Engineering Practices
Kent Beck hat mit Extreme Programming (XP) quasi zeitgleich zu Jeff Sutherland
und Ken Schwaber einen agilen Ansatz entwickelt, dessen Schwerpunkt auf den
Software-Entwicklungs-Teams bzw. der Art und Weise wie implementiert wird liegt.
XP definiert ebenfalls einen Prozess. Uns interessieren aber die sog. Engineering
Practices, die eine prima Ergänzung zum Scrum Framework darstellen. Die
Kombination des Scrum Frameworks mit den XP Engineering Practices erlaubt uns
bereits einen umfassenden Software-Entwicklungsprozess zu definieren.
Feature Driven Development
Jeff DeLuca und Peter Coad haben mit ihrem Feature Driven Development (FDD)
eine spezielle Sichtweise für die Definition des angestrebten Geschäftswerts von
Kunden geschaffen [DeLuca]. Mit FDD wurde ursprünglich in einer klassischen
Umgebung ein agiler Ansatz eingeführt, der ein Großprojekt rettete, weil er die
Prinzipien des Agilen Manifests etablieren konnte. Die meisten Rollen bei FDD sind
aber noch klassisch definiert. Für uns ist das Vorgehen hierbei weniger interessant,
sondern eher die Idee, wie der Geschäftswert entsteht im Ablauf von
Anforderungsanalyse, Implementierung, bis hin zur Auslieferung.
Ein Feature wird hierbei als eine Erweiterung des zu erstellenden Systems verstanden,
im Sinne eines Produktmerkmals, das den Geschäftswert erhöht. Die Granularität ist
hierbei fachlich getrieben. Wesentlicher Aspekte im Vergleich zur klassischen
21
komponenten-getriebenen Software-Entwicklung ist, dass der Feature-Ansatz
automatisch für eine bessere Integration bereits während der Implementierung sorgt.
Dies ist ein wichtiges Qualitätsmerkmal und erleichtert das Erzeugen des potentiellauslieferbaren Inkrements am Sprint Ende.
Kanban für Software-Entwicklung
David Anderson hat mit seiner speziellen Interpretation [Anderson 2010] des im
Toyota-Produktionssystems definierten Kanban (siehe hierzu auch [Cope 2011])
einen agilen Ansatz definiert, der noch geeigneter ist für Support- bzw.
Wartungsaufgaben in Projekten als das Scrum Framework. Da in der Wartung
Aufgaben kurzfristig anfallen, also schlecht planbar sind, und diese auch noch schnell
analysiert und abgearbeitet werden müssen (entsprechend vereinbarter Service Level
Agreements), kann das Wartungs-Team hier nur schwer nach Scrum Taktung
vorgehen.
Software Kanban definiert Arbeitsstationen (z.B. Testsysteme) und wie eine zu
bearbeitende Aufgabe diese möglichst schnell durchlaufen kann. Um den Durchlauf
zu erhöhen können Limitierungen definiert werden, die dafür sorgen, dass bereits in
Arbeit befindliche Aufgaben zu Ende gebracht werden, bevor neue angefangen
werden dürfen.
Das agile Projekt-Management
In der (agilen) Projekt-Management-Community wird das ema ProjektManagement im Zusammenhang mit Agilität immer noch kontrovers diskutiert
[Hagen 2012]. Man kann sicher darüber streiten, ob ein neuer Begriff her muss.
Allerdings zeichnet sich schon jetzt in der Community eine Unterscheidung über die
Begriffe „Klassisches Projekt-Management“ und „Agiles Projekt-Management“ ab.
Im anglo-amerikanischen Raum wird sogar grundsätzlich von „Wasserfall vs. Agil“
gesprochen, wenn es um den Vergleich geht. Das ist vielleicht etwas übertrieben, da
mindestens der Rational Unified Process, mit seinem interativ-inkrementellen
Vorgehen starke Verbreitung gefunden hat, und nicht mehr von grundsätzlich
sequentieller Vorgehensweise bei der Software-Entwicklung gesprochen werden kann.
Für Blue Scrum bedeutet agiles Projekt-Management einen hybriden Ansatz zu
verwenden, der einen Kern aus agilen Grundsätzen mit klassischen ProjektManagement-Standards verbindet, in dem er diese so adaptiert, dass ein zeitgemäßes
Projekt-Management gelebt werden kann, das in keinem Fall die agilen Grundwerte
kompromittiert.
Bei den Projekt-Management-Standards interessiert uns vor allem das prozessuale
Vorgehen im Sinne eines ganzheitlichen Ansatzes für ein agiles Projekt-Management.
22
Die meisten agilen Prozessbeschreibungen vernachlässigen das Initiieren und
Beschließen von Projekten, das Staffing, oder auch das Stakeholder- und RisikoManagement im Großen. Hier bieten die klassischen Ansätze sehr viel Interessantes,
dass Blue Scrum entsprechend aufgreift.
Abseits all dieser prozessualen Betrachtungen befassen sich die klassischen Ansätze
verstärkt mit den sozialen Aspekten des Projekt-Daseins, wie etwa Team-Bildung oder
Mediation bei Konflikten. Die meisten sozialen Konzepte lassen sich 1-zu-1 für Blue
Scum übernehmen, da der Bedarf hierfür in agilen Umgebungen mindestens genauso
hoch ist, wenn nicht sogar höher. Transparenz und das Prinzip den Menschen in den
Mittelpunkt zu stellen, erlauben nicht länger den menschlichen Aspekt zu
vernachlässigen oder gar zu ignorieren.
DIN 69901-2
Die DIN 69901 beschreibt Grundlagen, Prozesse, Prozessmodell, Methoden, Daten,
Datenmodell und Begriffe im Projektmanagement. Wir wollen hier nicht alle
Ausarbeitungen betrachten, sondern uns nur jenen Teil anschauen, der für die
Prozesse bzw. das Prozessmodell zuständig ist, also die DIN 69901-2 [DIN 2009].
Die DIN 69901-2 ist angelehnt an die Prozessidee wie sie die ISO 9000 bereits
eingeführt hat [Wagner 2009]. Hierbei steht das „Was zu tun ist“ im Vordergrund.
Dies erlaubt dem Projekt-Manager selbst zu entscheiden „Wie es umzusetzen ist“. Die
Norm ist unabhängig von Branche und Organisation definiert und synchronisiert
Aktivitäten und Beteiligte in Projekten.
Das in der Norm hinterlegte Projekt-Manager-Bild (er sagt wer, was, wann, mit wem,
für wen und warum etwas tut) erlaubt es leider nicht, die Norm 1-zu-1 zu
übernehmen. Wir brauchen hier eine Anpassung an die agilen Grundwerte, mit der
Idee eines agilen Projekt-Managers zu etablieren, der mit den Rollen des Scrum
Frameworks eng zusammenarbeitet, um einen optimalen Rahmen für die
Entwicklung zu schaffen.
IPMA Compentence Baseline 3.0
Zentraler Gedanke in der IPMA Competence Baseline (ICB) für den Erfolg eines
Projekts sind die Kompetenzen der Beteiligten und deren Möglichkeiten diese
anzuwenden. Die Bedeutung von Sozialkompetenz und Führungspersönlichkeit ist
hierbei besonders hervorgehoben. Der Focus liegt auf den handelnden Personen und
weniger auf Prozessen, auch wenn die ICB die DIN 69901-2 vollständig integriert.
Dieser Ansatz kommt den agilen Grundwerten sehr entgegen. Da die ICB das
Projekt-Management weiter fasst, werden wir uns zwar i.W. an den ProjektManagement-Phasen der DIN orientieren, schon weil sie Bestandteil der ICB
geworden sind. Wir werden aber zusätzlich auch die anderen Kompetenzfelder
23
(Anforderungen an das persönliche Verhalten, Umgang mit dem Projekt-Kontext)
verstärkt betrachten.
Zusammenfassung
Das Blue Scrum Prozessmodell ist ein hybrider Ansatz, der aufbauend auf
Industriestandards und Normen agile Ansätze im Sinne eines umfassenden ProjektManagements vervollständigt bzw. klassische Ansätze auf das Fundament eines agilen
Mindsets stellt.
Das Prozessmodell besitzt drei Säulen:
• Die agilen Grundwerte
• Die agilen Werkzeuge, die helfen die Grundwerte zu etablieren
• Das agile Projekt-Management, das erlaubt Software-Entwicklung im größeren
Rahmen agil zu gestalten, unter zu Hilfenahme klassischer Ansätze
Wir werden uns im Folgekapitel „Projektrahmen“ bei der Betrachtung der ProjektManagement-Phasen besonders mit der Frage beschäftigen, inwieweit die
Beschreibungen der DIN 69901-2 unter Berücksichtigung der ICB 3.0 Elemente im
agilen Kontext wiederverwendet werden können und wie notwendige Adapter zu
agilen Werkzeugen aussehen sollten.
24
Der Blue Scrum Projekt-Rahmen
Nachdem wir uns ausführlich mit den agilen Werten befasst und einen Überblick
über die darauf aufsetzenden Werkzeugen bzw. Projekt-Management-Ideen erhalten
haben, beginnen wir nun mit der Definition eines umfassenden agilen ProjektManagement-Ansatzes. Hierbei werden die klassischen Ansätze für ein modernes
Projekt-Management angepasst, in dem die Grundsätze agilen Vorgehens
bei
Übernahme und Adaption von Projekt-Management-Prozessen angewandt werden.
Hieraus entsteht ein Projekt-Rahmen, der optimal für die Integration agiler
Werkzeuge vorbereitet ist.
DIN 69901-2
Das Prozessmodell der DIN 69901-2 unterscheidet:
• Projekt-Phasen (iterativ)
Zeitlich zusammenhängende Abschnitte, die den Projektverlauf mit seinen
inhaltlichen Aktivitäten widerspiegeln, abhängig von Projektart, Branche und
Organisation
• Projekt-Management-Phasen (sequentiell)
Logisch zusammenhängende Aktivitäten des Projekt-Managements
Alle Geschäftsprozesse einer Organisation (das sog. Prozesshaus) lassen sich im
Hinblick auf das Projekt-Management-Prozessmodell in folgende Prozess-Gruppen
unterteilen:
• Führungs-Prozesse
• Projekt-Management-Prozesse
• Unterstützungs-Prozesse
• Wertschöpfungs-Prozesse
Für die Prozess-Gruppe „Projekt-Management-Prozesse“ lassen sich folgende ProzessUntergruppen ableiten:
• Ablauf und Termine
Sachlogische Reihenfolge und vorläufige Projektdauer
• Änderungen
Bewerten, Genehmigen und Durchführen von Änderungen gegenüber der
ursprünglichen Beauftragung
25
• Information/Dokumentation/Kommunikation
Archivierung und Recherche von wichtigen Informationen, Publikationen,
Protokollen, Entscheidungen und Änderungen
• Kosten und Finanzen
Verteilung von Kosten und Managen von Budget
• Organisation
Definition von Rollen, Verantwortlichkeiten, Befugnissen, Aufgaben,
Kommunikation, Schnittstellen und Infrastruktur
• Qualität
Übereinstimmung von Kundenanforderungen und erbrachter Leistung
• Ressourcen
Einsatzmittel, Sachmittel, Personal und Informationen
• Risiko
Analyse und Maßnahmen zur Bewältigung
• Projektstruktur
Grafische Darstellung der Projektaufgaben mit Hilfe von Arbeitseinheiten und
Arbeitspaketen
• Verträge und Nachforderungen
Rechte und Pflichten zwischen Auftraggeber und Auftragnehmer und
Durchsetzung von Ansprüchen
• Ziele
Zielfindung, Analyse, Koordination und Selektion von Zielen
Für die Prozess-Gruppe „Projekt-Management-Prozesse“ lassen sich folgende ProjektManagement-Phasen ableiten, die sowohl für das Einzelprojekt-Management als auch
das Multi-Projekt-Management (Programme, Portfolios) gelten:
• Initialisierung
Analysieren und Bewerten der vorliegenden Projektidee, Skizzieren einer
Projektvision, relevante Prozesse auswählen und vorbereiten für die
Projektabwicklung, Management-Freigabe vorbereiten
Ergebnisse: Benennung von Projekt-Manager + Initial-Team, Skizze der
Projekt-Ziele, Liste ausgewählter PM-Prozesse, Auftrag für die nächste
Phase
• Definition
Nach erteilter Freigabe: Kernteam bilden, SMARTe Ziele definieren, konkrete
Projektinhalte festlegen, wesentliche Meilensteine definieren, grobe
Aufwandsschätzung erstellen, Umfeld- und Stakeholder-Analyse durchführen,
Machbarkeit prüfen, Ableiten kritischer Erfolgsfaktoren, Management-Freigabe
vorbereiten
Ergebnisse: Benennung Projekt-Kern-Team, Projekt-Ziele, Machbarkeitsbewertung, Meilensteinplan, Aufwandsschätzung, grober Projekt-Struk-
26
Projekt-Management-Phasen
Definition
Initialisierung
Umgang mit
Änderungen
planen
Information,
Kommunikation,
Berichtswesen
und Dokumentation planen
Freigabe erteilen
Änderungen
steuern
Information,
Kommunikation,
Berichtswesen
und Dokumentation steuern
Abnahme erteilen
Projekt-Abschlussbericht
erstellen
Projekt-Dokumentation
archivieren
Kosten- und
Finanzmielplan
erstellen
Kosten und Finanzmiel steuern
Nachkalkulation
erstellen
Projekt-Kernteam Projektbilden
Organisation
planen
Kick-off
durchführen
Projekt-Team
bilden
Projekt-Team
entwickeln
Abschlussbesprechung
durchführen
Leistungen
würdigen
Projekt-Organisation auflösen
Erfolgskriterien
definieren
Qualitätssicherung planen
Qualität sichern
Projekt-Erfahrung
sichern
Ressourcenplan
erstellen
Ressourcen
steuern
Ressourcen
rückführen
Umgang mit
Risiken festlegen
Projekt-Umfeld /
Stakeholder
analysieren
Machbarkeit
bewerten
Risiken analysieren
Gegenmaßnahmen zu Risiken
planen
Risiken steuern
Grobstruktur
erstellen
Projekt-StrukturPlan erstellen
Arbeitspakete
beschreiben
Vorgänge
beschreiben
Vertragsinhalte
Verträge mit
mit Lieferanten
Kunden und
festlegen
Lieferanten
abwickeln
Nachforderungen
stellen
Zielerreichung
steuern
Änderungen
Projekt-Management-Prozesse (Prozess-Untergruppen)
Organisation
Information,
Kommunikation
und Berichtswesen festlegen
Projekt-Marketing definieren
Freigabe erteilen
Aufwände grob
schätzen
Kosten
Finanzen
Zuständigkeiten
klären
PM-Prozesse
auswählen
Qualität
Ressourcen
Risiko
Projektstruktur
Verträge
Nachforderungen
Ziele skizzieren
Ziele
Abschluss
Vorgänge
anstossen
Termine steuern
Ablauf, Termine
Information
Dokumentation
Kommunikation
Steuerung
Vorgänge planen
Terminplan
erstellen
Projekt-Plan
erstellen
Meilensteine
definieren
Freigabe erteilen
Planung
Umgang mit
Verträgen
definieren
Vertragsinhalte
mit Kunden
festlegen
Ziele definieren
Projekt-Inhalte
abgrenzen
Verträge beenden
Projekt-Phasen (projektspezifisch, iterativ)
...
27
tur-Plan, Regelungen für Information und Kommunikation,
Vertragsentwurf, Regelungen für Risiko-Management, Freigabe für
nächste Phase
• Planung
Nach erteilter Freigabe: Festlegen, was, wann, wie, und durch wen gemacht werden
soll; Projekt-Strukturplan mit Arbeitspaketen erstellen; Vorgänge definieren;
Termine, Ressourcen und Kosten planen; Vertragsinhalte mit Lieferanten
abstimmen; Freigabe durch den Auftraggeber vorbereiten
Ergebnisse: Projekt-Pläne (Projekt-Struktur, Termine, Kosten, Ressourcen,
Finanzierung), Risikoliste und Risikomaßnahmen, ÄnderungsManagement-Verfahren, Business-Plan, Projekt-Organisation
incl. Rollenbeschreibung, Qualitäts-Management, Freigabe für die
nächste Phase
• Steuerung
Nach erteilter Freigabe: Umsetzen der geplanten Tätigkeiten; Kick-off durchführen;
Team-Bildung/-Entwicklung einleiten; Ist-Stand mit Plan-Werten vergleichen, ggf.
Maßnahmen zur Gegensteuerung einleiten; Change Management (incl. Sicherung
der Nachforderungen); Ergebnis dem Auftraggeber zur Abnahme vorlegen
Ergebnisse: Projekt-Berichte, Abnahmeprotokolle, Entschiedene Änderungsanträge, Nachforderungen, Dokumentationen
• Abschluss
Nach Abnahme: Aufbereiten des gesamten Projekts, Nachkalkulation,
Durchführung Abschlussbesprechung, Abschlussbericht erstellen, Archivierung
wichtiger Unterlagen, Erfahrungssicherung als Input für zukünftige Projekte
Ergebnisse: Abschlussbericht, archivierte Projekt-Dokumentation, dokumentierte
Projekt-Erfahrungen, Nachkalkulation, beendete Verträge
Agiles Projekt-Management
Agiles Projekt-Management definiert, wie in einem agilen Umfeld Projekte geführt
werden. Hierzu wird eine erweiterte agile Sicht auf die Projekt-Management-Prozesse
der DIN 69901-2 entwickelt. Die Rolle des Projekt-Managers verändert sich derart,
dass alle Entscheidungen die agilen Grundwerte berücksichtigen.
Agile Projekt-Management-ProzessUntergruppen
Eine agile Betrachtung der Prozess-Untergruppen ergibt:
28
Projekt-Management-Phasen
Initialisierung
Planung
Steuerung
Abschluss
Product Backlog
erstellen
Release Planung
erstellen
Product Backlog
pflegen
Sprint Planning
Product Backlog
Grooming
Estimation
Meeting
Sprint
Daily Scrum
Information,
Kommunikation
und Berichtswesen festlegen
Projekt-Marketing definieren
Information,
Kommunikation,
Berichtswesen
und Dokumentation planen
Information,
Kommunikation,
Berichtswesen
und Dokumentation steuern
Sprint Review
Projekt-Abschlussbericht
erstellen
Projekt-Dokumentation
archivieren
Aufwände grob
schätzen
Kosten- und
Finanzmielplan
erstellen
Kosten und Finanzmiel steuern
Nachkalkulation
erstellen
Kick-off
durchführen
Projekt-Team
bilden
Projekt-Team
entwickeln
Abschlussbesprechung
durchführen
Leistungen
würdigen
Projekt-Organisation auflösen
Qualität
Akzeptanzkriterien für Product
Backlog Items
Sprint Review
Sprint
Retrospektive
Projekt-Erfahrung
sichern
Ressourcen
Ressourcenplan
erstellen
Ressourcen
steuern
Ressourcen
rückführen
Umgang und
Risiken festlegen
Projekt-Umfeld /
Stakeholder
analysieren
Risiken analysieren
Gegenmaßnahmen zu Risiken
planen
Risiken steuern
Impediments
Backlog pflegen
Impediments
beseitigen
Umgang mit
Verträgen
definieren
Vertragsinhalte
mit Kunden
festlegen
Vision definieren
Vertragsinhalte
mit Lieferanten
festlegen
Verträge mit
Kunden und
Lieferanten
abwickeln
Ablauf, Termine
Freigabe erteilen
Information
Dokumentation
Kommunikation
Projekt-Management-Prozesse (Prozess-Untergruppen)
Definition
Kosten
Finanzen
Organisation
Zuständigkeiten
klären
PM-Prozesse
auswählen
Risiko
Verträge
Nachforderungen
Vision skizzieren
Projekt-Kernteam Projektbilden
Organisation
planen
Verträge beenden
Sprint Goal
definieren
Ziele
Projekt-Phasen (projektspezifisch, iterativ)
Product Backlog
Grooming
Estimation
Meeting
Ersetzung bzw. Ergänzung
Sprint
Planning
Sprint
Sprint
Review
Sprint
Retrospektive
Anpassung
29
• Ablauf und Termine
Wir planen agil mit Product Backlog, Release Burn Down Chart, Sprint Planung
Estimation Meeting, Backlog Grooming und Task Board. Der Zeithorizont für eine
detailliertere Betrachtung geht nicht über drei Sprints hinaus. Es werden keine
Endtermine sondern Terminkorridore berechnet.
• Änderungen
Ein Änderungsmanagement im agilen Umfeld ist nicht notwendig, da der Kunde
bei der Planung für den nächsten Sprint sogar die Möglichkeit hat eine komplette
Kehrtwende zu vollziehen, wenn sein Markt dieses notwendig macht.
• Information/Dokumentation/Kommunikation
Es wird nur das festgehalten, was absolut notwendig ist für die Erstellung des
Codes. Die Spezifikation wird iterativ entwickelt und über den Product Backlog
und dessen Priorisierung gesteuert. Ergebnisse aus der Umfeldanalyse und die
Risikoliste werden z.B. zusammen mit dem Impediments Backlog verwaltet. Eine
formale Freigabe für die Planung ist nicht länger notwendig, da diese iterativ
entwickelt wird.
• Kosten und Finanzen
Die Kosten leiten sich nicht von einem fest vorgegebenen Umfang ab, sondern der
mögliche Umfang vom zur Verfügung stehenden Budget bzw. Zeitrahmen.
• Organisation
Wesentlich hierbei ist ein gut vorbereitetes Umfeld für ein effizientes und effektives
agiles Arbeiten.
• Qualität
Das Scrum Framework definiert bereits wesentliche Aspekte. Das Entwickler-Team
braucht hier ebenfalls ein Umfeld, um die best mögliche Qualität zu erreichen.
• Ressourcen
Wesentlicher Punkt ist die Planung für stabile Teams über eine lange Laufzeit.
Mindestens für die Länge eines Sprints darf die Zusammensetzung der EntwicklerTeams nicht verändert werden.
• Risiko
Die Risikoanalyse und deren Maßnahmen werden im Zusammenhang mit dem
Impediments Backlog betrachtet. Eintretende Risiken können als Teil des
Impediments Backlog verwaltet werden, um sie zu priorisieren bei der Umsetzung
geplanter Maßnahmen.
• Projektstruktur
Da wir nicht langfristig planen, wird dieses ema nicht mehr benötigt. Für die
kurzfristige Planung definiert das Scrum Framework alles notwendige.
• Verträge und Nachforderungen
Die Vertragsausarbeitungen basieren auf gegenseitigem Vertrauen und regeln das
absolut notwendigste. Der definierte Rahmen muss genügend Spielraum für
kurzfristige Änderungen zulassen, die in der laufenden Umsetzung zum Tragen
30
kommen. Da wir kein Änderungsmanagement mehr brauchen, wird die
Betrachtung von Nachforderungen obsolete.
Bei vorab definiertem Liefertermin: Das vom Kunden geplante Budget muss mit
dem zu erwartenden Budget aus dem Release Burn Down Chart regelmäßig
abgeglichen werden.
Bei Festpreis: Der priorisierte Funktionsumfang im Product Backlog muss dem zur
Verfügung stehenden Budget bei der laufenden Sprint Planung (besonders gegen
Ende des Projekts) gegenübergestellt werden. Soweit Funktionsumfang nicht mehr
geleistet werden kann, muss mit dem Kunden überlegt werden, wie der bisherige
priorisierte Funktionsumfang neu definiert werden kann.
• Ziele
Eine direkte Steuerung ist nicht mehr notwendig, da über die Sprint Goals dies
bereits iterativ im Scrum Framework verankert ist.
Agile Projekt-Management-Prozesse
Für die Prozesse ergibt sich nach Betrachtung der Untergruppen folgendes Bild:
Obsolete Prozesse
Nicht länger benötigte Prozesse sind:
• Prozess-Untergruppe „Ablauf und Termine“
• Vorgänge planen
• Terminplan erstellen
• Projekt-Plan erstellen
• Vorgänge anstoßen
• Termine steuern
• PM-Prozess-Untergruppe „Änderungen“
• Umgang mit Änderungen planen
• Änderungen steuern
• PM-Prozess-Untergruppe „Information, Kommunikation, Dokumentation“
• Freigabe erteilen (Definition)
• Freigabe erteilen (Planung)
• PM-Prozess-Untergruppe „Qualität“
• Erfolgskriterien definieren
• PM-Prozess-Untergruppe „Risiko“
31
• Machbarkeit bewerten
• PM-Prozess-Untergruppe „Projekt-Struktur“
• Grobstruktur erstellen
• Projekt-Struktur-Plan (PSP) erstellen
• Arbeitspakete beschreiben
• Vorgänge beschreiben
• PM-Prozess-Untergruppe „Ziele“
• Ziele skizzieren
• Ziele definieren
• Projektinhalte abgrenzen
• Zielerreichung steuern
Anzupassende Prozesse
Agil zu erweiternde bzw. anzupassende Prozesse sind:
• PM-Prozess-Untergruppe „Ablauf und Termine“
• Meilensteine definieren
Das Scrum Framework hat für eine Übersichtsplanung das Release Burn Down
Chart vorgesehen, das den Inhalt des Product Backlog zeitlich bewertet. Die
einzelnen Releases können als Meilensteine betrachtet werden. Allerdings
definiert der Chief Product Owner diese je nach aktueller Sprint Planung und
Velocity des Entwickler-Teams ggf. neu.
• PM-Prozess-Untergruppe „Information, Kommunikation, Dokumentation“
• Information, Kommunikation und Berichtswesen festlegen/planen/steuern
Information: Informationen werden zum großen Teil mündlich und formal
über durch das Scrum Framework definierte Meetings weitergegeben.
Kommunikation: Das Scrum Framework legt mit seinen Meetings und
Artefakten alles notwendige fest, damit eine zielführende Kommunikation
stattfindet.
Berichtswesen: Der aktuelle Zustand des Projekts lässt sich anhand der Task
Boards der Entwickler-Teams ablesen. Die Burn Down Charts visualisieren die
Abweichung des Ist vom Plan. Insofern ist lediglich zu überlegen, ob evtl. ein
entfernter Zugriff auf die Burn Down Charts etabliert werden muss, damit der
Kunde und das Management diese einsehen können. Für eine detailliertere
Betrachtung hat das Scrum Framework das Daily Scrum vorgesehen. Ergänzt
wird dies durch den Product Backlog und den Impediments Backlog bzw. die
Risikoliste.
32
• Abnahme erteilen
Abnahmen von Inkrementen werden iterativ über die jeweils am Ende eines
Sprints stattfindenden Sprint Reviews erteilt. Eine Gesamtabnahme in diesem
Sinne existiert nicht wirklich, auch wenn die letzte Sprint Planung und der
letzte Sprint Review stellvertretend dafür gehalten werden könnten.
• PM-Prozess-Untergruppe „Qualität“
• Qualitätssicherung planen
Der Product Owner definiert Akzeptanzkriterien für Product Backlog Items im
Rahmen der Sprint Planung. Das Scrum Team definiert die Kriterien einer
Definition of Done.
• Qualität sichern
Die Einhaltung der Akzeptanzkriterien und der Definition of Done wird im
Sprint bzw. Sprint Review geprüft. Abweichungen führen zur Nicht-Abnahme
und erneuten Einplanung in Folge-Sprints zur Nachbearbeitung.
• PM-Prozess-Untergruppe „Ressourcen“
• Ressourcen steuern
Wesentlich bei der Steuerung ist die Stabilität der Entwickler-Teams über einen
langen Zeitraum, mindestens aber für den Zeitraum eines Sprints. Nur
ungestörte Entwickler-Teams, die genügend Zeit zum Einschwingen
bekommen, können erwartbare Effizienzsteigerungen erreichen.
• PM-Prozess-Untergruppe „Risiko“
• Risiken steuern
Neben der Überwachung der bewerteten Risiken aus der Risikoliste wird der
Impediments Backlog vom Scrum Master gepflegt, priorisiert und abgearbeitet.
Agile Projekt-Management-Phasen
Durch die Anpassung der Projekt-Management-Prozesse ergeben sich für die ProjektManagement-Phasen entsprechende Veränderungen. Zusätzlich wird die Integration
der agilen Werkzeuge skizziert.
Initialisierung (Machen wir das Projekt?)
Das Management beauftragt den agilen Projekt-Manager eine Projekt-Idee zu
konkretisieren. Er analysiert und bewertet diese und skizziert zusammen mit dem
Chief Product Owner eine erste Vision (Ziele werden erst später in Sprint Planung
definiert). Zusammen mit dem Chief Scrum Master wählt er die relevanten ProjektManagement-Prozesse aus. Das Ergebnis wird dem Management zur Freigabe
vorgelegt.
33
Ergebnisse: Benennung von Projekt-Manager + Chief Product Owner + Chief Scrum
Master, Skizze der Vision, Liste ausgewählter PM-Prozesse, Auftrag für
die nächste Phase
Definition (Entwicklung vorbereiten, Formalien klären)
Der Chief Product Owner und der Customer definieren zusammen:
• Die Vision
• Erste Inhalte (Epics) und eine erste Priorisierung des Product Backlogs
• Erste Release Termine und ein Release Burn Down Chart
Auch wenn die inhaltliche Betrachtung noch grob ist, kann das initiale EntwicklerTeam zusammen mit dem Chief Product Owner Backlog Groomings und Estimation
Meetings durchführen, um Story Points für die Epics zu definieren. Die zugrunde
gelegte Velocity basiert dabei auf Erfahrungen aus vorangegangenen Projekten oder
wird geschätzt.
Der Chief Scrum Master definiert, wie der Entwicklungsprozess aussehen wird.
Zusammen mit dem agilen Architekten, dem agilen Test-Manager und dem agilen
Build-Manager definiert er anhand eines groben Architektur-Entwurfs und der
identifizierten nicht-funktionalen Anforderungen, mit welchen Entwicklungswerkzeugen und welcher Infrastruktur gearbeitet werden sollte.
Das initiale Entwickler-Team wird zusammengestellt. Es kümmert sich um alle
technischen emen, die für die nachfolgenden Entwicklungs-Sprints bereits
vorbereitet sein müssen, z.B. technische Standards, Entwicklungsumgebung, TestUmgebung, Build Management, Continuous Integration und Continuous Delivery.
Je nach Aufgabenanzahl kann dies mehrere Sprints lang dauern. Das initiale
Entwickler-Team kann entweder aus sehr erfahrenen agilen Entwicklern
zusammengesetzt sein, die sehr selbständig arbeiten können, oder aus einer Gruppe
von junioren und senioren Entwicklern, die vom agilen Architekten, agilen TestManager und agilen Build-Manager sowie dem Chief Scrum Master bei der
Umsetzung der Aufgaben und in Vorbereitung der nachfolgenden EntwicklungsSprints gecoacht werden.
Der agile Projekt-Manager kümmert sich um die Analyse der Umfeldeinflüsse, die
Erwartungen relevanter Interessengruppen und betrachtet die Risiken. Zudem
definiert er mit dem Customer die Vertragsinhalte. Dies passiert in enger
Abstimmung mit den Chief Product Owner und dem Chief Scrum Master.
Ergebnisse: Umgebung für initiales Scrum Vorgehen etabliert, Zusammenstellung
des initialen Entwickler-Teams, Vorbereitung der finalen Entwicklungsumgebung, Regelungen für Risiko-Management, Vertrag
34
Planung (auf Sprint-Ebene)
Vor dem ersten Entwicklungs-Sprint klärt der agile Projekt-Manager die
Zusammensetzung der notwendigen Scrum Teams. Hierbei werden Mitglieder des
initialen Entwickler-Teams gleichmäßig auf die neuen Entwicklungs-Teams verteilt
und das Initial-Team aufgelöst. Der Chief Scrum Master und der Chief Product
Owner klären die jeweiligen Scrum Master bzw. Product Owner der neuen Teams
über ihre Verantwortungsbereiche auf und lassen diese anschließend die Sprint
Planung für ihre jeweiligen Team vorbereiten.
In den Folge-Iterationen wird eine scrum-konforme Planung in den jeweiligen Scrum
Teams durchgeführt.
Ergebnisse: Projekt-Organisation (definierte Scrum Teams, Einordnung in
bestehende Organisation), Umgebung für Scrum Vorgehen etabliert
(incl. Einbindung von Customer und Management), Risikoliste und
Risikomaßnahmen
Steuerung (auf Sprint-Ebene)
Der agile Projekt-Manager kümmert sich i.W. um die Aufrechterhaltung einer
störungsfreien Projekt-Umgebung und versorgt Customer und Management mit den
notwendigen projekt-technischen Informationen. Die Scrum Teams, der Chief
Product Owner und der Chief Scrum Master sorgen in Folge-Iterationen für eine
scrum-konforme Umsetzung.
Ergebnisse: Potentiell auslieferbare Inkremente, Projekt-Berichte, Dokumentationen
Abschluss (Erforderlicher Geschäftswert ist geliefert)
Nachdem das letzte potentiell auslieferbare Inkrement erstellt und ausgeliefert
worden ist, schließt der agile Projekt-Manager das Projekt ab.
Ergebnisse: Abschlussbericht, Archivierte Projekt-Dokumentation, dokumentierte
Projekt-Erfahrungen, Nachkalkulation, beendete Verträge
35
IPMA Competence Baseline 3.0
Die IPMA Competence Baseline (ICB) unterscheidet drei Kompetenzfelder:
• Fachlich-methodischer Bereich (PM-technische Kompetenz)
Methodische und fachlich-technische Kompetenzen des Projekt-Managements;
vergleichbar mit den Projekt-Management-Prozessen der DIN 69901-2
• Verhaltensbereich (PM-Verhaltenskompetenz)
Anforderungen an das persönliche Verhalten von Projekt-Managern; Gestaltung
von Beziehungen, Selbstreflexion
• Kontextbereich (PM-Kontextkompetenz)
Umgang mit dem Projektkontext (z.B. Linienorganisation bei Change-Prozessen
innerhalb der Organisation); Ausführung der im Prozesshaus der DIN 69901-2
definierten Prozess-Gruppen.
PM-technische Kompetenz
Die Elemente der PM-technischen Kompetenz sind:
• Projekt-Management-Erfolg
Effektiver und effizienter Einsatz von Methoden zur Steigerung des wirtschaftlichen
Erfolgs und der Stakeholder-Zufriedenheit (Einhaltung definierter Ziele)
• Interessierte Parteien
Analyse und Management von Projektumfeld und Stakeholdern
• Projektanforderungen und Projektziele
Zielfindung, Analyse, Koordination und Selektion von Zielen
• Risiken und Chancen
Analyse und Maßnahmen zur Bewältigung von Risiken; Erkennen und Nutzen von
ungeplanten Möglichkeiten
• Qualität
Übereinstimmung von Kundenanforderungen und erbrachter Leistung
• Projektorganisation
Definition von Rollen, Verantwortlichkeiten, Befugnissen, Aufgaben,
Kommunikation, Schnittstellen und Infrastruktur
36
• Teamarbeit
Team-Bildung, informelle Rollen, Kommunikation, Mitarbeiter befähigen
• Problemlösung
Ursache finden, Lösung erarbeiten und umsetzen
• Projektstrukturen
Grafische Darstellung der Projektaufgaben mit Hilfe von Arbeitseinheiten und
Arbeitspaketen
• Leistungsumfang und Lieferobjekte
Projekt- und Produktinhalt, Festhalten in Lastenheft, Pflichtenheft,
Projektsteckbrief
• Projektphasen, Ablauf und Termine
Projekt-Management- und Projekt-Phasen, Vorgehensmodell, Aktivitäten,
Meilensteine, Fortschrittsmessung
• Ressourcen
Einsatzmittel, Sachmittel, Personal und Informationen
• Kosten und Finanzmittel
Verteilung von Kosten und Managen von Budget
• Beschaffung und Verträge
Bedarfsermittlung und Lieferantensuche, Rechte und Pflichten zwischen
Auftraggeber und Auftragnehmer
• Änderungen
Bewerten, Genehmigen und Durchführen von Änderungen gegenüber der
ursprünglichen Beauftragung
• Überwachung und Steuerung, Berichtswesen
Projektfortschritt, Controlling, Steuerungsmaßnahmen
• Information und Dokumentation
Archivierung und Recherche von wichtigen Informationen, Publikationen,
Protokollen, Entscheidungen und Änderungen
• Kommunikation
Akzeptanz für das Projekt gewinnen, Eigenmotivation bei Mitarbeitern fördern
• Start
Projekt vorbereiten
• Abschluss
Produktabnahme, Abschlussanalyse, Erfahrungssicherung
PM-Verhaltenskompetenz
Der Vollständigkeit halber hier die Elemente der PM-Verhaltenskompetenz, die wir
für das Blue Scrum Prozessmodell nicht detaillierter betrachten:
37
• Führung
• Engagement und Motivation
• Selbststeuerung
• Durchsetzungsvermögen
• Entspannung und Stressbewältigung
• Offenheit
• Kreativität
• Ergebnisorientierung
• Effizienz
• Beratung
• Verhandlungen
• Konflikte und Krisen
• Verlässlichkeit
• Wertschätzung
• Ethik
PM-Kontextkompetenz
Der Vollständigkeit halber hier die Elemente der PM-Kontextkompetenz, die wir für
das Blue Scrum Prozessmodell nicht detaillierter betrachten:
• Projekt-Orientierung
• Programm-Orientierung
• Portfolio-Orientierung
• Einführung von Projekt-, Programm- und Portfolio-Management
• Stammorganisation
• Geschäft
• Systeme, Produkte und Technologie
• Personalmanagement
• Gesundheit, Betr.-, Arbeits- u. Umweltschutz
• Finanzierung
• Rechtliche Aspekte
38
Mapping zwischen DIN 69901-2 und ICB 3.0
Nachfolgend die Zuordnung der ICB-Kompetenzelemente zu den ProjektManagement-Phasen der DIN 69901-2 [Schulz 2011]:
DIN Phase
ICB Kompetenzelemente
Initialisierung
1.00 Projekt, Projekt-Management, Projekt-Arten, ProjektManagement-Prozesse
3.01 Projekt-Orientierung
Definition
1.07 Teamarbeit
1.03 Projekt-Anforderungen, Projekt-Zielsetzungen
1.10 Leistungsbeschreibung, Lieferobjekte
2.08 Ergebnisorientierung
1.01 Projekt-Management-Erfolg
1.02 Umfeld, Interessierte Parteien
1.11a Projekt-Phasen
1.18 Kommunikation
1.19 Projekt-Start
Planung
1.09 Projekt-Strukturen
1.06 Projekt-Organisation
3.05 Stamm-Organisation
3.08 Personal-Management
1.11b Ablauf, Termine
1.12 Ressourcen
1.13 Kosten, Finanzmittel
1.04 Risiken, Chancen
2.02 Motivation, Engagement
2.01 Führung
1.08 Problemlösung, 2.07 Kreativität
1.05 Qualität
39
Steuerung
1.16 Projekt-Controlling: Überwachung, Steuerung,
Berichtswesen
1.17 Information, Dokumentation
1.15 Konfiguration, Änderungen
1.14 Vertragliche Aspekte der Projektarbeit
2.11 Verhandlungen
2.12 Konflikte, Krisen
2.15 Ethik
Abschluss
1.20 Projekt-Abschluss
Nachfolgend die Zuordnung der ICB-Kompetenzelemente zu den ProjektManagement-Prozessen der DIN 69901-2 [PM3 2010]:
ICB Kompetenzelement
DIN Typ
DIN Projekt-ManagementProzess
1.01 Projekt-ManagementErfolg
---
---
1.02 Interessierte Parteien
Prozess D 8.2
Projekt-Umfeld/Stakeholder
analysieren
1.03 Projekt-Anforderungen
und Projekt-Ziele
Prozess
Untergruppe 11
Ziele
1.04 Risiken und Chancen
Prozess
Untergruppe 8
Risiko
1.05 Qualität
Prozess
Untergruppe 6
Qualität
1.06 Projekt-Organisation
Prozess
Untergruppe 5
Organisation
1.07 Teamarbeit
Prozess
Untergruppe 5
Organisation
1.08 Problemlösung
---
---
1.09 Projekt-Strukturen
Prozess
Untergruppe 9
Projekt-Struktur
1.10 Leistungsbeschreibung
und Lieferobjekte
Prozess D 11.2
Projekt-Inhalte abgrenzen
40
1.11 Projekt-Phasen, Ablauf
und Termine
Prozess
Untergruppe 1
Ablauf und Termine
1.12 Ressourcen
Prozess
Untergruppe 7
Ressourcen
1.13 Kosten und
Finanzmittel
Prozess
Untergruppe 4
Kosten und Finanzen
1.14 Beschaffung und
Verträge
Prozess
Untergruppe 10
Verträge und Nachforderungen
1.15 Konfiguration und
Änderungen
Prozess
Untergruppe 2
Änderungen
1.16 Projekt-Controlling:
Überwachung und
Steuerung, Berichtswesen
PM-Phase
Steuerung
1.17 Information und
Dokumentation
Prozess
Untergruppe 3
Information, Kommunikation,
Berichtswesen und
Dokumentation
1.18 Kommunikation
Prozess
Untergruppe 3
Information, Kommunikation,
Berichtswesen und
Dokumentation
1.19 Projekt-Start
PM-Phase
Initialisierung
1.20 Projekt-Abschluss
PM-Phase
Abschluss
Agile Elemente der PM-technischen Kompetenz
Der Definition agiler Projekt-Management-Prozesse auf Basis der DIN 69901-2
folgend ergeben sich für die korrespondierenden agilen Elemente:
Obsolete Prozesse
Nicht länger benötigte Elemente sind:
• Element „Konfiguration und Änderungen“
• Element „Projekt-Strukturen“
Anzupassende Elemente
Agil zu erweiternde bzw. anzupassende Elemente sind:
41
• Element „Projekt-Phasen, Ablauf und Termine“
Der Phasenplan wird ersetzt durch die Release Burn Down Chart Betrachtung.
Projekt-Struktur-Plan, Ablauf- und Terminplanung, etc. fallen weg und werden
durch das iterative Vorgehen nach Scrum ersetzt.
• Element „Information und Dokumentation“, Element „Kommunikation“
Es wird nicht über Dokumente miteinander kommuniziert, sondern im direkten
Kontakt. Dokumentation entsteht nur im Kontext des angestrebten Geschäftswert.
• Element „Qualität“
Wird durch den im Scrum Vorgehen verankerten Deming-Kreis ersetzt und
leichtgewichtiger betrachtet (Akzeptanzkriterien, Definition of Done, Sprint
Review).
• Element „Ressourcen“
Die Unversehrtheit des Teams, die dedizierte Zuordnung eines Mitarbeiters zu
maximal einem Team (sic Projekt) und das Arbeiten in einem vor äußeren
Einflüssen geschützten Umfeld, sind wesentliche Voraussetzungen für effizientes
Vorgehen.
• Element „Risiken und Chancen“
Die Risikoliste und die Risikomaßnahmen werden ergänzt um das Verwalten und
Beseitigen von Impediments.
• Element „Projekt-Anforderungen und Projekt-Ziele“
Selbstverantwortliches Handeln benötigt eine Vision, die im gesamten ProjektVerlauf die Richtung vorgibt. Als John F. Kennedy in seiner Rede formulierte, dass
die USA bis zum Ende des Jahrzehnts (1960er Jahre) einen Menschen zum Mond
schicken und ihn auch gesund wieder zur Erde zurückholen wollten, war für alle
NASA-Mitarbeiter klar wohin die Reise geht.
Bei der iterativen Sprint Planung wird für jeden Sprint ein Ziel definiert, das die
Richtung im Sprint vorgibt. Dieses steht immer im Einklang mit der ProjektVision.
42
Das Blue Scrum Vorgehensmodell
Wir befassen uns im folgenden mit diesen emen:
• Feature-bezogene Planung und Umsetzung
• Agile Prozesse auf Basis des Scrum Frameworks
• Implementierung mit Hilfe der XP Engineering Practices
• Nachgelagerte Wartung auf Basis von Kanban
Das Feature als fachliche Erweiterung des
Systems
Zentral bei der agilen Entwicklung ist das Vermeiden von Verschwendung. Hierbei
wird der Focus auf den Geschäftswert (Business Value) des Kunden gelegt. Dieser
lässt sich am Besten in Form von Features formulieren.
Anforderungsbeschreibungen
Ein Feature (Produktmerkmal) ist zunächst einmal eine abstrakte Darstellung eines
geplanten Geschäftswert. Eine Formulierung wie “Die Anwendung kann
Geschäftsberichte drucken” dient als eine Art Zielbeschreibung. Nicht weiter
detailliert handelt es sich hier um ein Epic, wie es XP kennt. Ausgearbeitet ergeben
sich 1-n geplante PBIs, die in Sprints umgesetzt werden können. So kann das Feature
etwa folgende PBIs beinhalten:
• “Als CEO kann ich den Geschäftsbericht des letzten Quartals drucken, um mich
auf die anstehende Pressekonferenz vorzubereiten”
• “Als Controller kann ich den Geschäftsbericht des Vorjahrs drucken, um die
Entwicklung von Kennzahlen zu beurteilen”.
Implementierung
Der Feature-Ansatz verändert die Art, wie Software entwickelt wird. Im Gegensatz zu
einer klassischen Umsetzung in Form von spezialisierten Komponenten, die meist
von hochspezialisierten Entwicklern gebaut werden, wird der Integrationsgedanke
schon während der Umsetzung fokussiert. Meist zieht sich ein Feature durch
verschiedene Architekturschichten oder ist komponentenübergreifend zu
43
implementieren. Design, Implementierung und Test richten sich somit automatisch
auf das ema Integration aus.
Soweit mehrere Scrum Teams zur Verfügung stehen, können diese thematisch
organisiert arbeiten. Den fachlichen Schwerpunkten der Teams können dann
entsprechende Features in der Planung zugeordnet werden. Dies funktioniert
allerdings nur dann, wenn Features gleichmäßig über die Teams verteilt werden
können.
Integrationstest
Bei komponenten-orientierter Entwicklung steht am Ende meinst ein beträchtlicher
Aufwand, da die gelebte Separation während der Entwicklung nur selten zu einer
komponenten-übergreifende Sicht führt. Selbst wenn die vorher vereinbarten
Schnittstellen ineinander greifen, so ist damit die Funktionalität der Komponenten
noch nicht automatisch aufeinander abgestimmt. Dieses Defizit muss dann mühselig
im Integrationstest wieder ausgebügelt werden.
Von der Anforderung zur Implementierung
Ein Feature wird in einem oder mehr Product Backlog Items umgesetzt. Features sind
so geschnitten, dass sie innerhalb eines Releases umgesetzt werden können, Product
Backlog Items so, dass sie in einem Sprint umgesetzt werden können. Im Idealfall
kann ein Feature in einem Sprint umgesetzt werden, was dem Ursprünglichen Ansatz
des FDD entspricht. Das Modell erlaubt aber auch, dass ein Feature fachlich größer
geschnitten wird und somit über verschiedene Sprints hinweg implementiert werden
kann. Dies erlaubt eine Granularität, die unabhängig von der Velocity des
Entwickler-Teams gewählt werden kann.
Grundsätzlich entscheidet das Entwickler-Team selbst, wie ein Product Backlog Item
umgesetzt wird. Die Anzahl der Tasks ist hierbei frei wählbar und im Sprint beliebig
veränderbar. Einzig die Bearbeitungsdauer einer Task darf einen Tag nicht
überschreiten.
Das Scrum Framework als Entwicklungsrahmen
Wir schauen uns zunächst wichtige Details des Scrum Frameworks an und definieren
dann zusätzliche Rollen und Meetings, um ein umfassendes agiles ProjektManagement für größere Projekte etablieren zu können.
44
Das Scrum Framework
Das Scrum Framework beschreibt:
• Meetings
• Sprint Planung (Planning)
• Daily Scrum (Daily)
• Sprint Review (Review)
• Sprint Retrospektive (Retro)
• Rollen
• Product Owner (PO)
• Entwickler-Team
• Scrum Master (SM)
• Artefakte
• Product Backlog
• Sprint Backlog
• Inkrement
• Definition of Done (DoD)
Erweiterte Rollen
In [Gloger 2011] werden zusätzlich folgende Rollen definiert, um den erweiterten
Team-Kontext zu beschreiben (wobei eine Rolle als Container von
Verantwortlichkeiten definiert wird, die eine Person aus innerem Antrieb
wahrnimmt, und nicht etwa als Position in einer Organisation, deren Erfüllung
von außen gesteuert wird):
• Customer
• User
• Management
Basierend auf den Anmerkungen zu den Veränderungen bei klassischen Rollen in
[Cohn 2009] definiert Blue Scrum weitere Rollen. Allen gemeinsam ist, dass ihre
Entscheidungen von den agilen Grundwerten getragen werden und sie sich dem
Servant Leadership verpflichten. Hierbei bleibt die Verantwortung weitestgehend
beim Scrum Team und die Rolle fokussiert sich auf dessen Coaching. Je nach
Projekt-Größe sollte entschieden werden, ob die jeweilige Rolle durch eine
dedizierte Person abgebildet und über die komplette Projekt-Laufzeit gebraucht
wird:
45
• Agiler Projekt-Manager (PM)
• Agiler Architekt
• Agiler Test-Manager
• Agiler Build-Manager
• Chief Product Owner (Chief-PO)
• Chief Scrum Master (Chief-SM)
Erweiterte Meetings
Aufsetzend auf den Ideen in [Gloger 2011] definiert Blue Scrum eine erweiterte,
formalisierte Kommunikation, um die Planungsvorbereitung und den Multi-TeamKontext zu unterstützen:
• Scrum of Scrums
• Product Owner Runde
• Scrum Master Runde
• Backlog Grooming
• Estimation Meeting
Meetings
Deming‘s „Inspect and Adapt“ wird formal durch vier Ereignisse etabliert, die immer
zu gleichen Zeitpunkten innerhalb eines Sprints (Iteration) und ausgerichtet nach der
Produkt-Vision und eines wechselnden Sprint-Zieles stattfinden:
• Sprint Planung - Planung in Absprache mit dem Entwickler-Team
• Daily Scrum (Daily) - Micro-Planung während der konkreten Umsetzung durch
das Entwickler-Team
• Sprint Review - Überprüfung des Zwischenergebnisses (Inkrement) und
Vorbereitung der Ausrichtung für den nächsten Sprint
• Sprint Retrospektive (Retro) - Reflexion des Sprints und Erarbeitung von
Verbesserungsmaßnahmen zur Umsetzung im nächsten Sprint
Rollen
Ein Scrum Team besteht aus folgenden Rollen:
• Product Owner - Treibt die Entwicklung aus fachlicher Sicht, um den
Geschäftswert für den Kunden zu erhöhen
46
• Entwickler-Team - drei bis neun Generalisten, die eigenverantwortlich die
fachlichen Anforderungen unter den gegebenen technischen Rahmenbedingungen
programmieren, testen und ausliefern
• Scrum Master - Servant Leader, der Probleme zeitnah auflöst und auch für die
Weiterentwicklung des Entwicklungsprozesses zuständig ist
Artefakte
Gewisse Schlüsselinformationen im transparenten Vorgehen werden in folgenden
Artefakten formalisiert:
• Product Backlog - Priorisierte Liste von Anforderungen, die der Product Owner für
die Planung von Sprints pflegt. Sie gibt gleichzeitig Auskunft darüber in welchem
Zeitfenster das Projektziel erreicht sein könnte.
• Sprint Backlog - Priorisierte Liste von Product Backlog Items, die im aktuellen
Sprint umgesetzt werden.
• Inkrement - Potentiell auslieferbarer Code der alle Implementierungen des
aktuellen und der vorherigen Sprints erhält und die Kriterien der Definition of
Done erfüllt.
• Definition of Done - Regeln, die definieren, wann ein Product Backlog Item oder
ein Inkrement als „fertig implementiert“ zu bezeichnen sind (incl. aller
Qualitätsanforderungen)
Customer
Der Customer beauftragt und finanziert das Produkt, um seine User zufrieden zu
stellen.
User
Die User verwenden das vom Customer beauftragte Produkt letztendlich. Sie sind die
eigentlichen Fachleute der Fachlichkeit.
Management
Das Management ist die Organisationseinheit, die den Projekt-Rahmen bereitstellt.
Sie steht in engem Zusammenhang mit dem agilen Projekt-Manager, der bei
größeren Vorhaben als explizite Rolle aus dem „Management-Schatten“ hervortritt.
47
Agiler Projekt-Manager
In der agilen Community wird immer noch diskutiert, ob es eine Rolle ProjektManager braucht, um ein agiles Projekt erfolgreich durchzuführen. Das Scrum
Framework teilt den Projekt-Manager auf drei Rollen auf, so dass dieser nicht länger
benötigt wird:
• Product Owner - Alle Aspekte, die dafür sorgen, dass der Geschäftswert entsteht,
den der Kunde anstrebt (regelmäßiger Kundenkontakt; Kundenzufriedenheit; das
Was)
• Entwickler-Team - Alle planerischen Aspekte der Umsetzung, in einen
selbstorganisierten, selbstverantwortlichen Rahmen eingebettet (Qualität, MicroManagement; das Wie)
• Scrum Master - Alle Verfahrensweisen, die dafür sorgen, dass bei der Umsetzung
der angestrebte Geschäftswert in gewünschter Qualität entstehen kann (ProjektLebenszyklus; Rentabilität; das Womit)
Für kleine Projekt-Kontexte mag das gut funktionieren, wenn man die Rollen Kunde,
Anwender und Management mit dazu nimmt [Gloger 2011]. Dann können nämlich
alle projekt-technischen Aspekte von der Rolle Management mit abgedeckt
werden.
Betrachtet man nun aber größere Projekt-Kontexte (> 2 Scrum Teams), lassen sich
die projekt-technischen Aspekte nicht mehr wirklich nebenher abbilden. Hier
wird es sinnvoll eine dedizierte Person abzustellen, die sich zeitlich alleine auf
genau diese Themen konzentrieren kann.
Agiles Mindset und Servant Leadership
Der agile Projekt-Manager muss sich von dem Gedanken lösen, dass er z.B. bei
der Planung bis ins Kleinste mitredet. Dafür ist das Entwickler-Team zuständig.
Seine Aufgabe liegt darin, den Projekt-Rahmen zu definieren und stabil zu
halten. Wichtige Aspekte hierbei sind die Umfeld-Analyse, die
Außenkommunikation bzw. das Projekt-Marketing und das Risiko-Management
auf höherer Ebene. Diese Themen definiert und etabliert er in enger Absprache
mit dem Chief Product Owner (letzte Entscheidungsinstanz bei fachlichen
Fragen) und dem Chief Scrum Master (letzte Entscheidungsinstanz bei
prozessualen Fragen).
Den Entwickler-Teams hilft er bei der Beseitigung von Impediments und der
Abwehr von Störungen, die Einfluss auf den Verlauf von Sprints nehmen
könnten. Für den Kunden ist er z.B. erster Ansprechpartner bei Fragen des agilen
Vorgehens.
48
Kurz gesagt: er bestimmt nicht, wie es läuft, sondern er hilft mit, dass es läuft - und
dies in enger Absprachen mit dem Chief Product Owner und dem Chief Scrum
Master.
Agiler Architekt
Einen agilen Architekten erkennt man daran, dass er nicht daran arbeitet alle in der
Zukunft erdenklichen Fälle in sein Architekturkonzept zu übernehmen, sondern für
die gerade notwendige Fachlichkeit plant. Er sieht Technik nicht als Selbstzweck,
sondern sieht sich im Dienste der Fachlichkeit handeln. Sein Focus liegt auf
Veränderung und Komplexität.
Hierbei berät der agile Architekt andere in allen technischen Aspekten, die für die
Planung oder Umsetzung relevant sein könnten. So tritt er als Coach für das initiale
Entwickler-Team auf und hilft dabei, dass sich Architektur-Know-How in den
Folgeteams etabliert.
Agiler Test-Manager
Das kontinuierliche Testen von Code ist ein wesentlicher Aspekt für den Erfolg agilen
Vorgehens. Das dafür notwendige Wissen bringt das Entwickler-Team nicht
grundsätzlich von vorne herein mit. Der agile Test-Manager coacht die EntwicklerTeams, so dass sie sich in der Lage sehen, selbständig automatisierte Tests zu schreiben
und deren Lauffähigkeit überwachen zu können. Der agile Test-Manager arbeitet
hierbei eng mit dem agilen Build-Manager zusammen.
Agiler Build-Manager
Der agile Build-Manager coach das Entwickler-Team in Bezug auf Infrastrukturemen (Entwicklungsumgebung, server-seitige Builds, etc.) Besonderes Augenmerk
legt er hierbei auf die emen Continuous Integration und Continuous Delivery.
Chief Product Owner
Der Chief Product Owner (Chief-PO) ist eine Rolle, die in größeren ProjektKontexten etabliert werden sollte. Grundsätzlich kann formal einer der existierenden
POs diese Rolle mit übernehmen. Da aber der Koordinationsaufwand mit der Menge
an Entwickler-Teams steigt, kann es sehr schnell interessant werden, eine dedizierte
Person diese Rolle einnehmen zu lassen. Die Einführung dieser Rolle vereinfacht
grundsätzlich die Kommunikation über fachliche emen für den Kunden. Der
Projekt-Manager, der das Projekt zwar nach Außen vertritt, wird nicht in Gänze für
fachliche Fragen geeignet sein.
49
Der Chief-PO ist letzte Instanz bei fachlichen Entscheidungen. Er übernimmt zudem
die team-übergreifende Planung (Priorisierung für die Implementierung) und die
fachliche Kommunikation mit dem Kunden.
Chief Scrum Master
Ähnlich dem Chief-PO ist der Chief Scrum Master (Chief-SM) in größeren ProjektKontexten für alle prozessualen Belange einsetzbar. Er ist letzte Instanz bei
prozessualen Entscheidungen, treibt team-übergreifende prozessuale Optimierungen
und priorisiert die Beseitigung von Impediments.
Herausforderungen
Das Scrum Framework ist leichtgewichtig, einfach zu verstehen, aber wegen seines
disruptiven Charakters schwer zu etablieren in einer Organisation, die es als Vorgehen
im Rahmen ihres Projekt-Managements einsetzen möchte.
Wesentliche Herausforderungen hierbei sind:
• Das Management gibt Verantwortung und Kontrolle ab, da Scrum Teams
eigenverantwortlich handeln.
• Die Mitarbeiter sind nicht länger Ressourcen, sondern werden als Erwachsene auf
gleicher Augenhöhe respektiert, die einen wertvollen Beitrag durch ihre
Persönlichkeit für die Organisation leisten.
• Manager wechseln in die Rolle eines Servant Leaders, also einer dienenden
Führungspersönlichkeit, die ihre Hauptaufgabe darin sieht, das Entwickler-Team
kontinuierlich in seinem Handeln zu unterstützen. Hierbei wird permanent daran
gearbeitet, eine für das Entwickler-Team optimale Arbeitsumgebung zu schaffen im
Sinne eines effizienten ("Tun wir es richtig?") und effektiven Vorgehens ("Tun wir
das richtige?").
• Ansehen entsteht nicht länger durch die Position in der Organisation, sondern
durch den konkreten Beitrag zum angestrebten Ergebnis.
• Probleme werden sofort und schonungslos aufgedeckt, da Transparenz und offene
Kommunikation das Leitmotiv sind.
• Der Status Quo unterliegt ständigem Wandel, da die kontinuierliche Verbesserung
den Status Quo in kurzen Zyklen in Frage stellt, um ihn danach zu verbessern.
50
Die XP Engineering Practices für die konkrete
Implementierung
Die XP Praktiken sorgen dafür, dass Verschwendung bei der Programmierung
vermieden wird. Man unterscheidet zwischen
• Hauptpraktiken
• Ergänzende Begleitpraktiken
Hauptpraktiken
Räumlich zusammen sitzen
Die beste Kommunikation entsteht, wenn von Angesicht-zu-Angesicht kommuniziert
wird. Je schneller man dabei zusammenfindet, desto besser. Wenn sich alle in einem
Raum befinden und mindestens in Rufweite voneinander entfernt sitzen, sind
spontane Gespräche zeitnah und leicht zu initiieren.
Energievolle Arbeit
Es wird nur die Zeit gearbeitet, in der man wirklich produktiv sein kann. Damit ist
die 40-Stunden-Woche nicht länger eine Floskel und unproduktive Überstunden
werden nicht länger honoriert (oder sogar gefordert). Mehrarbeit wird streng
reglementiert, aber nicht grundsätzlich ausgeschlossen.
Stories
Anforderungen werden als User Stories formuliert, die priorisiert werden können und
deren erwarteter Aufwand über relatives Schätzen (z.B. Story Points) ermittelt wird.
User Storys sind Merker für etwas, das zu einem späteren Zeitpunkt, nämlich der
konkreten Implementierung, erst detailliert wird - durch direkte Kommunikation mit
dem Kunden.
51
Pair-Programming
„Doppelter Aufwand für die gleiche Tätigkeit?“ würde ein klassischer ProjektManager sofort in die Runde werfen. Allerdings greift diese Betrachtung genauso kurz
wie die Idee „je mehr Leute ich ins Projekt stecke, desto schneller bin ich fertig“.
Tatsächlich ergeben sich beim Pair-Programming interessante Synergien, die zunächst
nicht sofort ersichtlich werden. Im Prinzip wird durch das Vier-Augen-Prinzip eine
automatische Qualitätssicherung aktiviert, welche die spät erkannten und meist sehr
teuer zurückgebauten Abweichungen in späteren Projekt-Phasen bereits bei ihrem
Entstehen aufdeckt.
Wenn zwei Entwickler zeitgleich über dasselbe Problem nachdenken, besteht eine
gewisse Wahrscheinlichkeit, dass das dabei entstehende Design qualitativ besser ist.
Dies kann Wartungsprobleme verhindern helfen. Und ganz nebenbei kann auch noch
ein Know-How-Transfer stattfinden, der besonders bei junioren Entwicklern schnell
zu besserem Code führen kann.
Entspannte Arbeit
Das Ziel ist nur solche Versprechen zu geben, die auch in der zur Verfügung
stehenden Zeit gehalten werden können. Unter Anspannung mehr zu produzieren
um Verlorenes wieder aufzuholen, führt nur zu mehr Fehlern und damit zu noch
mehr Problemen. Letztendlich sinkt unterm Strich die Entwicklungsgeschwindigkeit.
Deshalb sollen die Entwickler in einer entspannten Atmosphäre hoch konzentriert
arbeiten können.
Kontinuierliche Integration
Eines der größten Probleme in der Vergangenheit der Software-Entwicklung waren
die zu spät geplanten Integrationen von Teilen eines Systems, die bis dahin im Projekt
separat entwickelt und getestet wurden. Selbst bei detailliert ausgehandelten
Schnittstellen kann nicht davon ausgegangen werden, dass hinterher alles
zusammenarbeitet. Deshalb wird angestrebt möglichst frühzeitig und regelmäßig zu
integrieren. Dies deckt Probleme schnell auf und reduziert die Aufwände durch zu
spät erkannte Design- und Implementierungsfehler. Es schützt das Team auch davor
kurz vor der Auslieferung noch grundlegende Teile des Systems überarbeiten zu
müssen, die dann halbgetestet (aus Zeitgründen) ausgeliefert werden.
Test-First Programmierung
Wenn ich beschreiben kann, was ich als Ergebnis erwarte, und die Einhaltung des
Ergebnisses auch noch jederzeit automatisiert abprüfen kann, bin ich in der Lage an
Bestehendem etwas zu verändern ohne Gefahr zu laufen Seiteneffekte zu erhalten.
52
Wenn ich jetzt noch das Ergebnis zuerst formuliere und dann den Code, der es
erzeugt, dann bin ich optimal unterwegs bei der Software-Entwicklung. Soweit die
eorie.
In der Praxis wird Test First zu einer Art Ping Pong Entwicklung zwischen
automatisierter Test- und Code-Weiterentwicklung führen, da nur immer soviel Code
formuliert werden soll, bis der Test „grün“ wird. Danach wird der Test um eine
weitere Testbedingung erweitert, so dass der Test erst einmal wieder fehl schlägt. Im
nächsten Schritt wird wieder der Code angepasst - und sofort.
Informativer Arbeitsplatz
Am Arbeitsplatz stehen alle Informationen zur Verfügung, die für ein effektives
Arbeiten benötigt werden. Dies können z.B. Task Boards sein, die die User Stories
und deren Tasks auflisten, und somit den aktuellen Entwicklungsstand wiedergeben.
Denkbar sind auch Design- und Architekturentwürfe, in Form von UMLDiagrammen, die an den Wänden des Raums aufgehangen sind, Maskenentwürfe,
Codierrichtlinien, usw. Das Team sollte viel Wandfläche zur Verfügung gestellt
bekommen und den gemeinsamen Raum nach eigenen Vorstellungen gestalten
können.
Team
In Zeiten, in denen ein Einzelner nicht mehr alles wissen kann, können
herausragende Ergebnisse nur im Team erreicht werden. Nicht mehr Fachwissen
sondern soziale Kompetenz (Respekt, Kommunikation, etc.) ist Trumpf. Dies trägt
längerfristig besser: Fachwissen kann man lernen, fehlende Sozialkompetenz lässt sich
aber selbst in längeren Projekten nur schwer aufbauen.
Zyklische Planung
Um nicht zu weit nach vorne zu schauen und durch zu viele fehlgeleitete Annahmen
Verschwendung zu produzieren, wird der Zeitraum der vorausschauenden Planung
begrenzt. Zudem erhöhen kürzere Zyklen die Möglichkeit, schneller Feedback vom
Kunden zu bekommen.
Inkrementelles Design
Verschwendung vermeiden heißt in erster Linie nach dem aktuellen Wissensstand zu
implementieren. Dies bedeutet im Umkehrschluss, dass ich nicht die Eier-legendewoll-milch-sau definiere, sondern einen ersten Wurf hinlege, diesen schon einmal
implementiere und dann später den Entwurf gemäß der neuen Anforderungen
erweitere. Auch wenn dies ggf. zu einem Refactoring führt, bevor weiter
implementiert werden kann.
53
10-Minuten-Build
Sobald ein Entwickler seine Änderungen in das gemeinsame Repository übertragen
hat, soll er maximal 10 Minuten warten, bis das System neu gebaut worden ist und
alle automatisierten Tests durchgelaufen sind. Wenn ein Entwickler zu lange warten
muss, führt die Ungeduld dazu, das das direkte Feedback des Continuous Integration
nicht mehr berücksichtigt wird, weil es zu spät kommt.
Pufferzeit
Den Entwicklern soll Zeit zur Verfügung stehen, so dass sie sich um Dinge außerhalb
der fachlichen Umsetzung kümmern können, die das Team langfristig effizienter
machen. Die Pufferzeit kann zudem problematische Situationen „retten“ helfen.
Begleitpraktiken
Richtige Kundeneinbeziehung
Der Kunde nimmt aktiv an der Entwicklung teil. Er steht für Fragen jederzeit zur
Verfügung und kann so den Entwicklern ohne Verzögerung die zu
implementierenden Details mitteilen. Zudem gewinnt der Kunde Einblick in die
Software-Entwicklung. Die enge Kommunikation und die Transparenz schaffen eine
vertrauensvolle Umgebung in der Entscheidungen schneller getroffen und umgesetzt
werden können.
Inkrementelles Deployment
Nicht eine große Auslieferung mit hohem Risiko des Scheiterns, sondern viele kleine,
die nach und nach mehr getestete Funktionalität zur Verfügung stellen. Der Kunde
bekommt frühzeitig eine produktive Variante der endgültigen Auslieferung zu sehen
und kann den Entwicklern entsprechendes Feedback geben.
Team-Konstanz
Einzelne Mitglieder eines Teams, die sich gefunden haben und effizient
zusammenarbeiten, sollen nicht wieder aus diesem Team-Kontext herausgenommen
werden.
54
Schrumpfende Teams
Wenn aus einem Team, das leistungsfähiger und produktiver geworden ist, Mitglieder
herausgenommen werden, soll dies nicht dazu führen, dass damit auch der
Umsetzungsaufwand sinkt.
Ursachliche Analysen
Bei auftretenden Fehler wird der tatsächlichen Fehlerursache nachgegangen und nicht
versucht nachzuvollziehen, warum der Fehler auftrat.
Geteilter Code
Alle Team-Mitglieder teilen gemeinsam die Verantwortung für den gesamten Code.
Dies bedeutet, dass jeder sich verpflichtet fühlt, bei Problemen sofort selber Hand
anzulegen, also nicht darauf zu warten, dass der eigentliche Verursacher aktiv wird.
Andererseits sind alle gleichberechtigt und in der Lage jederzeit Hand an den Code
zu legen.
Codierung und Testen
Entwickler testen, was sie codiert haben. Der Test ist zentraler Bestandteil bei der
Entwicklung im Team. Es gibt keine Spezialisierung, sondern jeder Entwickler ist
befähigt und willig zu testen. Code und Tests sind die einzigen permanenten
Artefakte. Dokumentation wird z.B. aus dem Code heraus generiert. Alles andere
wird über die sozialen Beziehungen im Team abgebildet.
Eine zentrale Code-Basis
Es wird ein zentrales Repository eingesetzt, auf das alle Entwickler gleichermaßen
zugreifen.
Tägliches Deployment
Tägliches Deployment führt dazu, dass die Auslieferung des Systems zur Routine
wird. Es hilft zudem zeitnah Problem aufzudecken.
Verhandelbarer, vertraglicher Funktionsumfang
Gemäß dem magischen Dreieck des Projekt-Managements werden Termine, Kosten
und Qualität als gesetzt betrachtet, der Leistungsumfang aber als verhandelbar. Dies
deckt sich mit den Erfahrungen aus klassisch geführten Projekten. Die höchste
Kundenzufriedenheit entsteht, wenn die Qualität unangetastet bleibt und fehlende
55
Funktionalität zu einem späteren Zeitpunkt mit gleich hoher Qualität ausgeliefert
wird.
Bezahlen-pro-Nutzung
Die Entwickler werden nicht für die Auslieferung der Software bezahlt, sondern für
die Nutzung der Features, die implementiert wurden. Dies motiviert die Entwickler,
jene Features zu implementieren, die wirklich häufig gebraucht werden.
56
Software Kanban für die nachgelagerte Wartung
Auch wenn die Art, wie bei Kanban Aufgaben bearbeitet werden, ideal zur Wartung
passt, kann sich das Team schwer tun tatsächlich effizient vorzugehen. Dies kann
natürlich bei allen agilen Ansätzen passieren, wenn die Prinzipen des Agilen Manifests
nicht wirklich verinnerlicht wurden. Allerdings ist Kanban bei der Definition der
mindestens einzuhaltenden Regeln noch etwas zurückhaltender als Scrum. In noch
vorwiegend klassisch-organisierten Umgebungen kann dies dazu führen, dass zwar ein
übliches Kanban Board zum Einsatz kommt, aber dessen Umgang klassisch gepflegt
wird (z.B. ständige Unterbrechungen von außen die Regel sind). Hier ist also weit
mehr Selbstdisziplin erforderlich.
Kanban sollte deshalb erst zum Einsatz kommen, wenn die Teams genügend
Erfahrung mit dem agilen Mindset bzw. dem Scrum Framework gesammelt haben.
Generell ist zu empfehlen, dass Dailys und Retros auch in der Wartung durchgeführt
werden, um die Micro-Planung zu koordinieren und den ständigen
Selbstverbesserungsprozess auch in der Wartung zu leben. Die Retros können hierbei
besondere Erkenntnisse in die Entwicklung zurückspiegeln (z.B. Muster beim
Auftreten von Bugs, technischen Problemen oder Nicht-Einhaltung von ProjektStandards).
57
Literaturverzeichnis
[Anderson 2010]
David Anderson, Donald G. Reinertsen: Kanban, Blue
Hole Press (2010)
[Aguayo 2010]
Rafael Aguayo: Dr. Deming - e American who Taught
the Japanese About Quality, Millennia Management
Associates, Ltd. (2010)
[Beck 2001]
Kent Beck et. al.: Manifesto for Agile Software
Development (2001), agilemanifesto.org/iso/de/
[Cohn 2009]
Mike Cohn: Succeeding With Agile - Software
Development Using Scrum, Addison-Wesley Longman,
Amsterdam (2009)
[Cope 2011]
Jim Coplien: An Alternative to Kanban - One-Piece
Continuous Flow, Jeff Sutherland Blog (2011),
scrum.jeffsutherland.com/2011/11/alternative-to-kanbanone-piece.html
[DIN 2009]
Deutsches Institut für Normung e.V.: DIN
69901-2:2009-01 / Projektmanagement –
Projektmanagementsysteme – Teil 2: Prozesse,
Prozessmodell, Beuth Verlag (2009)
[Eschen 2011]
Rainer Eschen: Kommentar zu Stefan Hagen‘s „Vortrag
beim PM Camp 2011“, Stefan Hagen Blog (2011),
http://pm-blog.com/2011/11/10/vortrag_pm_camp/
comment-page-1/#comment-22541
[Gloger 2011]
Boris Gloger: Scrum - Produkte schnell und zuverlässig
entwickeln, 3. Auflage, Hanser (2011)
[Gloger 2012]
Boris Gloger: Moral hat in der Retrospektive nichts
verloren!, Boris Gloger Blog (2012), borisgloger.com/
2012/09/13/moral-hat-in-der-retrospektive-nichtsverloren/
[Hagen 2013]
“Agiles Projektmanagement” – ein Widerspruch in sich?,
Stefan Hagen Blog (2013), pm-blog.com/2013/05/30/
agiles-projektmanagement-ein-widerspruch-in-sich/
58
[Hübner 2012]
Raimo Hübner: Weltweite Analyse der
Projektmanagement Methoden, Standards und
Guidelines, Version 13 (2012), michaljanas.com/wpcontent/uploads/2012/03/2012.02.17_V.
13.0_Global_Project.Management.Standard._.Guideline.
Comparisson.pdf
[Katzenberger 2013]
Rolf F. Katzenberger: Der Scrum Guide 2013 - was gibt es
Neues?, Rolf F. Katzenberger Blog (2013),
www.pragmatic-teams.de/scrum-guide-2013-was-gibt-esneues
[Motzel 2010]
Erhard Motzel: Projektmanagement Lexikon, 2.
Auflage, WILEY-VCH (2010)
[Ohno 2013]
Taiichi Ohno: Das Toyota-Produktionssystem, Campus
Verlag (2013)
[Pichler 2010]
Roman Pichler: Agile Product Management with
Scrum, Creating Products That Customers Love,
Addison-Wesley (2010)
[PM3 2010]
Deutsche Gesellschaft für Projektmanagement:
Kompetenzbasiertes Projektmanagement (PM3) Handbuch für die Projektarbeit, Qualifizierung und
Zertifizierung auf der Basis der IPMA Competence
Baseline Version 3.0, 3. Auflage, GPM (2010)
[Poppendieck 2003]
Mary Poppendieck, Tom Poppendieck: Lean Software
Development: An Agile Toolkit, Addison-Wesley
Professional (2003)
[Raitner 2013]
Marcus Raitner: Meine Projektmanagement-Philosophie,
Marcus Raitner Blog (2013), fuehrung-erfahren.de/
2013/09/meine-projektmanagement-philosophie/
[Schulz 2011]
Marcus Schulz, Wilhelm Mikulaschek: Projekt
Management - Zielorientierte Effizienz, Eigenverlag
(2011)
[Schwaber 2012]
Ken Schwaber: What comes after Scrum?, Ken Schwaber
Blog (2012), kenschwaber.wordpress.com/2012/10/05/
what-comes-after-scrum/
[Schwaber 2012 (2)]
Ken Schwaber, Jeff Sutherland: Software in 30 Days How Agile Managers Beat the Odds, Delight eir
Customers, And Leave Competitors in the Dust, John
Wiley & Sons (2012)
59
[Sinek 2010]
Simon Sinek: Wie große Führungspersönlichkeiten zum
Handeln inspirieren, TEDX (2010), www.ted.com/talks/
simon_sinek_how_great_leaders_inspire_
action.html
[Sutherland 2013]
Jeff Sutherland, Ken Schwaber: e Scrum Guide,
www.scrumguides.org (July 2013)
[Takeuchi 1986]
Hirotaka Takeuchi, Ikujiro Nonaka: e New New
Product Development Game, Harvard Business Review
(1986), hbr.org/1986/01/the-new-new-productdevelopment-game/
[Wagner 2009]
Reinhard Wagner: DIN 69900 und DIN 69901 - Das ist
neu in den deutschen PM-Normen, projektmagazin.de
(2009), www.projektmagazin.de/artikel/das-ist-neu-dendeutschen-pm-normen_7169
60
Abkürzungsverzeichnis
bzw.
beziehungsweise
Chief-PO, CPO
Chief Product Owner
Chief-SM, CSM
Chief Scrum Master
Daily
Daily Scrum
DIN
Deutsches Institut für Normung
ggf.
gegebenenfalls
GPM
Gesellschaft für Projekt-Management
ICB
IPMA Competence Baseline
IPMA
International Project Management Association
i.W.
im Wesentlichen
PBI
Product Backlog Item
PM
Projekt-Manager
PO
Product Owner
Retro
Retrospektive
SM
Scrum Master
URL
Uniform Resource Locator
usw.
und so weiter
z.B.
zum Beispiel
61
Blue Scrum
Agiles Projekt-Management in der Software-Entwicklung - geht das?
Rainer Eschen beschreibt in Blue Scrum - Das Prozessmodell einen pragmatischen
Ansatz wie bestehende Industriestandards und Normen dazu genutzt werden können, einen hybriden Ansatz aus
agilen und klassischen Projekt-Management-Elementen so zu kombinieren, dass diese Frage bejaht werden kann.
Hierbei werden agile Ansätze im Sinne eines umfassenden Projekt-Managements vervollständigt bzw. klassische
Ansätze auf das Fundament eines agilen Mindsets gestellt.
Das Blue Scrum Prozessmodell besteht aus drei Säulen:
Das agile Wertesystem
Zeitgemäßes Projekt-Management kann nicht länger auf klassischen Denkmustern aufsetzen, wenn der
Geschäftswert des Kunden, Qualität, Effektivität und Effizienz nachhaltig verfolgt werden sollen. Die Prinzipen
des Agilen Manifests definieren die Basis.
Die agilen Werkzeuge
Agile Werte benötigen agiles Vorgehen. Basis hierbei ist die vollständige Etablierung des Scrum Frameworks. Mit
Hilfe weiterer agiler Werkzeuge entsteht letztendlich ein vollständiger Software-Entwicklungsprozess.
Das agile Projekt-Management
Um größere Projekt-Kontexte verwalten zu können, werden Elemente des klassischen Projekt-Managements im
agilen Sinne wiederverwendet und adaptiert.
Die Ausarbeitungen der Blue Scrum Buchreihe können als Blaupause für eigene Projekte genutzt werden. Sie
werden im Rahmen der Diskussion mit der (agilen) Projekt-Management-Community kontinuierlich
weiterentwickelt und verbessert. Diskutieren Sie mit unter blog.rainwebs.net/blue-scrum-prozessmodell
In der Blue Scrum Buchreihe sind außerdem geplant:
Blue Scrum - Das Team
Best Practices bei der Umsetzung des Prozessmodells in der täglichen Praxis
Blue Scrum - Die Organisation
Change Management Praktiken für die langfristige Etablierung des Prozessmodells im Unternehmen
Blue Scrum - Der klassische Kunde
Adaption in die klassische Projekt-Management-Welt − als sanfter Übergang für die langfristige Etablierung des
Prozessmodells auf der Kundenseite
Rainer Eschen ist Diplom-Informatiker (FH), zertifizierter Professional Scrum Master I
(scrum.org), zertifizierter Projektmanagement-Fachmann (GPM) und arbeitet als agiler Coach
im IT-Projekt-Management. Ein Schwerpunkt seiner Tätigkeit ist die Entwicklung eines
vollständig auf agilen Grundsätzen aufbauenden Projekt-Management-Ansatzes, in dessen
Zentrum das Scrum Framework steht. Rainer ist erreichbar unter blog.rainwebs.net
62

Blue Scrum Prozessmodell

Transcription

Similar documents

Presseheft - Neue Visionen Filmverleih

Überfachliche Kompetenzanforderungen in den

The Scrum Guide

Diesen Katalog als PDF herunterladen - AL-KO

C / C++ - TU Ilmenau

Konzepte für eine IT-Security von morgen

Anforderungsmuster im Requirements Engineering

Magazin herunterladen

Softwaretechnik ¨Uberblick I - Informatik - FB3

Verhaltenskodex

Stromversorgung mit System

National Competence Baseline NCB 3.0

PDF

Interne Revision

prince2®, pmi®, ipma