Transcript
Page 1: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Blue Scrum Das Prozessmodell

V 0.1 / 30.09.2013

Damit Software-Entwicklung richtig Spaß macht!

Dipl.-Inform. (FH) Rainer Eschen

Wir brauchen Ihre Ideen für das nächsteUpdate dieses Buchs. Diskutieren Sie mit unterblog.rainwebs.net/blue-scrum-prozessmodell

Page 2: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Rainer Eschen

blog.rainwebs.netgoogle.com/pro!les/rainwebstwitter.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), zerti!zierter Professional Scrum Master I (scrum.org), zerti!zierter 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, Software-Architekt, 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

Page 3: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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

Page 4: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

....................................................................................................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 Blue Scrum Das Prozessmodell

Page 5: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 Software-Entwicklung vor: Die Blue Scrum Buchreihe.

Blue Scrum de!niert ein auf agilen Grundsätzen aufsetzendes Projekt-Management für Software-Entwicklungs-Projekte ab drei Scrum Teams. Im Mittelpunkt der De!nition 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 de!nieren.

Die Ausarbeitungen dieser Buchreihe sind als Work-in-Progress zu verstehen. Sie versuchen Ansätze aus verschiedenen agilen bzw. klassischen Projekt-Management-Ideen 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 de!nieren. 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) Projekt-Management-Community kontinuierlich ein#ieß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 de!niert, wie ein Apple Produkt erstellt wird. Mit dem Warum und mit dem Wie identi!ziert sich der Kunde letztendlich. Beide bestimmen, ob der Kunde das

Blue Scrum Das Prozessmodell 5

Page 6: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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, ...).

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 !nden 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 Blue Scrum Das Prozessmodell

Was?Wie?Warum?

Page 7: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 emp!nden 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 de!niert 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 !nden Sie unter blog.rainwebs.net/blue-scrum.

Rainer Eschen (rainwebs), September 2013

Blue Scrum Das Prozessmodell 7

Page 8: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Ü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 !nden 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 Projekt-Management - 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 #ä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 Er!nder, sollte also immer auch über

8 Blue Scrum Das Prozessmodell

Page 9: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 de!niert 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 Projekt-Management.

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.

Blue Scrum Das Prozessmodell 9

Page 10: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 de!nierten Projekt-Management-Prozesse und der ICB 3.0 Elemente in agilen Umgebungen

• Das Blue Scrum Vorgehensmodell - Die Ausgestaltung der agilen Software-Entwicklung im Detail

10 Blue Scrum Das Prozessmodell

Page 11: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 WertesystemEntscheidend 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 de!nieren, 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 Durchhaltever-mögen mitbringen. Wir werden uns im Buch Blue Scrum - Die Organisation noch ausführlich mit dem dafür notwendigen Change Management auseinandersetzen.

DIN����������� ������������������  69901-2

XP����������� ������������������  Practices

Lean����������� ������������������  Software

Scrum����������� ������������������  Framework

ICB����������� ������������������  3.0

FDD Kanban

Agiles����������� ������������������  Manifest

Scrum

Das����������� ������������������  agile����������� ������������������  Projekt-Management

Die����������� ������������������  agilenWerkzeuge

Das����������� ������������������  agile����������� ������������������  Wertesystem

XP

Blue Scrum Das Prozessmodell 11

Page 12: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Das Agile ManifestsDas 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 PlansDie 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 de!nieren 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 Informationsaus-tausches.

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 Schie#age 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 Blue Scrum Das Prozessmodell

Page 13: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 !nden. Dann braucht es auch keine komplizierten Verträge, die künstlich Vertrauen über Paragraphen in das Projekt hinein de!nieren.

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 DevelopmentsFü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

Blue Scrum Das Prozessmodell 13

