blue scrum prozessmodell - blue scrum – mit freude...

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

http://blog.rainwebs.net/blue-scrum-prozessmodell/http://blog.rainwebs.net/blue-scrum-prozessmodell/

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

http://blog.rainwebs.net/http://blog.rainwebs.net/http://google.com/profiles/rainwebs/http://google.com/profiles/rainwebs/http://twitter.com/rainwebs/http://twitter.com/rainwebs/http://www.packtpub.com/icefaces-18-next-generation-enterprise-web-development/bookhttp://www.packtpub.com/icefaces-18-next-generation-enterprise-web-development/bookhttp://www.packtpub.com/icefaces-18-next-generation-enterprise-web-development/bookhttp://www.packtpub.com/icefaces-18-next-generation-enterprise-web-development/bookhttp://blog.rainwebs.net/blue-scrum-prozessmodell/http://blog.rainwebs.net/blue-scrum-prozessmodell/

Inhaltsverzeichnis

.....................................................................................Die Blue Scrum Buchreihe 5...................................................................................................Über dieses Buch 8

..............................................................................Das Blue Scrum Prozessmodell 11.....................................................................................Das agile Wertesystem 11

...............................................................................Das Agile Manifests 12..........................................Prinzipien des Lean Software Developments 13

................................................................................Scrum Grundwerte 16...........................................Zentrale Werte des Extreme Programmings 19

......................................................................................Die agilen Werkzeuge 20.................................................................................Scrum Framework 21

.........................................Extreme Programming Engineering Practices 21.................................................................Feature Driven Development 21

.........................................................Kanban für Software-Entwicklung 22........................................................................Das agile Projekt-Management 22

........................................................................................DIN 69901-2 23..........................................................IPMA Compentence Baseline 3.0 23

...........................................................................................Zusammenfassung 24..........................................................................Der Blue Scrum Projekt-Rahmen 25

..................................................................................................DIN 69901-2 25.............................................................................Agiles Projekt-Management 28

..........................................Agile Projekt-Management-Prozess-Untergruppen 28................................................................Agile Projekt-Management-Prozesse 31

..................................................................Agile Projekt-Management-Phasen 33......................................................................IPMA Competence Baseline 3.0 36

...............................................Mapping zwischen DIN 69901-2 und ICB 3.0 39.............................................Agile Elemente der PM-technischen Kompetenz 41

.........................................................................Das Blue Scrum Vorgehensmodell 43...........................................Das Feature als fachliche Erweiterung des Systems 43

.................................................................Anforderungsbeschreibungen 43...................................................................................Implementierung 43

......................................................................................Integrationstest 44...........................................Von der Anforderung zur Implementierung 44

.............................................Das Scrum Framework als Entwicklungsrahmen 44................................................................................................Meetings 46

Blue Scrum Das Prozessmodell iii

....................................................................................................Rollen 46................................................................................................Artefakte 47...............................................................................................Customer 47

.......................................................................................................User 47..........................................................................................Management 47

..........................................................................Agiler Projekt-Manager 48.....................................................................................Agiler Architekt 49

...............................................................................Agiler Test-Manager 49............................................................................Agiler Build-Manager 49............................................................................Chief Product Owner 49

...............................................................................Chief Scrum Master 50................................................................................Herausforderungen 50

....................Die XP Engineering Practices für die konkrete Implementierung 51.....................................................................................Hauptpraktiken 51....................................................................................Begleitpraktiken 54

.............................................Software Kanban für die nachgelagerte Wartung 57...............................................................................................Literaturverzeichnis 58

...........................................................................................Abkürzungsverzeichnis 61

iv Blue Scrum Das Prozessmodell

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

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?

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


http://blog.rainwebs.net/blue-scrum/http://blog.rainwebs.net/blue-scrum/

Ü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


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.


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


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


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.


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


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


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.


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.


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.


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.


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.


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


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


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.


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


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


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


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



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

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:



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

• 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


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“


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


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


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


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


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


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


• 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


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


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


1.11 Projekt-Phasen, Ablauf und Termine


Ablauf und Termine

1.12 Ressourcen Prozess Untergruppe 7

Ressourcen

1.13 Kosten und Finanzmittel


Kosten und Finanzen

1.14 Beschaffung und Verträge


Verträge und Nachforderungen

1.15 Kon!guration und Änderungen


Änderungen

1.16 Projekt-Controlling: Überwachung und Steuerung, Berichtswesen

PM-Phase Steuerung

1.17 Information und Dokumentation


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:


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


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 Basi

blue scrum prozessmodell - blue scrum – mit freude...

Documents

Bitter SCRUM - DialogData Vortrag Chris Rupp... · Bitter Scrum –Auf der Suche nach den Sweet Spots Schluss-folgerung 5 Scrum 2 Intro 1 Scrum in der Projektrealität 4 Projektrealität

Agile Softwareentwicklung mit Scrum - BISbis.informatik.uni-leipzig.de/.../files?get=scrum_markus_nentwig.pdf · Warum Scrum Begriffe - Deﬁnition Scrum im Detail Beispiele Gliederung

Scrum besser machen - dl.dasscrumteam.comdl.dasscrumteam.com/DST_DoBetterScrum_deutsch.pdf · Scrum besser machen Eine inofﬁzielle Sammlung von Tipps und Einsichten, Scrum gut zu

Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum

Agiles Projektmanagement mit Scrum - tqu-group.com · •Scrum ist ein schlanker, agiler Prozess für Projektmanagement u. a. in der Softwareentwicklung. • Woraus besteht Scrum?

Scrum Guide Poster 1.1 - dasscrumteam.com€¦ · Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte. Der Scrum Guide beinhaltet die Deﬁnition von Scrum

