Beruflich Dokumente
Kultur Dokumente
Agiles Projektmanagement - Projektentwicklung Mit Scrum, Kanban & Co.
Agiles Projektmanagement - Projektentwicklung Mit Scrum, Kanban & Co.
6.4.2. Product Backlog
Wie bereits erwhnt, werden die Anforderungen vom Product Owner im Product Backlog
festgehalten. Unter dem Product Backlog versteht man eine priorisierte und rein
nutzerorientierte Liste mit Anforderungen, die das zu entwickelnde Produkt bercksichtigen
muss. Idealerweise erfolgt ein Eintrag in Form einer User Story als Antwort auf die Frage
Wer mchte was warum? nach folgendem Muster:
Als User x mchte ich Funktionalitt y, damit ich Nutzen z habe.
(Quelle: http://borisgloger.com/2011/06/20/scrum-essentials-die-sieben-fragen-der-user-
story/)
TechDivision GmbH Agiles Projektmanagement '$
6.4.3. Impediment Backlog
Beim Impediment Backlog handelt es sich um eine Liste aller Blockaden, die einer effektiven,
produktiven Arbeit des Teams im Weg stehen. Dieses Backlog wird bei den Scrum-
Artefakten meist bersehen. Boris Gloger gibt in seinem Blog 10 Tipps zum richtigen
Impediment Backlog, die von einem Scrum Master beachtet werden sollten (Quelle:
http://borisgloger.com/2010/10/04/das-impediment-backlog-10-tipps/):
a) Hnge es ffentlich auf. Am besten im Gang, so dass es alle sehen knnen.
b) Schreibe aktive Stze. z.B. Wir bentigen eine bessere Kaffeemaschine.
c) Beim Formulieren der Stze nicht beleidigen, aber auch nichts verschweigen.
d) Das Impediment Backlog sollte immer mindestens 10 Eintrge vorweisen.
e) Denke daran, alle Bereiche der Verbesserung tatschlich zu bearbeiten.
f) Mach es ordentlich: Es ist ein Ausdruck Eures Qualittsbewusstseins, ob das
Impediment Backlog ordentlich und gepflegt aussieht oder schlampig ist. Wir alle
schlieen von der Form auf den Inhalt: Unordentliche Charts = Schlampig
programmierte Software.
g) Das Impediment Backlog muss sich verndern. Zeige durch Durchstreichen und
Hinzufgen, dass auch DU als Scrum Master etwas tust.
h) Sage nicht: Der oder Die muss etwas tun, sondern DU als Scrum Master musst etwas
tun.
i) Sprich das Backlog einmal in der Woche mit deinem Chef durch. Weise ihn
kontinuierlich auf die Verbesserungsmglichkeiten hin.
j) Sprich das Backlog einmal in der Woche mit den anderen Scrum Mastern in deiner
Organisation durch. Aktualisiere es mit den neuen Informationen.
6.4.4. Burndown-Diagramm
Der aktuelle Entwicklungsstand wird idealerweise in einem sog. Burndown-Diagramm
dargestellt, auf dem auf der x-Achse der Zeitverlauf und auf der y-Achse die Tasks oder
Storypoints eingetragen werden. Eine Diagonale von links oben nach rechts unten stellt
dabei den optimalen Projektverlauf dar. Je nach Abweichung der aktuellen Burndown-Linie
von der Diagonale kann sehr schnell beurteilt werden, ob das Entwicklungsteam in Time ist
oder aktuell Verzgerungen bestehen, die bis zum Ende aufgeholt werden mssen. Da alle
Projektbeteiligten, also auch der Kunde (!!!), Zugriff auf dieses Burndown-Diagramm haben,
wird hchstmgliche Transparenz whrend der Implementierung gewhrleistet. Dadurch
lsst sich bei etwaigen Ausreiern auch frhzeitig gegensteuern bzw. werden geeignete
Gegenmanahmen ergriffen, um das Projekt wieder auf Schiene zu bringen.
TechDivision GmbH Agiles Projektmanagement '%
(Quelle: Exemplarischer Burnout-Chart mit dem Projektmanagement-Tool JIRA /
TechDivision)
6.5. Welche Vorteile bietet Scrum?
Die Vorteile der agilen Softwareentwicklung mit Scrum sind vielfltig. Zum einen ist es so,
dass bei Scrum-Projekten die Flexibilitt deutlich zunimmt, da man ein Groprojekt in
kleinere Teilprojekte (Sprints) herunterbricht und diese einzeln und nacheinander realisiert.
Nach jedem Teilprojekt erfolgt ein Review. Die Erkenntnisse flieen dann wieder in die
nachfolgenden Teilprojekte ein. Damit knnen auch nderungen am Markt oder neue
Erkenntnisse und Ideen zum Produkt jederzeit aufgegriffen und in einem der kommenden
Sprints bercksichtigt werden.
Ein ganz entscheidender Vorteil bei Scrum liegt auch im ausgeprgten Team-Gedanken.
Anforderungen und Probleme werden im Team diskutiert und gelst. Durch das cross
functional Team und den gruppendynamischen Prozess ergeben sich vielfach bessere
Endergebnisse. Darber hinaus arbeiten selbstorganisierte Teams effektiver.
Einer der grten Vorteile von Scrum liegt in der hchstmglichen Transparenz. Alle
Projektbeteiligten haben durch Zugriff auf Backlogs, auf Burndown-Diagramme mit dem
Projektfortschritt, den angefallenen Projektzeiten sowie etwaige Hemmnisse zu jedem
Zeitpunkt vollstndige Transparenz auf den aktuellen Entwicklungsstand. Hier kann jeweils
sehr zeitnah gegengesteuert werden, wodurch bse berraschungen ausbleiben.
Durch die permanente Diskussion in der Gruppe sowie die Reflexion am Ende eines jeden
Sprints wird ein kontinuierlicher Verbesserungsprozess gewhrleistet, der sich sehr positiv
auf die fachlichen Ergebnisse und auch auf die wirtschaftlichen Belange auswirkt. Aufgrund
der hppchenweisen Realisierung arbeiten Entwickler konzentrierter und auch fokussierter.
Durch das Arbeiten im Team und den dadurch gegebenen gegenseitigen Ansporn steigt die
Motivation und die Arbeitsergebnisse werden besser.
6.6. Die Kostenkalkulation in Scrum
Hufig wird vom Auftraggeber ein Fixpreis-Angebot gefordert, was in der Praxis ganz
offensichtliche Mngel und Nachteile mit sich bringt: Zum einen lassen sich bestimmte
Anforderungen und Features im Vorfeld hufig kaum vernnftig schtzen, da hier
Erfahrungswerte und detaillierte Informationen fehlen. Zum anderen ist es bei dem
TechDivision GmbH Agiles Projektmanagement '&
berwiegenden Teil von IT-Projekten so, dass sich whrend der Implementierung mitunter
weitreichende nderungen ergeben. Entweder weil sich Anforderungen z.B. aufgrund von
genderten Marktbedingungen ndern oder weil sich herausstellt, dass die im Vorfeld
geplanten Lsungsanstze aus welchem Grund auch immer sich in der Praxis so nicht
umsetzen lassen. Das zieht zwei Probleme nach sich, die mitunter recht schwergewichtig
sind und die die scheinbare Sicherheit eines Fixpreisangebotes fr den Auftraggeber in
einem anderen Licht erscheinen lassen.
Ein vernnftig agierender Dienstleister kalkuliert und dies muss er aus wirtschaftlichen
Gesichtspunkten auch Unsicherheiten bzw. Unwgbarkeiten aufgrund von fehlenden
Detailinformationen und Erfahrungswerten in sein Angebot mit ein, was fr den Auftraggeber
bedeuten kann, dass er fr die gewnschte Leistung deutlich zu viel bezahlt.
Gerade Agenturleistungen sind dabei sehr preisgetrieben. Der Auftraggeber entscheidet sich
daher mglicherweise fr den vermeintlich gnstigsten Anbieter. Machen wir uns hier aber
nichts vor: Heutzutage hat niemand etwas zu verschenken. Genauso wenig wie Sie Ihre
Produkte oder Dienstleistungen fr wenig Geld abgeben, wird dies eine Agentur tun. Insofern
erlebt man es auch recht hufig, dass der vermeintlich gnstigste Anbieter den Zuschlag
bekommt, dieser in der Umsetzung dann aber eben aus Budgetgrnden entweder nicht
sauber arbeitet, ein halbfertiges Produkt abliefert und/oder am Ende eine Nachkalkulation
fordert, um seine Kalkulation sauber halten zu knnen. Dadurch kann das vermeintliche
Schnppchen schnell in einem Desaster enden. Im schlimmsten Fall geht es dann jedoch
nicht mehr nur ums Geld, sondern mglicherweise auch ums Image und etwaige Schden.
Aus unserer Sicht und aufgrund unserer 15-jhrigen Erfahrung im Bereich Webentwicklung
knnen wir mit nahezu 100%-iger Sicherheit feststellen, dass man bei Softwareprojekten
seriser- und richtigerweise im Vorfeld eigentlich nur Schtzungen abgeben kann, da hier
einfach zu viele Unwgbarkeiten mitspielen, die nicht kalkulierbar sind. Insofern bietet ein
Fixpreis-Angebot nur auf den allerersten Blick die vermeintliche Sicherheit fr den
Auftraggeber. Wie bereits ausgefhrt, wird er die tatschlichen Kosten und diese werden
sehr hufig hher ausfallen als das erste Angebot anderweitig bezahlen, entweder
unmittelbar in Form von Change Requests oder ber Umwege, also etwa ber
Nachbesserungsmanahmen durch einen anderen Dienstleister aufgrund mangelnder
Qualitt bzw. nicht fertiggestellter Software. Darber sollte man sich als Auftraggeber im
Klaren sein: Die Rechnung wird kommen so oder so!
Fairerweise muss man hier auch ganz klar erwhnen, dass es unter wirtschaftlichen
Gesichtspunkten kaum mglich sein wird, bei einem komplexeren IT-Projekt ein Lasten- und
Pflichtenheft in der Qualitt zu erstellen, sodass es als richtige Basis fr ein Fixpreisangebot
verwendet werden kann. Der Aufwand hierfr wird am Markt kaum bezahlt werden, wodurch
sich dann einmal mehr die Frage stellt, ob ein gnstigeres Alibi-Lasten- und Pflichtenheft
dann berhaupt Sinn macht.
Scrum ist insofern der fr alle Beteiligten ehrlichste Ansatz. Ein Groprojekt wird in kleinere
Teilprojekte zerlegt und dann einzeln geschtzt. Es wird auch nur das abgerechnet, was
tatschlich an Aufwand entstanden ist. Durch die vollstndige Transparenz und Involvierung
des Kunden in den Enwicklungsprozess hat dieser hchstmgliche Sicherheit und kann auch
jederzeit reagieren. D.h. er kann bei sich abzeichnenden Budgetberschreitungen jederzeit
auch in Abstimmung mit dem Scrum-Team gegensteuern und im Notfall natrlich auch
abbrechen. Hier hat er auch immer den Vorteil, dass bis dahin entwickelte Software oder
Teile davon weiterverwendet werden knnen, da das Ziel von Scrum in der Bereitstellung
von funktionsfhiger Software bzw. Softwareteilen besteht. Das bedeutet: Transparenz und
Bezahlung nur fr die tatschlich erbrachte Leistung! Aus unserer Sicht ist dies der deutlich
bessere und auf lange Sicht gesehen auch fr alle Beteiligten der wirtschaftlichste Ansatz.
TechDivision GmbH Agiles Projektmanagement ",
In der Praxis hat sich bewhrt, dass das initiale Backlog mit auf hohem Abstraktionsniveau
formulierten Anforderungen zusammen mit dem Kunden erstellt wird. Auf Basis der so
erfassten Anforderungen kann eine erste Abschtzung der Aufwnde erfolgen. Wir gehen
dabei aufgrund der im Backlog erfassten Anforderungen von x Sprints 2-4 Wochen mit x
Personen aus. Durch diese Kalkulation kann der Projektumfang in einem sehr frhen
Stadium bereits umrissen werden. Hier besteht fr den Auftraggeber dann auch die
Mglichkeit die so ermittelten Werte zu deckeln oder einen niedrigeren Wert als
Hchstgrenze fr die Implementierung anzusetzen. Bei der Umsetzung wird dies dann
entsprechend bercksichtigt. Grundstzlich werden in der Folge nur die tatschlich
angefallenen Aufwnde abgerechnet, wobei durch den jederzeitigen Zugriff auf die
Projektmanagementtools diese Aufwnde tglich eingesehen und berwacht werden
knnen. Dadurch werden bse berraschungen vermieden!
Insofern lsst sich mit Scrum auch wenn dies nicht der eigentlichen Idee von Scrum
entspricht ein IT-Projekt auch mit einem vorab fixierten Budget realisieren. In diesem Fall
wird, sofern das Budget fr die gewnschten Features nicht ausreichen sollte, in
Abstimmung mit dem Kunden die eine oder andere Funktionalitt gestrichen oder angepasst,
wodurch das definierte Projektbudget wieder gehalten werden kann und das ohne und dies
ist sicherlich ganz entscheidend - Kompromisse bei der Qualitt eingehen zu mssen!
6.7. Die grten Fehler im Scrum-Prozess
Innerhalb eines Scrum-Projekts zeigen Retrospektiven schnell auf, wie die Effizienz und
damit Performance des Teams weiter gesteigert werden kann. Dabei besteht allerdings auch
die Gefahr, dass eigene Modifikationen sogenannte ScrumButs an Scrum vorgenommen
und wichtige Elemente ausgeblendet werden. Meist wurde dann die Quintessenz von Scrum
nur bedingt verstanden.
Beispiele fr ScrumButs sind:
Wir nutzen Scrum, aber wir
bentigen aufgrund unseres kleinen Teams keinen Scrum Master
brauchen die Aufwandschtzung einzelner Aufgaben nicht
verlngern einen Sprint, bis wir unser Ziel erreicht haben
verzichten auf Retrospektiven
(Quelle: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/ )
Tipps & Tricks so vermeiden Sie Scrum-Fehler
Keine umfassende Planung / Vorbereitung
Bei Scrum sind exzessive Vorbereitungsphasen nicht notwendig. Stattdessen sollte
versucht werden, mglichst schnell mit der Implementierung zu starten und ein
permanentes Feedback in den Sprint Reviews zur Weiterentwicklung und
Verbesserung zu nutzen. Sogar das Product Backlog kann bei Bedarf nach Beginn
des ersten Sprints erst noch erstellt werden.
Keine Versteifung auf Tools, die den Scrum Prozess vereinfachen
Hufig wird versucht im Vorfeld (bevor man Scrum wirklich verinnerlicht hat)
entsprechende Softwaretools zu finden, die den Scrum-Prozess abbilden und
vereinfachen. Zu Beginn reichen hier jedoch Stifte und Papier, da der Start damit
TechDivision GmbH Agiles Projektmanagement "'
genauso mglich und hufig gerade zu Beginn einfacher und schneller abbildbar ist.
Daily Scrum kurz und knackig!
Das tgliche Scrum Meeting darf nicht dazu dienen, grere Probleme oder
Schwierigkeiten zu diskutieren und hier Lsungsanstze zu erarbeiten. Stattdessen
sollte das Meeting mglichst kurz und knackig gehalten werden.
Problemdiskussionen sollten dann im Anschluss mit den relevanten Personen
separat gefhrt werden. Der Scrum Master berwacht dabei die Diskussion und sorgt
dafr, dass das Ganze mglichst zielgerichtet abluft.
Selbststndiges Arbeiten
Scrum Teams arbeiten selbst organisierend und besorgen sich die Aufgaben
eigenstndig. Eine Zuweisung von Tasks ist nicht erforderlich und meist auch
kontraproduktiv.
Scrum Master als Mitwirkender
Der Scrum Master kann als Coach im Scrum Team bezeichnet werden, der dafr
sorgt, dass der Scrum-Prozess mglichst reibungslos funktioniert und das Team sich
vollstndig auf die Implementierung konzentrieren kann. Eine aktive Mitarbeit im
Projekt ist hier nicht frderlich und sollte in jedem Fall vermieden werden. Gleiches
gilt fr technische Vorgaben, die der Scrum Master unbedingt unterlassen sollte.
Product Owner als kompetenter Ansprechpartner
Als verlngerter Arm des Kunden muss der Product Owner in den
Entwicklungsprozess und den aktuellen Stand der Entwicklung immer eingebunden
und fr das Team bei Fragen oder Unklarheiten auch jederzeit greifbar sein. Zudem
sorgt er fr die permanente Kommunikation mit dem Kunden.
Keine Vorgaben von auen
Ausschlielich das Team entscheidet, wie viele Tasks in einem Sprint abgearbeitet
werden. Vorgaben von auen sollten hier unbedingt vermieden werden, um
bestmgliche Qualitt gewhrleisten zu knnen.
Keine Alleingnge innerhalb des Teams
Scrum lebt vom Teamgedanken und der gemeinsamen Arbeit an einem Projekt. Die
Teammitglieder sollten daher auf Alleingnge jeglicher Art verzichten und stattdessen
ein mglichst umfassendes Wir-Gefhl entwickeln. Das Team gewinnt und verliert
gemeinsam!
Klare Verantwortlichkeiten
Der Product Owner ist fr die Spezifikation der Anforderungen zustndig. Er
beschreibt und bersetzt, was am Ende erstellt werden muss. Die technische
Umsetzung und die technologischen Anstze obliegen jedoch einzig und allein dem
Team.
Keine Unterbrechungen innerhalb eines Sprints
Sofern whrend des Sprints besonders dringende Themen auftauchen, sollte nach
Mglichkeit versucht werden, diese nach dem Sprint anzugehen und den Sprint
mglichst unverndert zu Ende zu fhren. In besonders dringenden Fllen, sollte statt
einer nderung innerhalb des Sprints der komplette Sprint abgebrochen werden.
Teammitglieder entscheiden nicht selbst ber Anforderungen
Der Product Owner ist als Produktverantwortlicher fr die Ausgestaltung des
TechDivision GmbH Agiles Projektmanagement ""
Produktes und das Endergebnis verantwortlich. Er entscheidet auch alleine ber
Anforderungen und Besonderheiten. Teammitglieder mssen sich bei Fragen im
Vorfeld mit dem PO abstimmen und drfen hier nicht eigenstndig Entscheidungen
treffen, die ber technische Anstze hinausgehen.
Zielorientiertes Vorgehen
Zu Beginn eines Sprints werden entsprechende Sprintziele definiert, die zwingend
eingehalten und whrend des gesamten Sprints berwacht werden mssen. Anhand
von sog. Burndown-Charts kann der Projektverlauf tglich mitverfolgt werden. Am
Ende eines Sprints muss eine funktionsfhige und getestete Software ausgeliefert
werden, bei der im Zweifelsfall lieber ein Feature weggelassen wird. Die fertig
gestellten Funktionen mssen jedoch mglichst fehlerfrei funktionieren, so dass damit
ein Go Live jederzeit mglich wre.
Komprimierte Teams
Da bei Scrum das Team im Vordergrund steht und hier der Teamgedanke ber allem
schwebt, sollte das Team auch mglichst in einem Raum sitzen um die
Kommunikation und das Wir-Gefhl optimal zu untersttzen. Verteilte Scrum-Teams
funktionieren zwar grundstzlich auch, am meisten kann jedoch von komprimierten
Teams profitiert werden.
nderungen des Scrum Teams vermeiden
Wie bereits mehrfach erwhnt, entfaltet Scrum seine Strken im Team und mit
laufender Zusammenarbeit der Team-Mitglieder. Insofern sollte whrend eines
Scrum-Projektes eine nderung am Scrum Team unbedingt vermieden werden.
Insbesondere durch Kontinuitt kann sich ein Scrum Team laufend verbessern und
die Arbeit im Team permanent optimieren.
Augenmerk auf Qualitt
Eigenverantwortlichkeit sowie das Thema Auslieferbare Software steht bei Scrum
im Vordergrund. Dies bedeutet nichts anderes, als dass die gelieferten Ergebnisse
whrend des Sprints entsprechend getestet und optimiert werden um ein
bestmgliches und finales Ergebnis abzuliefern. Dies muss vom Team im Rahmen
des Sprint-Plannings bercksichtigt werden, damit die implementierten Features auch
noch ausreichend getestet werden knnen. Separate Test-Teams sind bei Scrum
nicht vorgesehen, da die Ergebnisse dies nicht erforderlich machen.
TechDivision GmbH Agiles Projektmanagement "(
6.8. bersicht der Vor- und Nachteile von Scrum
(Quelle: TechDivision)
Was aus unserer Sicht noch besonders herauszustellen ist: Auch mit Scrum ist man vor
Sackgassen in einem IT-Projekt nicht geschtzt, man erkennt diese in der Regel jedoch
deutlich schneller und kann dementsprechend frhzeitig reagieren. Insofern eignet sich
Scrum immer dann ganz besonders gut, wenn bereits zu Beginn des Projektes bei einer
Vielzahl von Punkten noch Klrungsbedarf besteht, gewisse Unsicherheiten vorhanden sind
bzw. bereits im Vorfeld zu erkennen ist, dass es hier noch zu diversen nderungen und
Anpassungen im Projektverlauf kommen kann bzw. wird.
Die Grundlagen von Scrum und Kanban sind zwar einfach zu verstehen, eine disziplinierte
Umsetzung ist jedoch meist nicht so einfach zu erzielen. In diesem Zusammenhang lohnt es
sich meist auf Scrum-Experten bei TechDivision arbeiten u.a. vier Certified Scrum
Professionals zurckzugreifen, die Team und Kunden schulen und so eine reibungslose
Projektabwicklung garantieren. Scrum ist dabei weitaus mehr als nur ein Framework fr
Software- bzw. Produktentwicklung. Scrum ist vielmehr ein Paradigmenwechsel, der sowohl
vom Kunden als auch vom Team ein Umdenken voraussetzt.
TechDivision GmbH Agiles Projektmanagement ")
6.9. Zusammenfassung: Scrum
Simon Baker hat vor lngerer Zeit zum Thema Festpreisprojekte folgendes geschrieben:
To say how much something will cost, you need to know in great detail exactly what needs
to be built so that your estimates for the work can be accurate. But you cant define
everything you want, in detail and up front, and get it exactly right so there will be no changes
in the future. And no estimate is ever accurate (it wouldnt be an estimate if it was). []
Dont base the contract with your vendor on conformance to a detailed requirements
specification. If you do, youre saying all your good ideas happen at the start of a project and
youre effectively betting all your money on a hole-in-one...
(Quelle: http://www.energizedwork.com/weblog/2007/05/fixed-price-contracts-dont-work.html)
Das nachfolgende Video zeigt in knapp 5 Minuten nochmals die wesentlichen Elemente
sowie die Vorgehensweise bei Scrum.
(Quelle: http://www.youtube.com/watch?v=0Nuj-GgEW6o)
Aus unserer Sicht bleibt fr Auftraggeber nur die Empfehlung, sich beim nchsten Projekt
einmal auf das Thema Scrum einzulassen. Auch ein Festpreisangebot schtzt den
Auftraggeber nicht vor etwaigen Risiken und damit verbundenen Mehraufwnden, die dann
vielleicht zwar nicht sofort zu Buche schlagen, zu einem spteren Zeitpunkt aber in nahezu
allen Fllen zum Tragen kommen. Bei Scrum steht nicht ein fixer Preis fr vorab
genauestens definierte Features im Vordergrund, sondern die termingerechte Auslieferung
bestmglicher und funktionierender Software, die die definierten Anforderungen erfllen
muss. Bei der Umsetzung bestehen hier mehr Freiheiten was jedoch keinesfalls mit
mangelnder Qualitt gleichzusetzen ist.
TechDivision GmbH Agiles Projektmanagement "*
7. Agiles Projektmanagement mit Kanban
Kanban ist eine Methode der Produktionsprozesssteuerung. Das Vorgehen orientiert sich
ausschlielich am tatschlichen Verbrauch von Materialien am Bereitstellungs- und
Verbrauchsort. Kanban ermglicht ein Reduzieren der lokalen Bestnde von Vorprodukten in
und nahe der Produktion, die dort in Produkten der nchsten Integrationsstufe verbaut
werden. (Quelle: http://de.wikipedia.org/wiki/Kanban )
7.1. Zur Geschichte von Kanban
Das Wort Kanban stammt aus dem Japanischen und bedeutet so viel wie Karte, Tafel
oder Beleg. Das Prinzip ist auch unter Hol-, Zurufprinzip oder Pull-Prinzip bekannt. Das
ursprngliche Kanban wurde bereits 1947 von Taichi Ohno entwickelt, der mit dem System
auf die mangelnde Produktivitt bei Toyota Motor Corporation im Vergleich zur
amerikanischen Konkurrenz reagierte. Seine Idee war es dabei die Produktion nach dem
Supermarkt-Prinzip zu gestalten und zu organisieren: Sobald ein Verbraucher etwas aus
dem Regal nimmt, wird dieses sofort wieder aufgefllt.
Das Kanban-Prinzip ist auch als eine Reaktion auf die Bedrfnisse der Kunden zu sehen, die
neue Anforderungen an die Produktionsgeschwindigkeit, Lieferbereitschaft und
Zuliefererbeziehungen haben. Das Kanban-Verfahren ersetzte dabei bisherige
Produktionsverfahren und wurde von zahlreichen japanischen Unternehmen, darunter auch
Toyota, eingefhrt. In den 70er Jahren wurde das System auch in Deutschland und in den
USA adaptiert. (vgl. http://de.wikipedia.org/wiki/Kanban#Historische_Entwicklung)
7.2. Kanban in der Softwareentwicklung
David J. Andersson berarbeitete die Grundidee von Kanban und passte diese vor allem
hinsichtlich der Bedrfnisse in der Softwareentwicklung an. Ergebnis ist ein evolutionres
Vorgehen, bei dem kontinuierlich Arbeitsweisen verbessert und optimiert werden. In diesem
Zusammenhang wird dabei immer von der gegenwrtigen Situation ausgegangen. Einen
Kanban-Sollzustand gibt es dabei nicht. Kanban-Teams halten sich vielmehr an folgende
grundlegende Prinzipien:
Visualisierung des Arbeitsflusses und der Arbeit
Limitierung des WIP (WIP = Work In Progress, in Ausfhrung befindliche Arbeit)
Steuerung und Messung des Arbeitsflusses
Prozess-Regeln explizit machen
Verbesserung durch bewhrte Modelle und wissenschaftliche Methoden
Quelle: http://www.heise.de/developer/artikel/Software-Kanban-im-Einsatz-1235465.html
Ziel ist es durch Kanban Mechanismen im System zu implementieren, die laufende
Verbesserungen und Vernderungen erlauben. Im Laufe des Prozesses knnen sich so die
Teammitglieder einbringen und Optimierungen des Workflows vornehmen. Diesbezglich
muss erst einmal der Kaizen-Gedanke in die Kpfe der Menschen gebracht werden. Dabei
mssen Vernderungen nicht am Menschen, sondern durch den Menschen passieren.
TechDivision GmbH Agiles Projektmanagement "+
7.3. Kanban in Projekten
Kanban und Scrum finden ihren Einsatz in unterschiedlichen Projekten. Bei Kanban handelt
es sich im Gegensatz zu Scrum um eine Vorgehensweise, die einen kontinuierlichen
Arbeitsfluss garantieren soll. In diesem Zusammenhang werden alle anstehenden Aufgaben
und Ablufe mit Hilfe eines Boards, das in Zeilen und Spalten aufgeteilt ist, visualisiert. Auf
dem Board finden sich die Aufgaben in Form von Tickets wider. Jede Spalte reprsentiert
dabei einen Arbeitsschritt und das Projektteam kann jederzeit den Status einer Aufgabe
einsehen. In diesem Zusammenhang gibt es ein Limit an parallel laufenden Aufgaben. Ziel
dabei ist es, das Team nicht mit unterschiedlichen Aufgaben zu berhufen, sondern ein
konzentriertes Arbeiten an einem Task zu ermglichen (Limit work in progress). So ist ein
gleichmiges Bearbeiten von Tickets ohne lange Wartezeiten oder Blockaden
gewhrleistet. Ein zentraler Aspekt ist dabei der Flow-Gedanke. Kanban visualisiert somit
den aktuellen Prozess, ndert diesen aber zunchst nicht.
Kanban gilt als eine agile Methode, um Change Management evolutionr durchfhren zu
knnen. Dabei werden bestehende Prozesse schrittweise optimiert und verbessert. Durch
die nderung kleinerer Aspekte wird das Risiko fr jede einzelne Manahme verringert. Ein
Vorteil von Kanban ist auch der geringere Widerstand bei den Beteiligten. (vgl. http://www.it-
agile.de/wissen/methoden/kanban/)
7.4. So funktioniert Kanban
Eine wichtige Aufgabe von Kanban ist es vorhandene Probleme und Arbeiten darzustellen
und zu visualisieren. In diesem Zusammenhang spielt das sogenannte Kanban-Board eine
wichtige Rolle, welches beispielsweise aus einem Whiteboard, Karteikarten oder Haftnotizen
bestehen kann. Jede Aufgabe wird dabei durch eine Karte, etc., prsentiert. Der Vorteil
dieser Vorgehensweise ist eine erhhte Transparenz bei der Bearbeitung von Projekten. (vgl.
http://www.it-agile.de/wissen/methoden/kanban/) Kanban orientiert sich dabei an Lean-
Prinzipien und basiert auf dem Pull-Prinzip (Hol-Prinzip), bei dem die anfallende Arbeit nicht
von einem Vorgesetzten verteilt wird, sondern die Arbeiter bzw. Teammitglieder sich
selbststndig ihre Arbeit holen. Diese wird auf sog. Kanban-Karten am Kanban-Board
hinterlegt.
TechDivision GmbH Agiles Projektmanagement "$
(Quelle: http://www.it-agile.de/wissen/methoden/kanban/ )
Die Tasks wandern dabei von links nach rechts bis sie in der Spalte Fertig angekommen
sind. Die Spalten knnen dabei mit den jeweiligen Anforderungen abgestimmt werden.
Kanban gibt relativ wenig Vorgaben und ist somit stark an die jeweils individuellen
Bedrfnisse im Bezug auf Entwicklungsprozesse, Rollen, Releaseplanungen, etc.,
anpassbar.
Der Work in Progress die Anzahl an parallel laufenden Tasks wird dabei begrenzt, um
Multitasking zu reduzieren und Aufgaben zielgerichteter erledigen zu knnen. Im Mittelpunkt
von Kanban steht dabei das Flow-Prinzip. Tickets sollen so gleichmig und in mglichst
kurzer Zeit durch das System gleiten (http://www.it-agile.de/wissen/methoden/kanban/ ).
Nachfolgendes Video beschreibt in wenigen Minuten die wesentlichen Ideen und Anstze fr
Kanban im IT-Umfeld:
Quelle: http://www.youtube.com/watch?v=0EIMxyFw9T8
TechDivision GmbH Agiles Projektmanagement "%
7.5. Vorteile von Kanban im berblick
Kanban lsst sich in verschiedenen Bereichen einsetzen und es knnen sowohl kleine
Agenturen und Startups, als auch traditionelle Mittelstndler, grere Web-Plattformen sowie
internationale Unternehmen von dem Prinzip profitieren.
Transparenz
Durch die Darstellung von Problemen und Arbeiten auf dem Kanban-Board wird eine
bessere bersicht ber den Projektfortschritt geschaffen und es knnen dabei akute
Probleme besser identifiziert werden.
Schnelle Bearbeitung von Tasks
Die Bearbeitung der limitierten Anzahl von Tickets fhrt zu krzeren Durchlaufzeiten
der Arbeitspakete.
Vielseitiger Einsatz
Kanban lsst sich nicht nur in der reinen Softwareentwicklung einsetzen. Das Prinzip
ist auch in anderen Bereichen wie beispielsweise bei der Wartung,
Systemadministration, Marketing oder dem Vertrieb zielfhrend und effektiv
umsetzbar.
Schnelle Einfhrung
Die Einfhrung von Kanban ist erfahrungsgem mit wenig Widerstand verbunden.
Kanban an sich ist dabei leicht verstndlich und fr alle Beteiligten nachvollziehbar.
Quelle: http://www.it-agile.de/wissen/methoden/kanban/
7.6. Konsens die Basis des Kanban-Change
Vernderungen anzuordnen ist meist nicht gerade zielfhrend und erfolgreich. Genauso
wenig machen Entscheidungen Sinn, die ein Team vor vollendete Tatsachen stellen. Das
Prinzip Kanban fokussiert vor allem einen gemeinsamen Pfad und legt Wert auf gemeinsame
Entscheidungen, die fr Team, Management und weitere Stakeholder nachhaltige Vorteile
mit sich bringen. Ziel ist eine Win-Win-Win-Stituation. Im besten Fall durchlaufen dabei alle
beteiligten Parteien drei Phasen im Vernderungsprozess. (vgl.
http://www.heise.de/developer/artikel/Kanban-richtig-einfuehren-
1344554.html?artikelseite=2)
Sondierung: Allen Beteiligten ist bewusst, dass eine nderung notwendig ist
Engagement: Entwicklung einer gemeinsamen Vision sowie Definition von Tasks
und messbaren Zielen fr den Change Prozess
Durchfhrung: Umsetzung der Vision step-by-step und Beurteilung nach den
vereinbarten Kriterien
Ein hufiges Problem in der Praxis ist, dass die ersten beiden Punkte bersprungen werden
und dadurch Vernderungsprojekte schlielich scheitern.
TechDivision GmbH Agiles Projektmanagement "&
7.7. Sieben Schritte fr erfolgreiches Kanban
Ein wichtiges Ziel von Kanban ist es Prozesse und Arbeitsweisen zu optimieren. Meist ist es
sinnvoll mit dem wichtigsten Problem zu starten und weitere Probleme zu priorisieren. Das
Kanban-System wird dabei auf Grundlage gemeinsam definierter Ziele schrittweise
aufgebaut. Nach Konsens erfolgt die Visualisierung des Arbeitsflusses. Aus Kanban
entwickelt sich so ein Motor, der einen Wandel voran treibt. Nachfolgend werden die
einzelnen Schritte im Kanban nher beschrieben. (vgl.
http://www.heise.de/developer/artikel/Kanban-richtig-einfuehren-
1344554.html?artikelseite=2)
Schritt 1: Definition von Aufgaben
Im ersten Schritt erscheint es sinnvoll, dass ein oder mehrere Teams genau definieren, an
welcher Wertschpfungskette sie sich befinden. Welche Aufgaben fallen fr die jeweiligen
Teams an? Wer hat welche Verantwortung?
Schritt 2: Darstellung des Workflows
Arbeitsweisen werden in Form eines Kanban-Boards visualisiert und prsentiert. Hier spielt
das Team eine wichtige Rolle, welches die Kapazitten auf die einzelnen Arbeitstypen
einteilt. Der Vorteil dabei ist, dass sich der Arbeitsfluss gezielt steuern lsst, da hinter jedem
Task ein gewisser Arbeitsaufwand und Bedarf steht. So mssen beispielsweise Bugs sofort
bearbeitet werden.
Schritt 3: Laufende Tasks begrenzen
Wie bereits erwhnt, wird die Anzahl parallel laufender Arbeiten pro Arbeitsschritt begrenzt,
um einen effektiven Workflow garantieren zu knnen. Anhand des Boards kann so
visualisiert werden, wo gerade Engpsse bestehen oder der Arbeitsfluss ins Stocken gert.
Allerdings funktioniert das Work in Progress Prinzip nur dann, wenn Team, Management und
Stakeholder an einem Strang ziehen. Wie hoch das WIP-Limit anfangs gesetzt wird, ist
zunchst eine Gefhlsentscheidung. Wichtig ist dabei nur, dass man in einem Pull-System
arbeitet. Ziel ist es eine Balance zwischen der operativen Arbeit, Zeit fr Fehlerkennungen
sowie Problemlsungen halten zu knnen.
Schritt 4: Serviceklassen
Aufgaben haben unterschiedliche Prioritten und mssen daher differenziert und mit
entsprechenden Kapazitten behandelt werden. Serviceklassen betrachten dabei u. a. die
Cost of Delay. Damit sind die Auswirkungen auf den wirtschaftlichen Erfolg eines
Unternehmens gemeint. Hier spielt jedoch nicht nur Geld eine Rolle, sondern auch
Reputation, Kundenzufriedenheit, etc. Wie die Serviceklassen benannt werden ist
unternehmensspezifisch. Eine Mglichkeit wre beispielsweise in beschleunigt, fester
Liefertermin, Standard, etc., zu unterscheiden. Im Zusammenhang mit der Benennung von
Klassen erscheint es wichtig, Zeit-Impact-Zusammenhnge in jedem Business nher zu
betrachten.
Schritt 5: Aufstellen von Regeln
In diesem Schritt ist es wichtig, dass smtliche Serviceklassen mit gewissen Regeln und
Kapazitten hinterlegt werden. Diesbezglich muss klar definiert werden wie viele Aufgaben
aus welcher Serviceklasse hchstens in Arbeit sein drfen und wie die Vorgehensweisen des
Teams bei neu eingestellten Aufgaben sind.
Schritt 6: Messung der Ziele
Zur Messung der Ziele werden nicht einzelne Mitarbeiter bewertet, sondern immer das
System. Bei der Messung ist es dabei nicht wichtig auf die Kommastelle genau zu
TechDivision GmbH Agiles Projektmanagement (,
analysieren. Frei nach Russell Ackoff ist es besser, diejenigen Dinge unscharf zu messen,
die wirklich zu messen sind, als Dinge hochgenau zu analysieren, die einen nicht wirklich
weiterbringen. (Quelle: http://www.heise.de/developer/artikel/Kanban-richtig-einfuehren-
1344554.html?artikelseite=3)
Schritt 7: Implementierung im Betrieb
Im letzten Schritt ist es vor allem wichtig, den Zu- und Abfluss der Arbeit zu definieren, um
den Kanban-Prozess vorwrts zu bringen. In diesem Zusammenhang wird festgelegt, wie
Tickets auf dem Board landen. Diese Fragen werden in Queue Replenishment Meetings
besprochen, bei dem Stakeholder und Team festlegen, welche Aufgaben als nchstes
erledigt werden. Dabei rcken in der Praxis vor allem die Interessen des
Gesamtunternehmens in den Vordergrund. Die Aufgabe des Entwickler-Teams besteht dabei
darin, technische Entscheidungen zu treffen, whrend das Management den
unternehmerischen Kontext miteinflieen lsst. Beim sogenannten Daily Standup behandelt
das Team tglich seine Fragen zu seiner Arbeit und diskutiert dabei Engpsse und mgliche
Probleme. Vor allem am Anfang sind wchentliche Team-Retrospektiven unabdinglich. Der
Vorteil dabei ist, dass das Team Ergebnisse einer Woche nochmals Revue passieren lassen
kann, um genauer klren zu knnen, wo Vernderungsbedarf besteht. Bei der
Zusammenarbeit mehrerer Teams empfiehlt sich ein Operations Review, welches
bergreifende Probleme und Zusammenhnge fokussiert.
TechDivision GmbH Agiles Projektmanagement ('
8. Kanban vs. Scrum
Kanban hat sich vor allem bei projektbergreifenden Teams, bei kontinuierlichen, schlecht
planbaren Aufgaben und kleineren Projekten, die sich nicht in Iterationen teilen lassen
bewhrt und fhrt zu einem optimierten Workflow. Bei greren, komplexen und langfristig
angelegten Projekten eignet sich Scrum besser.
(Quelle: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/2/)
Sowohl Scrum als auch Kanban sind schlanke (lean) und agile Projektmanagementanstze,
die einiges gemeinsam haben, sich in bestimmten Punkten aber grundlegend unterscheiden.
Nachfolgend mchten wir die Gemeinsamkeiten und Unterschiede nochmals kurz darstellen:
Beide Anstze sind Lean und agil.
Beide Methoden setzen das Pull-Prinzip ein.
Bei beiden wird die Arbeit aufgeteilt.
Beide Anstze begrenzen die Work-In-Progress (WIP).
Bei beiden steht hchstmgliche Transparenz an oberster Stelle.
Bei beiden besteht das Ziel darin, mglichst schnell funktionsfhige und auslieferbare
Software zu generieren.
Bei beiden steht der Flow im Vordergrund. Teams organisieren sich dabei selbst.
Bei beiden wird der Releaseplan auf Basis empirischer Daten (Geschwindigkeit und
Durchlaufzeit) kontinuierlich verbessert.
Lean-Prinzipien stammen aus der japanischen Automobilindustrie. Dabei besteht das
oberste Ziel darin, die nachfolgenden drei Arten der Verschwendung mglichst zu verringern
bzw. zu unterbinden:
Muda Arbeit, die dem Produkt keinen Wert hinzufgt
Muri berlastung von Maschinen und Mitarbeitern
Mura Unregelmigkeit der Prozesse
Eines muss beim Einsatz von Lean-Methoden egal ob Scrum oder Kanban jedoch immer
bedacht werden. Durch diese Anstze und Prozesse werden entsprechende Vorgaben
eine Art Framework bereitgestellt. Die Umsetzung dieser Vorgaben kann jedoch nur durch
den Mensch unter Bercksichtigung entsprechender Disziplin, Kommunikation und
Motivation erfolgen, wodurch die genannten Verschwendungsarten unterbunden werden
knnen. Eine grundlegende Garantie fr Projekterfolgt stellen agile Methoden aber nicht dar.
8.1. Vorgaben bei Kanban
Bei Kanban gibt es im Prinzip nur zwei wesentliche Vorgaben. Ansonsten besteht hier sehr
groe Flexibilitt sowie entsprechender Gestaltungsspielraum, mit dem sich Kanban an die
individuellen Bedrfnisse anpassen lsst.
1. Visualisierung des Workflows
2. Limitierung des Work-In-Progress (WIP)
TechDivision GmbH Agiles Projektmanagement ("
8.2. Vorgaben bei Scrum
Im Vergleich zu Kanban geht Scrum deutlich restriktiver vor und stellt hier klarere Vorgaben
und Regeln auf. Wichtig dabei ist, dass das Team die einzige Rolle in Scrum darstellt, die mit
mehreren Personen besetzt ist. Eine der zentralen Vorgaben, mit denen alle wesentlichen
Punkte bei Scrum definiert werden, ist die sog. 3x3-Regel:
Drei Zeremonien
Daily Scrum die tgliche Einsatzbesprechung
Sprint Planung Planung eines Arbeitszyklusses (Sprint)
Sprint Review der Abschluss eines Sprints und die Abnahme des entsprechenden
Arbeitspaketes
Drei Artefakte
Product Backlog eine priorisierte Liste aller Anforderungen
Sprint Backlog eine Liste von Aufgaben zur Erfllung eines Arbeitspaketes
Inkrement das groe Projekt wird in mehren Inkrementen entwickelt
Drei Rollen
Product Owner zustndig fr den wirtschaftlichen Erfolg und das Endergebnis
Scrum Master wacht ber die Methodik und die Produktivitt des Teams
Team das selbst-organisierte, teilautonome Team
TechDivision GmbH Agiles Projektmanagement ((
8.3. Scrum und Kanban im direkten Vergleich
(Quelle: http://www.infoq.com/resource/news/2010/01/kanban-scrum-
minibook/en/resources/KanbanAndScrum-German.pdf)
8.4. Wann eignet sich Kanban und wann Scrum besonders?
Wie bereits eingangs erwhnt, handelt es sich bei beiden Projektmanagementanstzen um
agile Methoden, bei denen der Teamgedanke im Vordergrund steht.
Eine pauschale Empfehlung, wann Kanban und wann Scrum der bessere Ansatz ist, lsst
sich kaum treffen. Es knnen aber einige grundlegende Charakteristika der beiden Methoden
fr eine Entscheidung herangezogen werden.
Dabei sollten im Vorfeld insbesondere die folgenden Fragen geklrt werden:
Wie hoch ist die Komplexitt des Projektes?
Wie gro ist das Team fr die Realisierung?
Wie schnell und flexibel muss whrend der Implementierung reagiert werden
knnen?
Wie gro knnen entsprechende Iterationsschritte gewhlt werden?
In welcher Projektphase befindet man sich (Wartung/Weiterentwicklung vs. komplette
Neuentwicklung)?
TechDivision GmbH Agiles Projektmanagement ()
Hufig sind Softwareprojekte fr einen Scrum-Ansatz zu klein, da bei Scrum durch die
diversen Vorgaben und Rollen ein gewisser Projektmanagement-Overhead mitgeschleppt
wird.
Insofern hat sich in der Praxis gerade bei berschaubareren Projekten, bzw. insbesondere
bei Projekten in der Wartung und Weiterentwicklung, Kanban als sehr zielfhrender Ansatz
herausgestellt, da hier nur minimale Vorgaben gegeben werden und die anfallende Arbeit
insbesondere wenn sie nur schwer vorab planbar ist quasi auf Zuruf bzw. durch Notiz auf
Kanban-Karten erledigt werden kann. Aufgrund der anfallenden Tasks ist hier in der Regel
auch keine permanente Abstimmung mit dem gesamten Team erforderlich, wie dies bei
Scrum beispielsweise im Rahmen der Daily Standups vorgegeben wird.
Sofern das jeweilige Projekt allerdings eine entsprechende Grenordnung und Komplexitt
annimmt und hier ein greres Team zur Realisierung notwendig ist, kann Scrum seine
Strken ausspielen, indem durch klare Vorgaben und Prozesse ein sehr straffes Korsett zur
Bearbeitung eines solchen Projektes bereitgestellt wird. Dem Team wird dadurch die ntige
Sicherheit sowie ein entsprechender Rahmen bereitgestellt.
Auch wenn hier keine genaueren oder gar pauschalen Aussagen ber den jeweiligen PM-
Ansatz mglich sind, sollte man fr ein Scrum-Projekt ein Team mit 3-9 Entwicklern sowie
einen Product Owner und einen Scrum Master einsetzen.
Darber hinaus sollte das Projekt so bemessen sein, dass mind. 3 Sprints zur Realisierung
einer ersten Phase notwendig sind, um von den Vorteilen von Scrum auch mglichst
umfassend profitieren zu knnen. Dabei sind insbesondere die nachfolgenden Vorteile zu
nennen:
Striktes Vorgehen nach Prioritten
Sie erhalten regelmig funktionsfhige Zwischenstnde
Sie profitieren von Erkenntnissen aus dem QM
Sie gewinnen mehr Flexibilitt
Sie profitieren von aktuellen Entwicklungserkenntnissen
Die Arbeitslast verteilt sich besser
Scrum Teams arbeiten nachhaltig
Sie profitieren von erhhter Effizienz und Kostenvorteilen
TechDivision GmbH Agiles Projektmanagement (*
8.5. Von Wasserfall ber Scrum zu Kanban
Dass komplexe Webprojekte in der heutigen Zeit nicht mehr im Detail vorausgeplant werden
knnen, zeigt das nachfolgende Praxisbeispiel ber ein sehr umfangreiches Portal-Projekt,
das nach klassischer Vorgehensweise anhand eines vom Kunden gelieferten Lastenheftes
begonnen wurde. Im Projektverlauf hat sich dann jedoch sehr schnell gezeigt, dass
Definitionen und Vorstellungen aus der Konzeptphase in der Praxis aufgrund
unterschiedlichster Problematiken oder nderungen nicht umsetzbar waren bzw.
weitreichende Anpassungen notwendig wurden.
Dadurch wurde whrend des Projektes die Projektmanagementmethodik von Wasserfall hin
zu einem agilen Ansatz mittels Scrum gewechselt. Durch sehr kurzfristige
nderungswnsche auf Kundenseite konnte nach gewisser Zeit selbst eine Iteration mit 3-
wchigen Sprints nicht mehr aufrecht erhalten werden, wodurch am Ende zu Kanban als
agilster Projektmanagementform geswitcht wurde und das Projekt so am Ende erfolgreich
auf die Strae gebracht werden konnte.
(Quelle: http://www.youtube.com/watch?v=A5VUFMv2fuo)
TechDivision GmbH Agiles Projektmanagement (+
9. Vertragsgestaltung bei Webprojekten
Dr. Matthias Orthwein, LL.M. (Boston) / Daniel Memer
SKW Schwarz Rechtsanwlte
9.1. Klassisches oder agiles Projektmanagement?
Agilitt" ist auf dem Vormarsch. Im Vergleich zu einem klassischen Projektmanagement
werden agile Vorgehensweisen vor allem als kundengerechter, schneller und
kostengnstiger gepriesen. Warum das klassische Projektmanagement weiterhin eine
Daseinsberechtigung hat und welche rechtlichen und vertragsgestalterischen Stolpersteine
agile Projektmethoden mit sich bringen, wird in dem folgenden Beitrag dargestellt.
Wer plant, ein Webprojekt zu beauftragen oder seinen Online-Shop berarbeiten zu lassen,
hat meist eine gewisse Vorstellung von dem zu erzielenden Ergebnis. Oft stehen dabei zwar
Funktionalitten im Vordergrund; auch Design, Ergonometrie sowie look-and-feel werden
jedoch eine wesentliche Rolle spielen. Der Detailgrad der Vorstellung vor Vertragsschluss
variiert freilich sehr stark und ist von der (hufig fehlenden) Expertise des Kunden abhngig.
9.2. Probleme des klassischen Wasserfalls
Nach einer klassischen Vorgehensweise entsprechend dem Wasserfallmodell steht vor der
eigentlichen Projektumsetzung durch den Entwickler zunchst die Projektplanung. Ergebnis
dieser Planung ist in der Regel ein Feinkonzept (Pflichtenheft), in welchem das Projektziel
vollstndig umschrieben wird. Eventuell basiert dieses auf einem Lastenheft, in dem der
Kunde seine Anforderungen an das Projektziel grob beschrieben hat. Das Pflichtenheft wird
dabei in seltenen Fllen vom Kunden selbst, in den meisten Fllen jedoch gemeinsam von
Kunde und Entwickler erstellt. Erst nach Abschluss dieser Planung, also mit Fertigstellung
des Pflichtenheftes, beginnt die eigentliche Realisierung des Webprojektes. Die
Realisierungsphase baut dabei auf dem Ergebnis der Planungsphase auf.
Dieses lineare Vorgehen birgt allerdings eine Reihe systemimmanenter Projektrisiken, die
nicht selten Auslser von Auseinandersetzungen, Verzgerungen oder sogar
Projektabbrchen sind. Dem Kunden ist es auf der vorgelagerten, abstrakten Ebene hufig
nicht mglich, vor der Projektumsetzung die wichtigen von den unwichtigen oder
berflssigen Funktionen und Features zu unterscheiden. Aus Angst, in der Zukunft
erforderliche oder ntzliche Funktionen zu bersehen, ist das Pflichtenheft deshalb oft
berladen. Das fhrt nicht nur zu einer Verlngerung des Projektzeitraums, sondern auch
zu unntig hohen Kosten fr den Auftraggeber.
Ein ganz wesentliches Problem der klassischen Projektmethode liegt zudem auerhalb der
Kontrolle von Auftraggeber und Softwareentwickler: Es ist hufig nicht mglich, bereits bei
der Projektplanung vorauszusehen, welche Funktionen oder Schnittstellen zum Zeitpunkt der
Projektbeendigung tatschlich erforderlich, aktuell und state-of-the-art sind. Seit jeher
werden deswegen vertraglich Prozesse zur Aktualisierung des Vertragsgegenstandes im
Realisierungsprozess vereinbart (sog. Change Management). Damit soll das Projektziel
entsprechend der aktuellen technologischen Entwicklung und den neuen Anforderungen des
Kunden in der Umsetzungsphase angepasst werden. Der im klassischen
Projektmanagement angelegte statische Prozess wird damit flexibler gestaltet.
In der Praxis gibt das Verfahren zur nderung des Vertragsgegenstandes allerdings hufig
Anlass zu Diskussionen ber Machbarkeit, Umfang, Zeitverzgerung und zustzliche
Kosten. Gerade in einem stark volatilen technologischen Umfeld wie dem von Webprojekten
birgt das Change Management deswegen ein nicht unerhebliches Streit- und Risikopotential.
Der Grund dafr liegt im Change Management als Flexibilisierungsinstrument selbst. Denn
TechDivision GmbH Agiles Projektmanagement ($
im Rahmen einer klassischen Vorgehensweise stellt jede Flexibilisierung letztlich einen
Fremdkper dar, der den idealtypisch linearen Projektverlauf strt und behindert. Fr den
Auftraggeber bedeutet die Flexibilisierung, die er durch die Mglichkeit von Change
Requests erhlt, zudem in der Regel vor allem zustzliche ungeplante Kosten.
9.3. Agile Projektmethoden als Heilsbringer?
An diesen Schwachstellen linearer Entwicklungsmethoden setzt agiles Projektmanagement
an. Beispielhaft sei hier auf die weit verbreitete Scrum-Methode verwiesen: Statt eines
linearen Prozesses, in welchem die Projektplanung abstrahiert vor der Realisierung
stattfindet, werden Planungs- und Umsetzungsphasen gemeinsam in mehreren iterativen
Schleifen wiederholt. Zu Projektbeginn existiert allenfalls eine grobkrnig beschriebene
Projektvision, die sich im Rahmen des Prozesses zu einem detaillierten Projektziel hin
entwickelt. Im Vordergrund steht dabei die enge Zusammenarbeit von Entwickler und
Auftraggeber; alle Entscheidungen sollen gemeinsam besprochen und gemeinsam gefllt
werden. Auf Grundlage der Zwischenergebnisse der Entwicklung werden gemeinsam neue
Ideen entwickelt und ohne Denkverbote diskutiert. Die Flexibilitt ist dabei institutionalisiert:
Weiterentwicklungen und nderungen des Vertragsgegenstandes sind beabsichtigt und
Ausgangspunkt des Verstndnisses beider Parteien. Agilitt verspricht deswegen ein
besonders bedarfsgerechtes und zeitgemes Projektergebnis.
Obschon deshalb agiles Projektmanagement dem klassischen Vorgehen berlegen zu sein
scheint, ist absolute Agilitt fr viele Auftraggeber keine echte Option. Denn aufgrund der
starken Einbeziehung des Auftraggebers ber die gesamte Projektlaufzeit hinweg werden
Personalressourcen gebunden. Im Rckblick mag sich dieser Aufwand zwar auszahlen,
wenn das Ergebnis den Bedrfnissen des Auftraggebers in hohem Mae entspricht. Das ist
jedoch zunchst ungewiss. Deswegen scheuen sich viele Auftraggeber, mit diesem
Personalaufwand in Vorleistung zu treten. Hufig fehlt es auch schlicht an internen
Ressourcen mit ausreichendem Projekt-Know-How.
Ein weiteres wesentliches Problem ist die mangelnde Kostentransparenz: Da nicht feststeht,
was vom Auftragnehmer entwickelt werden soll, kann im vorhinein auch nicht feststehen,
was die Entwicklung am Ende kostet. Hufig wird versucht, diesen Aspekt durch eine
Festpreisvereinbarung zu entschrfen und Kostentransparenz zu schaffen (Agiler
Festpreis). Daraus folgt jedoch zwingend eine Einschrnkung der gestalterischen Freiheit.
Sollen neue Features umgesetzt werden, mssen im Gegenzug alte fallen gelassen werden.
Andernfalls werden die zustzlichen Kosten entsprechend dem Change Management
gesondert berechnet.
9.4. Was bedeutet Agilitt rechtlich?
Ungeachtet der Vor- und Nachteile beider Projektmethoden stellt sich aus
vertragsgestalterischer Sicht eine ganz grundlegende Frage: Welchem Vertragstypus sind
Softwarevertrge zuzuordnen und unterscheiden sich agile Softwarevertrge insoweit vom
klassischen Softwarevertrag?
Die vertragstypologische Einordnung hat ganz entscheidenden Einfluss auf die
Vertragsgestaltung. Denn das Brgerliche Gesetzbuch sieht fr eine Reihe von
Vertragstypen bestimmte Regelungen vor, die Anwendung finden, wenn die Parteien nicht
vertraglich etwas Abweichendes vereinbaren (z. B. in Bezug auf Gewhrleistungsregeln oder
Zahlungsmodalitten). Nur wenn feststeht, um welchen Vertragstyp es sich handelt, knnen
die Parteien (soweit das Gesetz dies zulsst) bewusst und individuell vom Gesetz
abweichende Vereinbarungen treffen. Auerdem sind und das ist insbesondere fr
TechDivision GmbH Agiles Projektmanagement (%
Auftragnehmer von Bedeutung, die ein Vertragsmuster verwenden die Mastbe einer
Kontrolle der Vertragsklauseln auf Vereinbarkeit mit dem AGB-Recht je nach Vertragstyp
unterschiedlich.
9.5. Gretchenfrage: Werk- oder Dienstvertrag?
Fr die Vertragsgestaltung von klassischen und agilen Vertrgen ist deswegen mageblich,
welcher Vertragstyp des BGB jeweils Anwendung findet.
Fr Vertrge ber Erstellung eines Online-Auftritts oder eines Web-Projekts kommt in erster
Linie eine werkvertragliche oder dienstvertragliche Einordnung in Betracht. Werk- und
Dienstvertrag unterscheiden sich wesentlich darin, dass der Auftragnehmer beim
Werkvertrag einen konkreten Erfolg schuldet, beim Dienstvertrag dagegen lediglich zum
Ttigwerden verpflichtet ist, ohne zugleich ein bestimmtes Ergebnis zu versprechen.
Dementsprechend ist beim Werkvertrag allein der Auftragnehmer fr den Projekterfolg
verantwortlich und Weisungen des Auftraggebers anders als beim Dienstvertrag nicht
unterworfen.
Die Unterscheidung ist vor allem deswegen relevant, weil das Werkvertragsrecht ein
Mngelhaftungsrecht (Gewhrleistung) vorsieht, das Dienstvertragsrecht allerdings nicht.
Vor allem der Auftragnehmer hat deswegen ein Interesse an dem Abschluss eines
Dienstvertrages.
9.6. Entscheidend ist der Vertragsinhalt
Auf Softwareerstellungsvertrge nach klassischer Vorgehensweise findet in aller Regel
Werkvertragsrecht (bzw. unter bestimmten Umstnden Werkliefer- und damit weitgehend
Kaufrecht) Anwendung. Der Auftragnehmer schuldet dabei eine dem Pflichtenheft
entsprechende Software und muss Abweichungen hiervon im Rahmen der
Sachmangelhaftung (Gewhrleistung) beseitigen.
Im technischen Umfeld wird fr Vertrge auf Grundlage eines agilen Projektmanagements
hufig davon ausgegangen, agile Projektentwicklung fhre zu einer dienstvertraglichen
Einordnung des Vertrages, da kein Pflichtenheft vorliegt und die Parteien gemeinschaftlich
auf den Projekterfolg hinarbeiteten, sodass nicht nur der Auftragnehmer die Verantwortung
fr den Projekterfolg trage. Die Entscheidung agil oder klassisch htte damit auch
wesentliche juristische Bedeutung: Agil wre grundstzlich gnstiger fr den Auftragnehmer.
Eine pauschale Differenzierung klassisch = Werkvertrag, agil = Dienstvertrag ist allerdings
falsch und irrefhrend. Richtig ist lediglich, dass die juristische Klassifizierung eines
Softwareerstellungsvertrages auf agiler Basis Schwierigkeiten bereiten kann und im Einzelfall
mglicherweise vom klassischen Modell abweicht. Fr die vertragliche Einordnung eines
Vertrages entscheidend sind allerdings nicht die berschrift oder Schlagwrter, die den
Vertragsinhalt beschreiben. Mageblich sind allein die tatschlich vereinbarten
Vertragspflichten, in erster Linie diejenigen des Auftragnehmers.
Ein Softwareerstellungsvertrag auf agiler Basis kann also durchaus auch Werkvertrag sein.
Schlielich erwartet der Auftraggeber in der Regel ein fr ihn nutzbares Ergebnis als
Vertragserfolg. Auerdem legen die Parteien auch bei agiler Vorgehensweise hufig ein
wenn auch vages Projektziel fest (z. B. Erstellung eines Web-Auftritts), das den Rahmen
der Entwicklung vorgibt. Verpflichtet sich der Auftragnehmer, die Verantwortung fr das
Erreichen dieses Projektziels zu bernehmen, ist grundstzlich von einem Werkvertrag
auszugehen.
Um also tatschlich zur Anwendung des Dienstvertragsrechts zu gelangen, msste
TechDivision GmbH Agiles Projektmanagement (&
ausdrcklich vereinbart werden, dass der Auftragnehmer keinen Erfolg schuldet, sondern
umgekehrt der Auftraggeber die Verantwortung fr den Projekterfolg trgt. Der Auftraggeber
kauft bei dieser Gestaltung also letztlich Programmierzeit des Auftragnehmers, ohne eine
konkrete Zusage fr das Ergebnis zu bekommen.
Aus mehreren Grnden ist eine solche Vertragsgestaltung allerdings problematisch: Der
Auftraggeber ist nur in den seltensten Fllen bereit, das alleinige Risiko fr den Projekterfolg
zu bernehmen. Es ist auch nicht recht plausibel, dass der Auftraggeber als technischer Laie
die Verantwortung behlt und der Auftragnehmer als Experte keine Erfolgsverantwortung
bernimmt. Schlielich passt diese Konstruktion nicht zu dem Umstand, dass in der Regel
der Auftragnehmer das Projekt steuert, wenn auch mit Untersttzung des Auftraggebers.
Den Softwareerstellungsvertrag als reinen Dienstvertrag zu gestalten, ist also zwar rechtlich
mglich, allerdings in der Praxis wohl kaum gegenber dem Auftraggeber durchsetzbar und
in den meisten Fllen nicht interessengerecht.
9.7. Bedarfsgerechte Vertragsgestaltung
Ziel der Vertragsgestaltung muss es deswegen sein, einen gleichermaen bedrfnis- wie
interessengerechten Zwischenweg zu finden.
Insbesondere bei Scrum knnen etwa die Planung der Sprints (Sprint-Plannings) und das
Sprint-Review sowie Scrum-Meetings auf Ebene eines Dienstvertrages geregelt werden.
Fr die einzelnen Sprints kann davon abweichend eine werkvertragliche oder
werkliefervertragliche Gestaltung gewhlt werden. Geschuldet ist dann jeweils ein Ergebnis
mit der Funktionalitt wie im Sprint-Backlog beschrieben.
Die so erzielte Aufspaltung in viele kleinere Werkvertrge vermindert das Risiko auf beiden
Seiten. Flexibilitt wird dadurch sichergestellt, dass beide Parteien nach jedem oder einer
bestimmten Zahl von Sprints den Vertrag kndigen knnen. Dabei kann entweder anhand
des voraussichtlichen Aufwands die Vergtung eines einzelnen Sprints jeweils separat
vereinbart, oder vertraglich ein fester Preis pro Sprint festgelegt werden.
Dies fhrt zwar mglicherweise ideologisch zu einer Vermengung von agiler und klassischer
Entwicklungsweise. Zum einen scheint eine Zwischenlsung jedoch aus
Interessengesichtspunkten sachgerecht und zum anderen ermglicht sie auch konservativen
Auftraggebern, die Vorteile agiler Entwicklungsmethoden nutzen zu knnen, ohne vollstndig
auf die gewohnte Projektumgebung verzichten zu mssen.
Letztlich ist fr die Vertragsgestaltung also nicht die Projektmethode mageblich.
Entscheidend ist die Ausgestaltung der Zusammenarbeit fr das konkrete Projekt. Erst auf
dieser Basis kann ein sachgerechter Vertrag berhaupt entworfen werden. Inwieweit Werk-
und Dienstvertrag diese Gestaltung beeinflussen, ist allein abhngig von dem Parteiwillen
und nicht nur an die Frage der Projektmethode geknpft.
9.8. Zusammenfassung
Agil oder klassisch? Aus vertragsgestalterischer Sicht ist die Frage nur von untergeordneter
Bedeutung. Entscheidend ist letztlich, dass der Vertrag das von den Parteien beabsichtigte
Vorgehen abbildet und alle wesentlichen rechtlichen Punkte, die damit in Zusammenhang
stehen, regelt. Das setzt voraus, dass sich die Parteien ber die grundlegenden Aspekte der
Vorgehensweise bei der Projektumsetzung und ber die Verteilung der Verantwortlichkeiten
fr den Projekterfolg einig sind. Dazu gengt es nicht, sich auf ein agiles Vorgehen zu
einigen. Denn das sagt noch nichts Konkretes ber die Leistungspflichten aus und lsst eine
Einordnung des Vertrages und eine sachgerechte Vertragsgestaltung nicht zu.
TechDivision GmbH Agiles Projektmanagement ),
Ebenso wenig wie deswegen aus agil zwingend die Anwendung des Dienstvertragsrechts
folgt, sollten sich die Parteien ausschlielich von vertragstypologischen Erwgungen leiten
lassen. Entscheidend ist eine rechtlich ausgewogene Lsung auf Grundlage der parteilichen
Zusammenarbeit. Da diese von Fall zu Fall divergiert bedarf hufig auch der Vertrag einer
bedarfsgerechten Gestaltung ganz im Sinne des agilen Projektmanagements.
TechDivision GmbH Agiles Projektmanagement )'
10. Fazit
Klassisches Projektmanagement ist meist mit viel Aufwand, Arbeit, festen Strukturen und
detaillierten Vertrgen verbunden. Ein weiteres Problem ist, dass das Projektmanagement
nach dem klassischen Wasserfallmodell oft die Wnsche des Kunden nicht ausreichend
erfllen kann, da insbesondere E-Commerce-Projekte mitunter einer enormen Dynamik
unterliegen. Agiles Projektmanagement erlaubt dagegen einen Auftrag zielgerichteter zu
fokussieren und auch in spten Projektphasen kurzfristig auf nderungen reagieren zu
knnen. Flexibilitt gewinnt in Projekten immer mehr an Bedeutung und Kunden erwarten
mageschneiderte Lsungen fr ihre individuellen Bedrfnisse Scrum, Kanban und Co.
garantieren dabei ein zielorientiertes Vorgehen und helfen dabei, Projekte erfolgreich und
effizient abzuwickeln.
TechDivision GmbH Agiles Projektmanagement )"
11. Autoren
Josef Willkommer, Geschftsfhrer TechDivision
Als Geschftsfhrer von TechDivision beschftigt sich Josef Willkommer seit vielen Jahren
sehr intensiv mit Themen aus den Bereichen E-Commerce, Online Marketing und den dazu
notwendigen, modernen Projektmanagement-Anstzen. Darber ist er als Chef-Redakteur
des eStrategy-Magazins einem quartalsweise erscheinenden, kostenlosen Online-Magazin
mit Fokus auf E-Commerce und Online Marketing auch journalistisch ttig und versucht
sein Wissen in Form von Fachbeitrgen weiterzugeben. Auch auf diversen Fachkonferenzen
trifft man ihn als Referent zu Themen rund um den elektronischen Handel.
Sacha Storz, Standortleitung Mnchen / Business Development
Sacha Storz ist als Certified Scrum Product Owner (CSPO) und Certified Scrum Professional
(CSP) offiziell von der Scrum Association zertifiziert. Als Agile Evangelist ist er fr das
Business Development und den Auf- und Ausbau des Standortes Mnchen von TechDivision
verantwortlich. Als ausgebildeter Psychologe gilt sein besonderes Interesse neben
Projektmanagement dabei dem Thema moderne Unternehmenskultur(en) und Leadership.
Dominik Haller, Online Marketing Manager / Projektmanager
Der studierte Kommunikationswissenschaftler arbeitet als Online Marketing Manager bei der
TechDivision GmbH und ist fr das Content Management, Partnermanagement, fr die
Eventorganisation sowie smtliche Marketingaktivitten online / offline zustndig. Darber
hinaus ist er als leitender Redakteur und Autor des eStrategy Magazins fr
Hintergrundrecherchen rund um das Thema E-Commerce, Online Marketing, E-Recht, etc.
zustndig. Neben seiner beruflichen Ttigkeit bei der TechDivision GmbH engagiert er sich
auch als Lehrbeauftragter an der Universitt Salzburg.
Michael Schubart, Online Marketing Manager / Projektmanager
Michael Schubart ist als Certified Scrum Product Owner (CSPO) und Certified Scrum
Professional (CSP) offiziell von der Scrum Association zertifiziert. Als Product Owner ist er
innerhalb von Projekten erster Ansprechpartner sowohl fr den Kunden als auch fr externe
Agenturen und leitet und koordiniert interne Planungsmeetings. Er erarbeitet und priorisiert
gemeinsam mit dem Kunden und Entwickler-Team die Projektanforderungen und untersttzt
den Kunden bei der Produktentwicklung und der Produktvision. Als Autor schreibt er
Fachbeitrge zu unterschiedlichsten E-Commerce und Online Marketing Themen und ist im
Rahmen von Fachkonferenzen auch als Journalist ttig.
Externe Autoren
Dr. Matthias Orthwein, LL.M. (Boston) / Daniel Memer
SKW Schwarz Rechtsanwlte
TechDivision GmbH Agiles Projektmanagement )(
12. ber TechDivision
Die TechDivision GmbH ist eine etablierte Internetagentur mit Standorten in
Rosenheim/Kolbermoor sowie Mnchen und Lbeck. Als kompetenter Partner untersttzt sie
seit vielen Jahren namhafte nationale und internationale Kunden wie Ritter-Sport, American
Express, Meggle oder Ferrero bei der ganzheitlichen Planung, Konzeption und Umsetzung
von webbasierten Technologien.
Als Magento Gold Partner und TYPO3 Association Gold Member gehrt TechDivision zu den
fhrenden Adressen fr anspruchsvolle Magento- und TYPO3-Lsungen und ist auch an der
Entwicklung des zukunftsweisenden TYPO3 Neos mageblich beteiligt. Neben der
Entwicklung auf Basis von Open Source Technologien bietet TechDivision ber ihre Online
Marketing Unit die TechDivision eConsulting zustzliche Leistungen rund um das Thema
Performance-Marketing wie SEO/SEA, Usability- und Conversion-Optimierung, Webtracking,
Social Media sowie weitere eConsulting-Leistungen an.
Mehr Informationen zu TechDivision finden Sie unter http://www.techdivision.com.
Certified Scrum Professionals bei TechDivision
Wir reden nicht nur ber agiles Projektmanagement, wir sind darin auch Experten und bilden
uns in diesem Bereich gezielt fort. Unsere Kunden erleben dabei agiles Projektmanagement
auf hohem Niveau und werden von einem erfahrenen Scrum-Team begleitet und bei Bedarf
auch geschult. Insgesamt gibt es in Deutschland 137 Certified Scrum Professionals, die in
der Scrum Alliance gelistet sind davon sind vier im TechDivision-Team vertreten:
Florian Dinauer (SM, CSP)
Stefan Regniet (SM, CSP)
Michael Schubart (CSPO, CSP)
Sacha Storz (CSPO, CSP)
Neben unseren Certified Scrum Professionals verfgen wir natrlich auch noch ber weitere
Certified Scrum Product Owner und Certified Scrum Master, die ihre Expertise und ihr Know-
How in Kundenprojekte einflieen lassen.
Quelle: http://www.scrumalliance.org/community/member-
directory.aspx?firstname=&lastname=&email=&location=Germany&company=&csm=False&
csd=False&csp=True&cspo=False&cst=False&csc=False&rep=False&author=False&orderby
=&sortdir=&page=3
TechDivision GmbH Agiles Projektmanagement ))
Sie haben Fragen?
Wir stehen Ihnen telefonisch und per Mail gerne zur Verfgung und freuen uns auf eine
gemeinsame und erfolgreiche Zusammenarbeit!
TechDivision GmbH
Turning online projects into success
Spinnereiinsel 3a
83059 Kolbermoor
Balanstr. 73, Haus 8, 3.OG
81541 Mnchen
Willy-Brandt-Allee 31c
23554 Lbeck
Tel.: +49 8031 / 22 10 55 0
Fax: +49 8031 / 22 10 55 22
[email protected]
www.techdivision.com