Page 14: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• 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 Toyota-Produktionssystem. 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 herauszu!nden, was der Anwender tatsächlich meint, wenn er Aussagen trifft (beispielsweise im Rahmen von iterativer, prototypischer Implementierung von Benutzerober#ächen).

So spät wie möglich entscheiden

Je genauer ich de!nieren 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 de!niert ist, die sich später als unzureichend erweisen könnten.

14 Blue Scrum Das Prozessmodell

Page 15: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 iterativ-inkrementellen 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.

Blue Scrum Das Prozessmodell 15

Page 16: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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-zu-Angesicht zu kommunizieren und sich nicht auf Dokumente zu verlassen.

Scrum GrundwerteIm 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 Blue Scrum Das Prozessmodell

Page 17: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 re#ektieren 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äu!g 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 Ein#uss 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 de!niert 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.

Blue Scrum Das Prozessmodell 17

Page 18: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 Entwickler-Team 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 Blue Scrum Das Prozessmodell

Page 19: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Zentrale Werte des Extreme ProgrammingsDie 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, !ndet 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 !ndet eine Erweiterung oder ein entsprechendes Refactoring statt.

Rückmeldung (Feedback)

Dieser Aspekt ist Teil der intensiven Kommunikation und betrachtet die Kontexte:

• SystemUnit 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.

Blue Scrum Das Prozessmodell 19

Page 20: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• KundeAkzeptanz-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.

• TeamDas 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 WerkzeugeAgile 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 Blue Scrum Das Prozessmodell

Page 21: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Scrum FrameworkDas 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 de!niert 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 De!nition und Erstellung des Produkts im Sinne der Anwender.

Extreme Programming Engineering PracticesKent 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 de!niert 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 de!nieren.

Feature Driven DevelopmentJeff DeLuca und Peter Coad haben mit ihrem Feature Driven Development (FDD) eine spezielle Sichtweise für die De!nition 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 de!niert. 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

Blue Scrum Das Prozessmodell 21

Page 22: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 potentiell-auslieferbaren Inkrements am Sprint Ende.

Kanban für Software-EntwicklungDavid Anderson hat mit seiner speziellen Interpretation [Anderson 2010] des im Toyota-Produktionssystems de!nierten Kanban (siehe hierzu auch [Cope 2011]) einen agilen Ansatz de!niert, 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 de!niert 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 de!niert werden, die dafür sorgen, dass bereits in Arbeit be!ndliche Aufgaben zu Ende gebracht werden, bevor neue angefangen werden dürfen.

Das agile Projekt-ManagementIn der (agilen) Projekt-Management-Community wird das ema Projekt-Management 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 Uni!ed 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 Projekt-Management-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 Blue Scrum Das Prozessmodell

Page 23: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Die meisten agilen Prozessbeschreibungen vernachlässigen das Initiieren und Beschließen von Projekten, das Staffing, oder auch das Stakeholder- und Risiko-Management 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 Kon#ikten. 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-2Die 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 de!niert 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.0Zentraler 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 Projekt-Management-Phasen der DIN orientieren, schon weil sie Bestandteil der ICB geworden sind. Wir werden aber zusätzlich auch die anderen Kompetenzfelder

Blue Scrum Das Prozessmodell 23

Page 24: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

(Anforderungen an das persönliche Verhalten, Umgang mit dem Projekt-Kontext) verstärkt betrachten.

ZusammenfassungDas Blue Scrum Prozessmodell ist ein hybrider Ansatz, der aufbauend auf Industriestandards und Normen agile Ansätze im Sinne eines umfassenden Projekt-Managements 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 Projekt-Management-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 Blue Scrum Das Prozessmodell

Page 25: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 De!nition eines umfassenden agilen Projekt-Management-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-2Das 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 Prozess-Untergruppen ableiten:

• Ablauf und TermineSachlogische Reihenfolge und vorläu!ge Projektdauer

• ÄnderungenBewerten, Genehmigen und Durchführen von Änderungen gegenüber der ursprünglichen Beauftragung

Blue Scrum Das Prozessmodell 25

Page 26: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• Information/Dokumentation/KommunikationArchivierung und Recherche von wichtigen Informationen, Publikationen, Protokollen, Entscheidungen und Änderungen

• Kosten und FinanzenVerteilung von Kosten und Managen von Budget

• OrganisationDe!nition von Rollen, Verantwortlichkeiten, Befugnissen, Aufgaben, Kommunikation, Schnittstellen und Infrastruktur

• QualitätÜbereinstimmung von Kundenanforderungen und erbrachter Leistung

• RessourcenEinsatzmittel, Sachmittel, Personal und Informationen

• RisikoAnalyse und Maßnahmen zur Bewältigung

• ProjektstrukturGra!sche Darstellung der Projektaufgaben mit Hilfe von Arbeitseinheiten und Arbeitspaketen

• Verträge und NachforderungenRechte und P#ichten zwischen Auftraggeber und Auftragnehmer und Durchsetzung von Ansprüchen

• ZieleZiel!ndung, Analyse, Koordination und Selektion von Zielen

Für die Prozess-Gruppe „Projekt-Management-Prozesse“ lassen sich folgende Projekt-Management-Phasen ableiten, die sowohl für das Einzelprojekt-Management als auch das Multi-Projekt-Management (Programme, Portfolios) gelten:

• InitialisierungAnalysieren und Bewerten der vorliegenden Projektidee, Skizzieren einer Projektvision, relevante Prozesse auswählen und vorbereiten für die Projektabwicklung, Management-Freigabe vorbereitenErgebnisse: Benennung von Projekt-Manager + Initial-Team, Skizze der Projekt-Ziele, Liste ausgewählter PM-Prozesse, Auftrag für die nächste Phase

• De!nitionNach erteilter Freigabe: Kernteam bilden, SMARTe Ziele de!nieren, konkrete Projektinhalte festlegen, wesentliche Meilensteine de!nieren, grobe Aufwandsschätzung erstellen, Umfeld- und Stakeholder-Analyse durchführen, Machbarkeit prüfen, Ableiten kritischer Erfolgsfaktoren, Management-Freigabe vorbereitenErgebnisse: Benennung Projekt-Kern-Team, Projekt-Ziele, Machbarkeitsbewer- tung, Meilensteinplan, Aufwandsschätzung, grober Projekt-Struk-

26 Blue Scrum Das Prozessmodell

Page 27: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Blue Scrum Das Prozessmodell 27

Proj

ekt-

Man

agem

ent-

Proz

esse

(Pro

zess

-Unt

ergr

uppe

n)

Ablauf, Termine

Änderungen

InformationDokumentation Kommunikation

KostenFinanzen

Organisation

Qualität

Ressourcen

Risiko

Projektstruktur

VerträgeNachforderungen

Ziele

Projekt-Phasen (projektspezi!sch, iterativ)

...

Projekt-Management-Phasen

Meilensteine de!nieren

Vorgänge planenTerminplan erstellenProjekt-Plan erstellen

Vorgänge anstossenTermine steuern

Umgang mit Änderungen planen

Änderungen steuern

Information, Kommunikation, Berichtswesen und Dokumenta-tion planenFreigabe erteilen

Information, Kommunikation, Berichtswesen und Dokumenta-tion steuernAbnahme erteilen

Projekt-Ab-schlussbericht erstellenProjekt-Doku-mentation archivieren

Initialisierung De!nition Planung Steuerung Abschluss

Freigabe erteilen Information, Kommunikation und Berichtswe-sen festlegenProjekt-Marke-ting de!nierenFreigabe erteilen

Aufwände grob schätzen

Kosten- und Finanzmielplan erstellen

Kosten und Fi-nanzmiel steu-ern

Nachkalkulation erstellen

Zuständigkeiten klärenPM-Prozesse auswählen

Projekt-Kernteam bilden

Projekt-Organisation planen

Kick-off durchführenProjekt-Team bildenProjekt-Team entwickeln

Abschlussbe-sprechung durchführenLeistungen würdigenProjekt-Organisa-tion au$ösen

Erfolgskriterien de!nieren

Qualitätssiche-rung planen

Qualität sichern Projekt-Erfahrung sichern

Ressourcenplan erstellen

Ressourcen steuern

Ressourcen rückführen

Risiken analysie-renGegenmaßnah-men zu Risiken planen

Risiken steuernUmgang mit Risiken festlegenProjekt-Umfeld / Stakeholder analysierenMachbarkeit bewerten

Projekt-Struktur-Plan erstellenArbeitspakete beschreibenVorgänge beschreiben

Grobstruktur erstellen

Vertragsinhalte mit Lieferanten festlegen

Verträge mit Kunden und Lieferanten abwickelnNachforderungen stellen

Verträge beendenUmgang mit Verträgen de!nierenVertragsinhalte mit Kunden festlegen

Zielerreichung steuern

Ziele skizzieren Ziele de!nierenProjekt-Inhalte abgrenzen

Page 28: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

tur-Plan, Regelungen für Information und Kommunikation, Vertragsentwurf, Regelungen für Risiko-Management, Freigabe für nächste Phase

• PlanungNach erteilter Freigabe: Festlegen, was, wann, wie, und durch wen gemacht werden soll; Projekt-Strukturplan mit Arbeitspaketen erstellen; Vorgänge de!nieren; Termine, Ressourcen und Kosten planen; Vertragsinhalte mit Lieferanten abstimmen; Freigabe durch den Auftraggeber vorbereitenErgebnisse: Projekt-Pläne (Projekt-Struktur, Termine, Kosten, Ressourcen, Finanzierung), Risikoliste und Risikomaßnahmen, Änderungs- Management-Verfahren, Business-Plan, Projekt-Organisation incl. Rollenbeschreibung, Qualitäts-Management, Freigabe für die nächste Phase

• SteuerungNach 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 vorlegenErgebnisse: Projekt-Berichte, Abnahmeprotokolle, Entschiedene Änderungsan- träge, Nachforderungen, Dokumentationen

• AbschlussNach Abnahme: Aufbereiten des gesamten Projekts, Nachkalkulation, Durchführung Abschlussbesprechung, Abschlussbericht erstellen, Archivierung wichtiger Unterlagen, Erfahrungssicherung als Input für zukünftige ProjekteErgebnisse: Abschlussbericht, archivierte Projekt-Dokumentation, dokumentierte Projekt-Erfahrungen, Nachkalkulation, beendete Verträge

Agiles Projekt-ManagementAgiles Projekt-Management de!niert, 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-Prozess-Untergruppen

Eine agile Betrachtung der Prozess-Untergruppen ergibt:

28 Blue Scrum Das Prozessmodell

Page 29: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Blue Scrum Das Prozessmodell 29

Proj

ekt-

Man

agem

ent-

Proz

esse

(Pro

zess

-Unt

ergr

uppe

n)

Ablauf, Termine

InformationDokumentation Kommunikation

KostenFinanzen

Organisation

Qualität

Ressourcen

Risiko

VerträgeNachforderungen

Ziele

Projekt-Phasen (projektspezi!sch, iterativ)

Product Backlog Grooming

Sprint Planning

Sprint Sprint Retrospektive

Sprint Review

Projekt-Management-Phasen

Product Backlog erstellenRelease Planung erstellen

Product Backlog p!egenSprint PlanningProduct Backlog GroomingEstimation Meeting

SprintDaily Scrum

Information, Kommunikation, Berichtswesen und Dokumenta-tion planen

Information, Kommunikation, Berichtswesen und Dokumenta-tion steuernSprint Review

Projekt-Ab-schlussbericht erstellenProjekt-Doku-mentation archivieren

Initialisierung De!nition Planung Steuerung Abschluss

Freigabe erteilen Information, Kommunikation und Berichtswe-sen festlegenProjekt-Marke-ting de!nieren

Aufwände grob schätzen

Kosten- und Finanzmielplan erstellen

Kosten und Fi-nanzmiel steu-ern

Nachkalkulation erstellen

Zuständigkeiten klärenPM-Prozesse auswählen

Projekt-Kernteam bilden

Projekt-Organisation planen

Kick-off durchführenProjekt-Team bildenProjekt-Team entwickeln

Abschlussbe-sprechung durchführenLeistungen würdigenProjekt-Organisa-tion au$ösen

Akzeptanzkrite-rien für Product Backlog Items

Sprint ReviewSprint Retrospektive

Projekt-Erfahrung sichern

Ressourcenplan erstellen

Ressourcen steuern

Ressourcen rückführen

Risiken analysie-renGegenmaßnah-men zu Risiken planen

Risiken steuernImpediments Backlog p$egenImpediments beseitigen

Umgang und Risiken festlegenProjekt-Umfeld / Stakeholder analysieren

Vertragsinhalte mit Lieferanten festlegen

Verträge mit Kunden und Lieferanten abwickeln

Verträge beendenUmgang mit Verträgen de!nierenVertragsinhalte mit Kunden festlegen

Sprint Goal de"nieren

Vision skizzieren Vision de"nieren

Estimation Meeting

Ersetzung bzw. Ergänzung Anpassung

Page 30: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• Ablauf und TermineWir 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.

• ÄnderungenEin Ä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/KommunikationEs wird nur das festgehalten, was absolut notwendig ist für die Erstellung des Codes. Die Spezi!kation 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 FinanzenDie Kosten leiten sich nicht von einem fest vorgegebenen Umfang ab, sondern der mögliche Umfang vom zur Verfügung stehenden Budget bzw. Zeitrahmen.

• OrganisationWesentlich hierbei ist ein gut vorbereitetes Umfeld für ein effizientes und effektives agiles Arbeiten.

• QualitätDas Scrum Framework de!niert bereits wesentliche Aspekte. Das Entwickler-Team braucht hier ebenfalls ein Umfeld, um die best mögliche Qualität zu erreichen.

• RessourcenWesentlicher Punkt ist die Planung für stabile Teams über eine lange Laufzeit. Mindestens für die Länge eines Sprints darf die Zusammensetzung der Entwickler-Teams nicht verändert werden.

• RisikoDie 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.

• ProjektstrukturDa wir nicht langfristig planen, wird dieses ema nicht mehr benötigt. Für die kurzfristige Planung de!niert das Scrum Framework alles notwendige.

• Verträge und NachforderungenDie Vertragsausarbeitungen basieren auf gegenseitigem Vertrauen und regeln das absolut notwendigste. Der de!nierte Rahmen muss genügend Spielraum für kurzfristige Änderungen zulassen, die in der laufenden Umsetzung zum Tragen

30 Blue Scrum Das Prozessmodell

Page 31: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

kommen. Da wir kein Änderungsmanagement mehr brauchen, wird die Betrachtung von Nachforderungen obsolete. Bei vorab de!niertem 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 de!niert werden kann.

• ZieleEine direkte Steuerung ist nicht mehr notwendig, da über die Sprint Goals dies bereits iterativ im Scrum Framework verankert ist.

Agile Projekt-Management-ProzesseFü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 (De!nition)

• Freigabe erteilen (Planung)

• PM-Prozess-Untergruppe „Qualität“

• Erfolgskriterien de!nieren

• PM-Prozess-Untergruppe „Risiko“

Blue Scrum Das Prozessmodell 31

Page 32: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• 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 de!nieren

• Projektinhalte abgrenzen

• Zielerreichung steuern

Anzupassende Prozesse

Agil zu erweiternde bzw. anzupassende Prozesse sind:

• PM-Prozess-Untergruppe „Ablauf und Termine“

• Meilensteine de!nierenDas 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 de!niert 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/steuernInformation: Informationen werden zum großen Teil mündlich und formal über durch das Scrum Framework de!nierte Meetings weitergegeben. Kommunikation: Das Scrum Framework legt mit seinen Meetings und Artefakten alles notwendige fest, damit eine zielführende Kommunikation statt!ndet.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 Blue Scrum Das Prozessmodell

Page 33: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• Abnahme erteilenAbnahmen von Inkrementen werden iterativ über die jeweils am Ende eines Sprints statt!ndenden 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 planenDer Product Owner de!niert Akzeptanzkriterien für Product Backlog Items im Rahmen der Sprint Planung. Das Scrum Team de!niert die Kriterien einer De!nition of Done.

• Qualität sichernDie Einhaltung der Akzeptanzkriterien und der De!nition 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 steuernWesentlich 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 steuernNeben der Überwachung der bewerteten Risiken aus der Risikoliste wird der Impediments Backlog vom Scrum Master gep#egt, priorisiert und abgearbeitet.

Agile Projekt-Management-PhasenDurch die Anpassung der Projekt-Management-Prozesse ergeben sich für die Projekt-Management-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 de!niert). Zusammen mit dem Chief Scrum Master wählt er die relevanten Projekt-Management-Prozesse aus. Das Ergebnis wird dem Management zur Freigabe vorgelegt.