Betriebsverfassungsgesetz und Scrum - Scrum Day 2013archiv.scrum-day.de/archiv/scrumdayjul12sap/vortraegedownload... · 1 Betriebsverfassungsgesetz und Scrum Wie passt das zusammen?

Agile Softwareentwicklung mit Scrum - HS Augsburggori/AgileSWE/Script-Scrum-01.pdf · Agile Softwareentwicklung Scrum Pichler Roman dpunkt.verlag 978-3-89864-478-5 Scrum Gloger B

Scrum Guide - Squarespacestatic.squarespace.com/static/51e3f87ce4b0031a73dac256/t... · die erfolgreiche Anwendung von Scrum. Das Scrum Team Das Scrum Team besteht aus dem Product

Teams mit Scrum infizieren – auf dem Tandem geht’s leichter · Teams mit Scrum infizieren – auf dem Tandem geht’s leichter „Scrum is Simple. Doing Scrum is Hard.“ (Jim

Effiziente Management von Scrum Projekten mittels Multi ... · Scrum Poker ! Daily Scrum: Status-Meetings mit Burndown etc. ! Synchronisation: Team Foundation Server . ScrumTable

Semesterprojekt: Einführung in Scrum...Einführung in Scrum Wintersemester 2018/19 Matthias Weidlich Stephan Fahrenkrog-Petersen. ... Scrum Board - Jira 18. Scrum 19. Sprint • 1

Failure Stories mit Scrum - scrum-master.de · Scrum wird manchmal als "Silver Bullet" wahrgenommen, als magische Lösung aller Projektmanagement-Probleme. Scrum ist aber nicht die

Scrum eingef hrt - und nun? - Software-Entwicklung …Management-Ebene kommt in Scrum um eine Änderung des Selbstverständnis nicht herum. Scrum ohne Clean Code wird Flacid Scrum

Berater-Profil + Referenz-Projekte - Scrum-Master.de€¦ · Web viewAgile / Lean Coach Certified Scrum Master Certified Scrum Professional Alter: 48 Jahre, * 08.05.1971 Nationalität:

Scrum Intro

Scrum angepasst - Erfolgsmodell bei der Projektron GmbH · Scrum angepasst - Erfolgsmodell bei der Projektron GmbH Effizientere Produktentwicklung durch Scrum – wie das geht, zeigt

VKSI Magazin 2 - isf-muenchen.de · Scrum: Scrum (engl. für Gedränge) beschreibt die Standard- ... AgiLe SoFtWAReentWickLung Mit ScRuM* ROLLEnSPIEL I Der Scrum Master ist zuständig

Begeistern! (2018), Berlin, CoObeya...Agile Produktentwicklung 142 Scrum 148 Scrum und empirisches Steuern 148 Scrum-Rollen für bessere Zusammenarbeit 150 Das Vorgehen in Scrum 151

Scrum - Einführungjohanneslink.net/downloads/Scrum Erleben.pdf · Agenda • Was ist Agilität? Was ist Scrum? • Scrum: Rollen, Meetings und Artefakte • Scrum erleben • Spezialitäten

Betriebsverfassungsgesetz und Scrum - Scrum Day 2012

Sybit Ausgabe 4 agile · Scrum dagegen ist eine sogenannte agile Projektmanagement - methode (kein Prozessmodell!), die nach den Prinzipien des Agilen Manifesto7 konzipiert wurde

SCRUMAnforderung auch Softwaretester, UX-Designer und technische Schreiber. Regirt M., Siller C. SCRUM 13. Dezember 2018 9 / 36 SCRUM-Prozess SCRUM-Prozess Regirt M., Siller C. SCRUM

Scrum in der Praxis - Ein Blick hinter die Kulissen von Scrum

198 WIE SKALIERT SCRUM? - wibas.com · SCRUM TEAM DER SCRUM MASTER Scrum Master A Scrum Master B Scrum Master C Chief Scrum Master USER STORY TEAM TEAM A TEAM B TEAM C Aufgabe, die

Scrum breakfast skillset_toolset_mindset

projekt Angebotsüberblick raum · die verschiedenen Rollen eines SCRUM Projektes die verschiedenen Artefakte eines SCRUM Projektes das zentrale Controlling Instrument im Scrum: der

Scrum besser machen - Scrum Sensescrumsense.com/wp-content/uploads/2014/02/ScrumBesserMachen-v… · Was ist Scrum? Woher kommt Scrum? Scrum ist ein Management-Rahmenwerk, innerhalb

Mechanische FMN-V 60 Blue FMN-V 12 Blue Mobil ... · FMN-V 5 Blue bis FMN-V 60 Blue FMN-V 5 Blue FMN-V 12 Blue FMN-V 60 Blue FMN-V 30 Blue Standardausführungen Air Industriefilter

Das Onlineunterrichtswerk · Prozessmodell: Ziele –Vorarbeiten –Abgrenzungen ... Leitfaden zum Kerncurriculum Hessen Richtlinien aus Rheinland Pfalz

Scrum mit WorkFlowy

Scrum Andreas Voraberger. Inhalt Einführung Definition Ablauf Scrum Rollen Scrum Master Product Owner Scrum Team

PromoS - Prozessmodell für nicht-medizinische ... · PromoS - Prozessmodell für nicht-medizinische Supportleistungen in Spitälern basierend auf LekaS Version 1.0 Autorinnen: Nicole

Scrum Anwendungsfehler

Die Scrum Checklist - files.hanser.defiles.hanser.de/hanser/docs/20130415_21341513727-102_110413... · Scrum – ein Managementansatz mit einfachen Prinzipien. Die Scrum Checklist