Blue Scrum Das Prozessmodell 33

Page 34: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 de!nieren zusammen:

• Die Vision

• Erste Inhalte (Epics) und eine erste Priorisierung des Product Backlogs

• Erste Release Termine und ein Release Burn Down ChartAuch wenn die inhaltliche Betrachtung noch grob ist, kann das initiale Entwickler-Team zusammen mit dem Chief Product Owner Backlog Groomings und Estimation Meetings durchführen, um Story Points für die Epics zu de!nieren. Die zugrunde gelegte Velocity basiert dabei auf Erfahrungen aus vorangegangenen Projekten oder wird geschätzt.

Der Chief Scrum Master de!niert, wie der Entwicklungsprozess aussehen wird. Zusammen mit dem agilen Architekten, dem agilen Test-Manager und dem agilen Build-Manager de!niert er anhand eines groben Architektur-Entwurfs und der identi!zierten nicht-funktionalen Anforderungen, mit welchen Entwicklungs-werkzeugen 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, Test-Umgebung, 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 Test-Manager und agilen Build-Manager sowie dem Chief Scrum Master bei der Umsetzung der Aufgaben und in Vorbereitung der nachfolgenden Entwicklungs-Sprints gecoacht werden.

Der agile Projekt-Manager kümmert sich um die Analyse der Umfeldein#üsse, die Erwartungen relevanter Interessengruppen und betrachtet die Risiken. Zudem de!niert 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 !nalen Entwicklungs- umgebung, Regelungen für Risiko-Management, Vertrag

34 Blue Scrum Das Prozessmodell

Page 35: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 (de!nierte 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

Blue Scrum Das Prozessmodell 35

Page 36: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

IPMA Competence Baseline 3.0Die 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, Selbstre#exion

• 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 de!nierten Prozess-Gruppen.

PM-technische Kompetenz

Die Elemente der PM-technischen Kompetenz sind:

• Projekt-Management-ErfolgEffektiver und effizienter Einsatz von Methoden zur Steigerung des wirtschaftlichen Erfolgs und der Stakeholder-Zufriedenheit (Einhaltung de!nierter Ziele)

• Interessierte ParteienAnalyse und Management von Projektumfeld und Stakeholdern

• Projektanforderungen und ProjektzieleZiel!ndung, Analyse, Koordination und Selektion von Zielen

• Risiken und ChancenAnalyse und Maßnahmen zur Bewältigung von Risiken; Erkennen und Nutzen von ungeplanten Möglichkeiten

• QualitätÜbereinstimmung von Kundenanforderungen und erbrachter Leistung

• ProjektorganisationDe!nition von Rollen, Verantwortlichkeiten, Befugnissen, Aufgaben, Kommunikation, Schnittstellen und Infrastruktur

36 Blue Scrum Das Prozessmodell

Page 37: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• TeamarbeitTeam-Bildung, informelle Rollen, Kommunikation, Mitarbeiter befähigen

• ProblemlösungUrsache !nden, Lösung erarbeiten und umsetzen

• ProjektstrukturenGra!sche Darstellung der Projektaufgaben mit Hilfe von Arbeitseinheiten und Arbeitspaketen

• Leistungsumfang und LieferobjekteProjekt- und Produktinhalt, Festhalten in Lastenheft, P#ichtenheft, Projektsteckbrief

• Projektphasen, Ablauf und TermineProjekt-Management- und Projekt-Phasen, Vorgehensmodell, Aktivitäten, Meilensteine, Fortschrittsmessung

• RessourcenEinsatzmittel, Sachmittel, Personal und Informationen

• Kosten und FinanzmittelVerteilung von Kosten und Managen von Budget

• Beschaffung und VerträgeBedarfsermittlung und Lieferantensuche, Rechte und P#ichten zwischen Auftraggeber und Auftragnehmer

• ÄnderungenBewerten, Genehmigen und Durchführen von Änderungen gegenüber der ursprünglichen Beauftragung

• Überwachung und Steuerung, BerichtswesenProjektfortschritt, Controlling, Steuerungsmaßnahmen

• Information und DokumentationArchivierung und Recherche von wichtigen Informationen, Publikationen, Protokollen, Entscheidungen und Änderungen

• KommunikationAkzeptanz für das Projekt gewinnen, Eigenmotivation bei Mitarbeitern fördern

• StartProjekt vorbereiten

• AbschlussProduktabnahme, 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:

Blue Scrum Das Prozessmodell 37

Page 38: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• Führung

• Engagement und Motivation

• Selbststeuerung

• Durchsetzungsvermögen

• Entspannung und Stressbewältigung

• Offenheit

• Kreativität

• Ergebnisorientierung

• Effizienz

• Beratung

• Verhandlungen

• Kon#ikte 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 Blue Scrum Das Prozessmodell

Page 39: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Mapping zwischen DIN 69901-2 und ICB 3.0Nachfolgend die Zuordnung der ICB-Kompetenzelemente zu den Projekt-Management-Phasen der DIN 69901-2 [Schulz 2011]:

DIN Phase ICB KompetenzelementeInitialisierung 1.00 Projekt, Projekt-Management, Projekt-Arten, Projekt-

Management-Prozesse

3.01 Projekt-Orientierung

De!nition 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

Blue Scrum Das Prozessmodell 39

Page 40: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Steuerung 1.16 Projekt-Controlling: Überwachung, Steuerung, Berichtswesen

1.17 Information, Dokumentation

1.15 Kon!guration, Änderungen

1.14 Vertragliche Aspekte der Projektarbeit

2.11 Verhandlungen

2.12 Kon#ikte, Krisen

2.15 Ethik

Abschluss 1.20 Projekt-Abschluss

Nachfolgend die Zuordnung der ICB-Kompetenzelemente zu den Projekt-Management-Prozessen der DIN 69901-2 [PM3 2010]:

ICB Kompetenzelement DIN Typ DIN Projekt-Management-Prozess

1.01 Projekt-Management-Erfolg

--- ---

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 Blue Scrum Das Prozessmodell

Page 41: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 Kon!guration 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 KompetenzDer De!nition 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 „Kon!guration und Änderungen“

• Element „Projekt-Strukturen“

Anzupassende Elemente

Agil zu erweiternde bzw. anzupassende Elemente sind:

Blue Scrum Das Prozessmodell 41

Page 42: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• 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, De!nition 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 Ein#ü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 Projekt-Verlauf 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 de!niert, das die Richtung im Sprint vorgibt. Dieses steht immer im Einklang mit der Projekt-Vision.

42 Blue Scrum Das Prozessmodell

Page 43: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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.

AnforderungsbeschreibungenEin 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”.

ImplementierungDer 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

Blue Scrum Das Prozessmodell 43

Page 44: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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.

IntegrationstestBei 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 De!zit muss dann mühselig im Integrationstest wieder ausgebügelt werden.

Von der Anforderung zur ImplementierungEin 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 EntwicklungsrahmenWir schauen uns zunächst wichtige Details des Scrum Frameworks an und de!nieren dann zusätzliche Rollen und Meetings, um ein umfassendes agiles Projekt-Management für größere Projekte etablieren zu können.

44 Blue Scrum Das Prozessmodell

Page 45: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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

• De!nition 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• ManagementBasierend 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:

Blue Scrum Das Prozessmodell 45

Page 46: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• 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-Team-Kontext zu unterstützen:

• Scrum of Scrums

• Product Owner Runde

• Scrum Master Runde

• Backlog Grooming

• Estimation Meeting

MeetingsDeming‘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 statt!nden:

• 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) - Re#exion des Sprints und Erarbeitung von Verbesserungsmaßnahmen zur Umsetzung im nächsten Sprint

RollenEin 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 Blue Scrum Das Prozessmodell

Page 47: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

• 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 au#öst und auch für die Weiterentwicklung des Entwicklungsprozesses zuständig ist

ArtefakteGewisse 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 p#egt. 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 De!nition of Done erfüllt.

• De!nition of Done - Regeln, die de!nieren, wann ein Product Backlog Item oder ein Inkrement als „fertig implementiert“ zu bezeichnen sind (incl. aller Qualitätsanforderungen)

CustomerDer Customer beauftragt und !nanziert das Produkt, um seine User zufrieden zu stellen.

UserDie User verwenden das vom Customer beauftragte Produkt letztendlich. Sie sind die eigentlichen Fachleute der Fachlichkeit.

ManagementDas 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.

Blue Scrum Das Prozessmodell 47

Page 48: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Agiler Projekt-ManagerIn der agilen Community wird immer noch diskutiert, ob es eine Rolle Projekt-Manager 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, Micro-Management; 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 (Projekt-Lebenszyklus; 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 Blue Scrum Das Prozessmodell

Page 49: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 ArchitektEinen 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-ManagerDas 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 Entwickler-Teams, 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-ManagerDer 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 OwnerDer Chief Product Owner (Chief-PO) ist eine Rolle, die in größeren Projekt-Kontexten 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.

Blue Scrum Das Prozessmodell 49

Page 50: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 Projekt-Kontexten für alle prozessualen Belange einsetzbar. Er ist letzte Instanz bei prozessualen Entscheidungen, treibt team-übergreifende prozessuale Optimierungen und priorisiert die Beseitigung von Impediments.

HerausforderungenDas 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 Blue Scrum Das Prozessmodell

Page 51: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 zusammen!ndet, desto besser. Wenn sich alle in einem Raum be!nden 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.

Blue Scrum Das Prozessmodell 51

Page 52: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Pair-Programming

„Doppelter Aufwand für die gleiche Tätigkeit?“ würde ein klassischer Projekt-Manager 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 statt!nden, 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 Blue Scrum Das Prozessmodell

Page 53: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 au#isten, und somit den aktuellen Entwicklungsstand wiedergeben. Denkbar sind auch Design- und Architekturentwürfe, in Form von UML-Diagrammen, die an den Wänden des Raums aufgehangen sind, Maskenentwürfe, Codierrichtlinien, usw. Das Team sollte viel Wand#ä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-legende-woll-milch-sau de!niere, 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.

Blue Scrum Das Prozessmodell 53

Page 54: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 Blue Scrum Das Prozessmodell

Page 55: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 verp#ichtet 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

Blue Scrum Das Prozessmodell 55

Page 56: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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äu!g gebraucht werden.

56 Blue Scrum Das Prozessmodell

Page 57: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

Software Kanban für die nachgelagerte WartungAuch 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 De!nition 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 gep#egt 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 Projekt-Standards).

Blue Scrum Das Prozessmodell 57

Page 58: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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-kanban-one-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-nichts-verloren/

[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 Blue Scrum Das Prozessmodell

Page 59: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

[Hübner 2012] Raimo Hübner: Weltweite Analyse der Projektmanagement Methoden, Standards und Guidelines, Version 13 (2012),  michaljanas.com/wp-content/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-es-neues

[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, Quali!zierung und Zerti!zierung auf der Basis der IPMA Competence Baseline Version 3.0, 3. Au#age, 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)

Blue Scrum Das Prozessmodell 59

Page 60: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

[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-product-development-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-den-deutschen-pm-normen_7169

60 Blue Scrum Das Prozessmodell

Page 61: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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

Blue Scrum Das Prozessmodell 61

Page 62: Blue Scrum Prozessmodell - BLUE SCRUM – Mit Freude ...blog.rainwebs.net/wp-content/uploads/blue-scrum/blue-scrum-prozes… · Blue Scrum Das Prozessmodell V 0.1 / 30.09.2013 Damit

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 WertesystemZeitgemäß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 de!nieren die Basis.

Die agilen WerkzeugeAgile 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-ManagementUm 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 TeamBest Practices bei der Umsetzung des Prozessmodells in der täglichen Praxis

Blue Scrum - Die OrganisationChange 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

62 Blue Scrum Das Prozessmodell

Rainer Eschen ist Diplom-Informatiker (FH), zerti!zierter Professional Scrum Master I (scrum.org), zerti!zierter 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

Blue Scrum


Recommended