FOM Fachhochschule für Ökonomie und Management Standort Essen. Berufsbegleitender Studiengang Master of Arts IT-Management

Transkript

1 FOM Fachhochschule für Ökonomie und Management Standort Essen Berufsbegleitender Studiengang Master of Arts IT-Management Seminararbeit im Fach Software-Engineering, Projekt- und Qualitätsmanagement Titel der Seminararbeit Agile Entwicklungsmethoden - Kanban für die Softwareentwicklung Betreuer: Autor: Dr. Gregor Sandhaus Dominik Abs Matrikelnummer: Bearbeitungszeitraum: Wuppertal, den

2 Inhaltsverzeichnis - i - Inhaltsverzeichnis Inhaltsverzeichnis... i Abkürzungsverzeichnis... ii Abbildungsverzeichnis... iii 1 Einleitung Begriffsdefinitionen Kanban Agile Softwareentwicklung Kanban für die Softwareentwicklung Visualisierung der Wertschöpfungskette Begrenzung paralleler Arbeit Pull statt Push Kaizen Kanban vs. Scrum Rollen und Prozesse Timeboxes Scrumboard vs. Kanbanboard: Umgang mit Anpassungen Gemeinsamkeiten Fazit Literaturverzeichnis... I

3 Abkürzungsverzeichnis - ii - Abkürzungsverzeichnis DIY-Bereich IT PPS-System ROI RUP WIP Do-it-yourself-Bereich Informationstechnik Produktionsplanungs- und steuerungssystem Return on Investment Rational Unified Process Work in Progress

4 Abbildungsverzeichnis - iii - Abbildungsverzeichnis Abbildung 1: Visualisierung einer Wertschöpfungskette im Entwicklungsprozess... 7 Abbildung 2: Pull-Prinzip... 9 Abbildung 3: Umgang mit Problemen... 10

5 1 Einleitung Einleitung Die vorliegende Seminararbeit im Fach Software-Engineering, Projekt- und Qualitätsmanagement befasst sich mit dem Thema Agile Entwicklungsmethoden - Kanban für die Softwareentwicklung. Kanban ist ein agiles Projektmanagement Framework, das erst seit Anfang des 21. Jahrhunderts im IT-Bereich eingesetzt wird. Der Begriff agiles Projektmanagement Framework verrät bereits an dieser Stelle, dass Kanban, wie z.b. Scrum auch in den Bereich der agilen Softwareentwicklung einzuordnen ist. Ähnlich wie Scrum handelt es sich bei Kanban um eine Projektmanagement Methode, in deren Fokus die Organisation der Entwicklung in einem Software-Projekt steht. Kanban bietet hingegen keine Richtlinien dafür, wie ein einzelner Entwickler entwickeln soll. Das letzte Wort Framework lässt darauf schließen, dass Kanban kein vollständiges Vorgehensmodell für die Softwareentwicklung bietet, wie es z.b. das Modell des Rational Unified Process (in der Folge kurz: RUP) bietet. RUP stellt ein Verfahrensmodell zur iterativen Softwareentwicklung zur Verfügung. In diesem Modell sind die einzelnen Phasen und Rollen innerhalb eines Projekts klar definiert. Im Gegensatz dazu stellt Kanban ausschließlich einen Werkzeugkoffer zur Verfügung. Dieser Werkzeugkoffer bietet Leitfäden, Motivation und Werte. Er bietet jedoch auch sehr viel Spielraum bzw. Freiraum, welche Werkzeuge davon eingesetzt werden. Ziel dieser Seminararbeit ist es, Kanban als agiles Projektmanagement Framework für die Softwareentwicklung vorzustellen und die Möglichkeiten und Grenzen dieser Methode herauszuarbeiten. Dazu wird im Folgenden zunächst der Begriff Kanban definiert und der Ursprung in der Automobilindustrie kurz beschrieben. Anschließend wird aufgezeigt, wie Kanban in der Softwareentwicklung erfolgreich eingesetzt werden kann. Hierzu werden die Methoden und Werte diese Frameworks vorgestellt. Des Weiteren erfolgt eine Gegenüberstellung mit der deutlich bekannteren agilen Methode Scrum. Abgeschlossen wird diese Arbeit durch ein Fazit, in dem die wesentlichen Erkenntnisse dieser Arbeit noch einmal zusammengefasst und durch eine persönliche Einschätzung für die Einführung in einem Unternehmen bewertet werden.

6 2 Begriffsdefinitionen Begriffsdefinitionen In den nachfolgenden Abschnitten werden die in dieser Arbeit grundlegenden Begriffe Kanban und agile Softwarewareentwicklung beschrieben. 2.1 Kanban Die vorliegende Seminararbeit beschäftigt sich damit, wie Kanban als agiles Projektmanagement Framework für die Softwareentwicklung erfolgreich eingesetzt werden kann. Um den Kanban-Ansatz zu verstehen, werden im Folgenden kurz der Ursprung sowie der Prozess von Kanban beschrieben. Kanban ist ein Produktionsplanungs- und steuerungssystem, kurz PPS-System, welches bereits Mitte des 20. Jahrhunderts durch den Japaner Taiichi Ohno entwickelt und bei der Toyota Motor Company eingesetzt wurde. Der Begriff Kanban setzt sich aus den beiden Wörtern kan und ban zusammen und kann sinngemäß mit Signalkarte übersetzt werden. Ziele von Kanban waren die Steigerung der Produktivität und die Senkung der Kosten, um im Wettbewerb mit amerikanischen Konkurrenzunternehmen bestehen zu können. 1 In der Fertigungssteuerung nach Kanban werden die speziellen Verhältnisse Japans berücksichtigt: Rohstoffknappheit, geringe Baufläche, Unternehmensverbundenheit sowie stark ausgeprägtes Gruppendenken. Speziell die beiden erstgenannten Punkte verursachen hohe Lagerkosten und haben die Überlegungen einer ausschussfreien Produktion vorangetrieben. 2 Aufgrund hoher Zins- und Lagerkosten wurde die Idee entwickelt, jedes Produktionsgut erst dann zu beschaffen, wenn es benötigt wird. Diese Überlegungen werden als Just-in-Time-Produktion bezeichnet und sind die Basis des Kanban-Systems. 3 Der wesentliche Unterschied zu traditionellen PPS-Systemen besteht darin, dass die Fertigungssteuerung in den einzelnen Prozessschritten nicht zentral koordiniert wird. Vielmehr sieht Kanban die einzelnen Fertigungsstellen als selbstregulierende Regelkreise Vgl. Geiger, G., et al. (2003), Seite 16. Vgl. Wöhe, G. (2002), Seite 450. Vgl. ebenda. Jung, H. (2006), Seite 524.

7 2 Begriffsdefinitionen Dies führt dazu, dass in der Produktion befindliche Werkstücke nicht bei nachgelagerten Fertigungsschritten auf die Weiterverarbeitung warten müssen. Vielmehr wird der Anreiz zur Fertigung von den nachgelagerten Prozessschritten ausgelöst und ein Holprinzip etabliert. Hierbei kann von einem vorwärts gerichteten Materialfluss und einem rückwärts gerichteten Informationsfluss gesprochen werden. Werden an einzelnen Fertigungsstellen Material-Mindestbestände unterschritten, werden diese bei der vorgelagerten Fertigungsstelle angefordert. Die Kommunikation zwischen den jeweiligen Fertigungsstellen erfolgt dabei über die namensgebende Kanban-Karte. Diese enthält u.a. die benötigte Teilebezeichnung, die Mindestmenge sowie den Termin, an dem die Fertigungsteile benötigt werden. Die maximale Anzahl der Kanban-Karten je Fertigungseinheit ist dabei begrenzt. Die Lagerung der Fertigungsteile zwischen den Fertigungsstellen erfolgt in sogenannten Materialbehältern. 5 Die Definition der Teilemengen pro Materialbehälter und der Anzahl der eingesetzten Kanbans stellen die größten Herausforderungen dieses Produktionsplanungsverfahrens dar. Eine zu niedrig bemessene Anzahl an Materialbehältern kann den Produktionsfluss empfindlich stören. Wird in den Materialbehältern ein zu großer Bestand vorgehalten, führt dies wiederum zu höheren Lagerkosten 6. Eine allgemeine Regel zur Lösung dieser Problemstellung gibt es im Kanban- Verfahren nicht. Kanban sieht vielmehr vor, diesen Prozess durch kontinuierliche Verbesserungen an ein Optimum heranzuführen. 2.2 Agile Softwareentwicklung Der zweite Begriff, der in dieser Seminararbeit immer wieder verwendet wird, ist die agile Softwareentwicklung. Agile Softwareentwicklung ist erst seit den 1990er Jahren bekannt und gewann nach der Veröffentlichung des Buches Extreme Programming von Kent Beck im Jahre 1999 immer mehr an Bedeutung. Der Begriff agil wird erst seit 2001 verwendet und löste den bis dahin gebräuchlichen Begriff leichtgewichtig ab. 5 6 Vgl. Jung, H. (2006), Seite 524. Vgl. Jung, H. (2006), Seite 525.

8 2 Begriffsdefinitionen Doch was war der Anlass für eine Neuausrichtung, weg von traditionellen Vorgehensmodellen in der Softwareentwicklung, wie z.b. dem V-Modell oder dem Rational Unified Process? Hauptkritikpunkte an diesen traditionellen Methoden sind mangelnde Flexibilität, mangelnde Einbeziehung des Kunden in den Entwicklungsprozess und ein zu großer Dokumentationsaufwand. Um zu verstehen, was mangelnde Flexibilität bedeutet, muss man nur das sehr standardisierte RUP-Modell mit seinen mehr als 30 Rollen, mehr als 20 Aktivitäten und den mehr als 70 Artefakten betrachten. Es liegt auf der Hand, dass ein dermaßen standardisiertes Modell nicht flexibel eingesetzt werden kann, geschweige denn in der Lage ist, flexibel auf sich ändernde Anforderungen in einem laufenden Entwicklungsprojekt zu reagieren. Ziel der agilen Softwareentwicklung ist es, die drei genannten Nachteile zu beheben. Dies bedeutet konkret ein höheres Maß an Flexibilität, ständige Interaktion mit den Kunden und nur ein Mindestmaß an Dokumentation. Die Grundlage hierfür bildet das agile Manifest, das ebenfalls im Jahre 2001 veröffentlicht wurde: 7 Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen. Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation. Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen. Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung. 8 Durch agile Softwareentwicklung soll eine funktionsfähige Software-Lösung mit höchstmöglicher Qualität schnellstmöglich ausgeliefert werden. Bereits durch den ersten Satz des agilen Manifests wird deutlich, dass die Interaktion und enge Zusammenarbeit mit dem Kunden dabei eine zentrale Rolle spielt. Nur durch die Interaktion mit dem Kunden kann ein flexibler Umgang mit Anforderungen oder die Rückmeldung auf ausgelieferte Software gewährleistet werden. 9 Das inzwischen bekannteste und weitverbreitetste agile Vorgehensmodell ist das im Jahre 2001 vorgestellte Scrum. Die Grundlagen zu Scrum werden in dieser Seminararbeit vorausgesetzt. Kanban als agiles Projektmanagement Framework für die Softwareentwicklung ist jünger und wurde erst im Jahre 2007 öffentlich durch David J. Anderson vorgestellt Vgl. Schatten, A., et al. (2010), Seite 62. Vgl. Beck, et al. (2001), URL: Stand Vgl. Schatten, A., et al. (2010), Seite 62.

9 3 Kanban für die Softwareentwicklung Wie sich der ursprüngliche Kanban-Ansatz auf Softwareentwicklungsprojekte übertragen lässt und welche Vorzüge Kanban im Gegensatz zu traditionellen Vorgehensmodellen oder auch moderneren Ansätzen wie Scrum bietet, wird in den folgenden Kapiteln beschrieben. 3 Kanban für die Softwareentwicklung Die Grundidee von Kanban lässt sich nicht 1:1 auf die besonderen Bedürfnisse und Anforderungen an die Softwareentwicklung übertragen. Sowohl in der Fertigung als auch in der Softwareentwicklung handelt es sich bei Kanban um ein schlankes Verfahren. In der schlanken Produktion wird allerdings in der Regel in jeder Fertigungseinheit sehr monotone und dadurch wenig kreative Arbeit gefordert und durchgeführt. In der Softwareentwicklung werden zwar grundlegende Prinzipien der schlanken Produktion übernommen, nicht jedoch konkrete Praktiken. Dies liegt u.a. daran, dass die Arbeit innerhalb eines Projektes und projektübergreifend inhaltlich stark variiert und als sehr kreative Tätigkeit gesehen werden kann. 10 Die weiteren Aspekte von Kanban, wie z.b. die Vermeidung langer Langerzeit finden auch im Vorgehensmodell für die Softwareentwicklung Berücksichtigung. Kanban ist ein agiles Projektmanagement Framework für die Softwareentwicklung. Dies bedeutet, auch in Kanban wird das Ziel verfolgt eine schnelle Durchlaufzeit zu erzielen und fertige Software schnellstmöglich auszuliefern. Die Gründe sind offensichtlich: eine schnelle Auslieferung eines Produktes führt zu einem früheren Return on Investment (ROI). Ein weiterer Grund ist die Positionierung am Markt. Dabei kann es sowohl Ziel sein, ein Produkt als Erster zu veröffentlichen und damit deutliche Wettbewerbsvorteile gegenüber der Konkurrenz zu erzielen, als auch als sogenannter Fast Follower schnell mit einem Produkt nachzuziehen, um den Anschluss zum Wettbewerb nicht zu verlieren oder durch höhere Qualität selbst wieder einen Wettbewerbsvorteil zu erreichen. Eine schnelle und regelmäßige Auslieferung von Softwareständen steigert außerdem das Vertrauensverhältnis zum Kunden und führt dadurch zu höherer Kundenzufriedenheit. Letztes Argument für eine schnelle Auslieferung ist, dass auch das Kundenfeedback schneller erfolgt und so sichergestellt werden kann, dass der Kunde auch wirklich das Produkt be- 10 Vgl. Roock, A., Wolf, H. (2010), Seite 12.

10 3 Kanban für die Softwareentwicklung kommt, das er gefordert hat. 11 Diese Gedanken geben die Grundidee agiler Softwareentwicklung komprimiert wieder. In Kanban wird nun versucht, diese Ideen mit Hilfe von vier Elementen umzusetzen: 1. Visualisierung der Wertschöpfungskette: Informationen werden transparent und damit für alle Stakeholder ersichtlich. 2. Pull statt Push: Arbeit wird genommen und niemals gegeben. 3. Begrenzung paralleler Arbeit: Die Anzahl der zu bearbeiten Mengen ist limitiert. 4. Kaizen: Kanban fördert den kontinuierlichen Verbesserungsprozess. 12 Diese vier Elemente werden in den folgenden Kapiteln ausführlich vorgestellt. 3.1 Visualisierung der Wertschöpfungskette Die Visualisierung der Wertschöpfungskette eines Geschäftsprozesses ist der erste Schritt bei der Einführung von Kanban in einem Unternehmen. Zu diesem Zwecke wird in Kanban mit einem Kanbanboard gearbeitet. Auf diesem Kanbanboard sollen alle Prozessschritte, die die Software von der Entstehung bis zur Auslieferung durchläuft, dargestellt werden. Es wird empfohlen, den Prozess so abzubilden, wie er aktuell im Unternehmen gelebt wird, nicht, wie er idealerweise gelebt werden sollte. Nur so kann das Kanbanboard wiederspiegeln, womit die Teammitglieder aktuell beschäftigt sind und als Grundlage zu einer Optimierung des bestehenden Prozesses beitragen. 13 Über das Kanbanboard sollte nur der Bereich im Entwicklungsprozess visualisiert werden, der kontrolliert werden kann. Ein Prozess könnte zum Beispiel damit beginnen, dass Anforderungen bzw. Aufgaben in einem zentralen Dokument, dem Backlog gesammelt werden. Das Backlog stellt wie in Scrum die Sammlung aller priorisierten und für die Entwicklung vorbereiteten Themen dar, daher kann das Backlog auch als Themenspeicher bezeichnet werden. Die einzelnen Themen werden häufig in Form von User-Stories formuliert. Weitere Aufgabentypen können z.b. Use Cases, Change Requests oder auch Fehler im Produktivsystem sein. Wie bei Scrum auch, werden die Aufgaben häufig auf Karteikarten festgehalten Vgl. Roock, A., Wolf, H. (2010), Seite Vgl. Epping, T. (2011), Seite Vgl. Anderson, D. (2011), Seite Vgl. Anderson, D. (2011), Seite 72.

11 3 Kanban für die Softwareentwicklung Aus dem Backlog werden die Aufgaben für die Entwicklung eingeplant, werden entwickelt und nach erfolgreichem Test entsprechend ausgeliefert und produktiv zur Verfügung gestellt. Jeder dieser Prozessschritte stellt im Kanbanboard eine eigene Spalte dar. Abbildung 1 zeigt beispielhaft die Visualisierung einer einfachen Wertschöpfungskette im Entwicklungsprozess. Roock, A., Wolf, H. (2010), Seite 13. Abbildung 1: Visualisierung einer Wertschöpfungskette im Entwicklungsprozess Durch die Visualisierung der Aufgaben am Kanbanboard wird schnell ersichtlich, welche Aufgabe in welcher Zeit die Wertschöpfungskette durchläuft und an welcher Stelle Schwierigkeiten auftreten. Wie auch bei Scrum wird empfohlen, einfache Mittel zur Visualisierung zu verwenden, z.b. ein Whiteboard oder eine Metaplanwand. Zum einen können diese Mittel flexibel an projektindividuelle Gegebenheiten angepasst werden, zum anderen sind die Informationen an einem echten Board für das Projektteam leichter zugänglich, als bspw. über ein Dateisystem mit verschiedenen Berechtigungen. Bereits in Scrum wird betont, dass es sich positiv auf das Team auswirkt, wenn Aufgaben tatsächlich greifbar sind und manuell in eine andere Phase verschoben werden können. Auch bei räumlich getrennten Teams ist die Arbeit mit echten Whiteboards nicht unüblich. Hier muss allerdings sichergestellt werden, dass die Informationen mindestens täglich synchronisiert werden Vgl. Epping, T. (2011), Seite 59.

12 3 Kanban für die Softwareentwicklung Begrenzung paralleler Arbeit In Scrum ist die Anzahl der zu bearbeitenden Aufgaben in einem Sprint limitiert. Das Limit ist abhängig von der Sprintlänge, die üblicherweise zwischen einer und vier Wochen variiert, und der Velocity des Teams, d.h. der Geschwindigkeit, mit der Tickets abgearbeitet werden. Letzteres ist in Scrum ein Erfahrungswert, der in jedem Scrum-Team individuell variieren wird. In Kanban gibt es keine Iterationen, also gibt es auch keine maximale Anzahl an Tickets bzw. Aufgaben, die für ein Entwicklungsteam eingeplant werden müssen. Vielmehr wird in Kanban die Menge der Aufgaben in jeder Spalte der Wertschöpfungskette, an den gleichzeitig gearbeitet wird, begrenzt. 16 Die Tickets, die aktuell bearbeitet werden, werden als WIP (Work in Progress) bezeichnet. Die Kennzahl WIP wird also durch die Begrenzung paralleler Arbeit reduziert. Gleichzeitig wird durch die Begrenzung der Arbeit jedoch auch vermieden, dass einzelne Personen überlastet werden. Dadurch, dass konzentriert an einer Aufgabe gearbeitet werden kann, wird die durchschnittliche Durchlaufzeit einer Aufgabe reduziert. 17 Grundlage hierfür ist der Zusammenhang, den John D.C. Little 1961 unter dem Titel Little s Law veröffentlichte: h = 18 h Diese Formel zeigt, welche Stellschrauben existieren, um die Durchlaufzeit einer einzelnen Aufgabe zu reduzieren. Entweder der Durchsatz wird erhöht, was ggf. einhergehen würde mit dem Zukauf externen Entwicklungsressourcen oder die Menge der parallelen Arbeit wird möglichst gering gehalten. Das Kanbanboard wird in den jeweiligen Spalten der Wertschöpfungskette um die entsprechende Begrenzung paralleler Arbeit ergänzt. Hierbei wird von WIP-Limits gesprochen. 16 Vgl. Roock, A., Wolf, H. (2010), Seite 13f. 17 Vgl. Epping, T. (2011), Seite Vgl. Epping, T. (2011), Seite 29.

13 3 Kanban für die Softwareentwicklung Pull statt Push Wie im vorangegangenen Kapitel beschrieben, werden auf dem Kanbanboard über jede Spalte die WIP-Limits geschrieben. Neben dieser wesentlichen Erweiterung des Kanbanboards ist ebenso wichtig, dass Aufgaben nicht in die nächste Phase der Wertschöpfungskette geschoben (Push) werden. Aufgaben werden durch die nachgelagerten Phasen entsprechend ihrer WIP-Limits gezogen (Pull). 19 Sobald die Anzahl der Aufgaben innerhalb einer Spalte geringer ist, als die Menge der definierten WIP-Limits, wird ein freier Bearbeitungsplatz signalisiert Arbeit kann so ohne Fremdregulierung genommen werden. 20 Als weiterer Effekt wird hierdurch die gleichzeitige Arbeit an mehreren Aufgaben vermieden. Das Pull-Prinzip wird in Hernik Knibergs Comic One day in Kanban land verdeutlicht. Abbildung 2 zeigt einen Auszug mit deutscher Übersetzung. In Anlehnung an: Kniberg, H. (2009): One day in Kanban land Abbildung 2: Pull-Prinzip Das im Comic dargestellte Kanbanboard enthält fünf Phasen der Wertschöpfungskette vom Backlog bis zur Produktivsetzung der Anforderungen. Über jeder Spalte wurde ein entsprechendes WIP-Limit definiert. In diesem Auszug ist zu erkennen, dass durch die Auslieferung der Anforderung A nur noch eine Anforderung in der Entwicklung bearbeitet wird. Da für die Entwicklung jedoch ein WIP-Limit von 2 definiert wurde, hat das erste Entwicklerteam nun die Freiheit, eigenständig zu entscheiden, wann mit der Arbeit an einer neuen Anforderung begonnen wird. Durch das Pull-Prinzip soll so eine Überlastung des beteiligten Teams vermieden werden. Gleichzeitig wird hierdurch ein nachhaltiges Arbeitstempo gewährleistet, da das 19 Vgl. Epping, T. (2011), Seite Vgl. Anderson, D. (2011), Seite 89.

14 3 Kanban für die Softwareentwicklung Team vom Ballast paralleler Arbeit befreit wurde. 21 Ein weiterer Vorteil des Pull- Prinzips ist, dass Probleme beim Durchlaufen der Wertschöpfungskette schnell deutlich werden. Dies wird durch eine weitere Szene im Comic One day in Kanban land illustriert. In Anlehnung an: Kniberg, H. (2009): One day in Kanban land Abbildung 3: Umgang mit Problemen Das zweite Entwicklungsteam hat die Arbeit an Anforderung B abgeschlossen und könnte nun mit Anforderung D fortfahren. Bei der Auslieferung von Anforderung A ist jedoch ein Problem aufgetreten, sodass Anforderung B in der Spalte Entwicklung liegen bleibt. Aufgrund des WIP-Limits von 2 im Bereich der Entwicklung kann das Entwicklerteam nicht mit der Arbeit an Anforderung D beginnen. Dieses Beispiel zeigt, dass sich Probleme sofort ohne zeitlichen Verzug auswirken und das Team so die Möglichkeit hat, schnell darauf zu reagieren. In diesem Fall wäre es denkbar, dass das Entwicklerteam im Bereich der Auslieferung Unterstützung anbietet, um so die Anforderung schnellstmöglich produktiv zu setzen oder aber einen Software-Test schreibt, der den Fehler aus Anforderung A bei zukünftigen Auslieferungen abfängt. 22 So trägt das Pull-Prinzip zusätzlich zu einer kontinuierlichen Verbesserung im Wertschöpfungsprozess bei. 3.4 Kaizen Das Streben nach kontinuierlicher Verbesserung ist eine prozessorientierte Denkweise, eine Geisteshaltung, in Kanban. Dieses wird im japanischen durch die beiden Symbole KAI (übersetzt verbessern ) und ZEN (übersetzt gut ) ausgedrückt. Zusammengesetzt kann KAIZEN mit Verändern zum Besseren übersetzt wer- 21 Vgl. Roock, A., Wolf, H. (2010), Seite 13f. 22 Vgl. Anderson, D. (2011), Seite 247.

15 4 Kanban vs. Scrum den. 23 Ziel der kontinuierlichen Verbesserung ist es, dass jeder Angestellte dazu beiträgt, die Qualität des Produktes, die Produktivität sowie die Kundenzufriedenheit immer weiter zu verbessern. 24 Dies wurde im vorangegangenen Kapitel exemplarisch in Abbildung 3 gezeigt. Hinter dieser Kultur steckt aber auch das Prinzip, dass jeder Angestellte eigenverantwortlich handeln und Entscheidungen treffen darf. In regelmäßigen Meetings sollen Probleme offen angesprochen und Lösungen für zukünftige Verbesserungen diskutiert werden. Unbedingt notwendig ist dafür aber auch, dass das Management ebenfalls Fehler akzeptiert, sofern diese im Kontext einer Prozess- oder Leistungsverbesserung stehen. 25 Die Behebung der Ursache eines Fehlers sollte immer Vorrang gegenüber einer kurzfristigen Lösung des Problems haben. Kanban ist darauf ausgelegt, bestehende Prozesse in einem Unternehmen kontinuierlich zu verbessern, anstatt sie mit großer Wucht sofort durch einen besseren Prozess zu ersetzen. Um dies zu fördern, muss die eigene Firmenkultur den Kaizen-Ansatz unterstützen und über alle Management-Ebenen hinweg vorleben. Hierdurch wird ein Reifeprozess innerhalb eines Unternehmens angestoßen. Die Optimierung eines bestehenden Prozesses ist immer einfach und wird auf deutlich weniger Widerstand stoßen, als ihn komplett zu ersetzen. Langfristig wird die zunehmende Reife des Unternehmens dazu führen, dass auch drastischere Veränderungen leichter umgesetzt werden können und diese von der gesamten Belegschaft mitgetragen werden Kanban vs. Scrum Kanban und Scrum sind beides Frameworks, die in den Bereich der agilen Softwareentwicklung einzuordnen sind. Auch wenn die Überschrift dieses Kapitels erwarten lässt, dass am Ende dieser Seminararbeit feststeht, welches Framework besser ist und ab sofort in jedem Softwareentwicklungsprojekt eingesetzt werden sollte, so müssen die Erwartungen an dieser Stelle gedämpft werden. 23 Vgl. Brunner, F. (2008), Seite Vgl. Anderson, D. (2011), Seite Vgl. ebenda. 26 Vgl. Anderson, D. (2011), Seite 58f.

16 4 Kanban vs. Scrum Beide Frameworks sind weder perfekt noch vollständig. Beide führen auch nicht zwangsläufig zum Projekterfolg. Henrik Kniberg hat dazu folgende Aussagen getroffen: Ein Projekt kann erfolgreich sein wegen eines großartigen Werkzeugs. Ein Projekt kann erfolgreich sein trotz eines lausigen Werkzeugs. Ein Projekt kann scheitern wegen eines lausigen Werkzeugs. Ein Projekt kann scheitern trotz eines großartigen Werkzeugs. 27 Daher sollen beide Prozesswerkzeuge an dieser Stelle lediglich verglichen werden, um die wesentlichen Unterschiede zu erkennen und die eigentlichen Stärken insbesondere von Kanban für die Softwareentwicklung zu verstehen. Kanban und Scrum sind leichtgewichtig. Vergleicht man beide Frameworks miteinander, so ist dennoch festzustellen, dass Scrum an einigen Stellen wesentlich standardisierter ist. Die wesentlichsten Unterschiede werden in den folgenden Abschnitten gegenübergestellt. 4.1 Rollen und Prozesse Scrum schreibt sechs Rollen, sechs Meetings und neun Artefakte vor, deren Zusammenspiel streng reglementiert ist. Bei den Rollen werden u.a. der Product Owner, das Team, der Scrum-Master und der Kunde unterschieden. Auch die verschiedenen Meetings sind klar voneinander abgegrenzt. Als Beispiele können das Sprint Planning Meeting, das Daily Scrum oder die Sprint Retrospektive genannt werden. Bei Artefakten handelt es sich um Resultate eines Prozesses. Im Scrum- Prozess sind dies u.a. das Sprint Backlog, das Impediment Backlog oder die einzelne Aufgabe. 28 Kanban gibt den Unternehmen an dieser Stelle mehr Freiheiten: Kanban schreibt keine Rollen vor. Dadurch ist man bei der Einführung von Kanban flexibler, da keine zusätzlichen Rollen definiert werden müssen. Nichtsdestotrotz können zusätzliche Rollen, wie z.b. die Rolle des Product Owners sinnvoll sein, um den konstanten Zufluss von Aufgaben sicherzustellen Kniberg, H., Skarin, M. (2010), Seite Vgl. Gloger, B. (2009), Seite 12ff. 29 Vgl. Kniberg, H., Skarin, M. (2010), Seite 14f.

17 4 Kanban vs. Scrum Timeboxes In Scrum erfolgt die Entwicklung immer in einer definierten Timebox. Hierbei handelt es sich um Iterationen, die in einem zeitlichen Rahmen von einer bis zu vier Wochen durchgeführt werden. Grundsätzlich können die Iterationen zeitlich variieren, Scrum verfolgt allerdings das Ziel, Iterationen von immer derselben Länge zu planen. Der Kunde legt mit dem Scrum-Team den Rahmen und die zu bearbeitenden Aufgaben fest. Die Anzahl der Aufgaben wird auf Basis von Story Points und der durchschnittlichen Velocity, d.h. der Entwicklungsgeschwindigkeit, des Scrum- Teams festgelegt. Wurde sich auf ein Iterationsziel geeinigt, gilt die Iteration als geschützt. Eine Nachpriorisierung oder ein Zwischenschieben von Aufgaben ist nicht gewünscht. Auch an dieser Stelle gibt Kanban keine Vorschriften. Kanban legt sich nicht auf Iterationen fest und definiert keine Sprints. 30 Kanban begrenzt lediglich die Anzahl der Aufgaben, die parallel in jeder Phase der Wertschöpfungskette bearbeitet werden dürfen. In Kanban werden Aufgaben ausgeliefert, sobald sie ausgeliefert werden können, wohingegen in Scrum ein Paket fertiger Aufgaben am Ende eines Sprints ausgeliefert werden. Liegt in Scrum also der Fokus eher auf der Erreichung des Sprint-Ziels, so soll durch Kanban ein kontinuierlicher Fluss neuer, auslieferbarer Features entstehen. 4.3 Scrumboard vs. Kanbanboard: Umgang mit Anpassungen Wie bereits im letzten Kapitel beschrieben, werden in Scrum Aufgaben zu Beginn einer Iteration definiert und in Kanban werden WIP-Limits für jede Phase der Wertschöpfungskette festgelegt. Welche Möglichkeiten bieten beide Frameworks, um auf kurzfristige Änderungen, z.b. einer ungeplanten aber hochpriorisierten Aufgabe, zu reagieren? In Scrum sind Iterationen geschützt, d.h. kurzfristig kann die neue Aufgabe nicht bearbeitet werden. Die Aufgabe muss entsprechend priorisiert im Backlog des Product Owners eingeplant werden, damit sie in der nächsten Iteration bearbeitet werden kann. Man geht davon aus, dass die Zeit, um auf eine neue Anforderung zu 30 Vgl. Roock, S. (2010), Seite 20.

18 4 Kanban vs. Scrum reagieren, in Scrum durchschnittlich eine halbe Sprintlänge beträgt. 31 Als drastischste Methode kann eine Iteration auch abgebrochen werden. In diesem Fall werden die Sprint-Ziele verworfen und der Scrum-Prozess beginnt von vorne. Diese Maßnahme sollte jedoch nur im äußersten Notfall ergriffen werden. Auch hier kann Kanban flexibler auf die neue Anforderung reagieren, als Scrum. Unter Berücksichtigung der WIP-Limits kann die neue Aufgabe einfach entsprechend priorisiert eingeplant werden. In der Regel muss hierfür allerdings eine bereits eingeplante Aufgabe wieder zurückgestuft werden. Die neue Anforderung kann also ohne großen zeitlichen Verzug eingeplant und umgesetzt werden Gemeinsamkeiten Die vorangegangen Abschnitte beschreiben die wesentlichsten Unterschiede zwischen Kanban und Scrum. Beide Frameworks verbinden jedoch auch Gemeinsamkeiten. So basieren beide Frameworks auf selbst gesteuertem handeln und ein Pull- Prinzip, das dem Entwicklerteam zwischen den einzelnen Aufgaben immer wieder Zeit für Refactoring- oder Schulungsmaßnahmen bietet. Beide Systeme bilden über das jeweilige Board den gesamten Wertschöpfungsprozess der Softwareentwicklung ab. Welche Phasen abgebildet werden, kann wiederum von Unternehmen zu Unternehmen variieren. Sowohl Scrum als auch Kanban verfolgen als Ziel, Aufgabenpakete schnell und mit hoher Qualität auszuliefern. Eine Einschätzung beider Modelle bzgl. Erfolg und Einführung in einem Unternehmen erfolgt im nachfolgenden Fazit. 31 Vgl. Kniberg, H., Skarin, M. (2010), Seite 22f. 32 Vgl. ebenda.

19 5 Fazit Fazit In der vorliegenden Seminararbeit sollte Kanban als neues agiles Framework für die Softwareentwicklung vorgestellt und von der bekannteren agilen Methode Scrum abgegrenzt werden. Wie die vorangegangenen Kapitel gezeigt haben, bietet Kanban keine grundlegend neuen Werkzeuge oder Vorgehensweisen für die Softwareentwicklung. Greift man das Beispiel des Werkzeugkoffers aus der Einleitung dieser Seminararbeit wieder auf, so besteht Kanban aus vielen Werkzeugen, die dazu dienen, einen optimaleren Prozessfluss im Bereich der Softwareentwicklung zu ermöglichen. Handwerkliche Vorgaben werden nicht gegeben und können unternehmensindividuell getroffen werden. Im Gegensatz zu anderen Frameworks, wie beispielsweise Scrum, verzichtet Kanban auf die Definition klarer Rollen und Regeln. Einzig die Einhaltung der Visualisierung der Wertschöpfungskette, die Begrenzung paralleler Arbeit, die Etablierung eines Holprinzips sowie die Förderung eines kontinuierlichen Verbesserungsprozesses werden in Kanban vorausgesetzt. Dennoch ist der Unterschied zu Scrum nicht so groß, wie auf den ersten Blick vermutet werden könnte. Auch in Scrum wird versucht, die gesamte Wertschöpfungskette über das Scrumboard abzubilden. Setzt man nun voraus, dass es sinnvoll ist, parallele Arbeit wenn möglich zu vermeiden, so findet auch in Scrum eine gedankliche Begrenzung paralleler Arbeit statt. Diese bezieht sich in Scrum allerdings auf einen definierten Zeitraum, der definierten Entwicklungsiteration. Klar ist auch, dass auch in Kanban bestimmte Rollen und Strukturen notwendig sind, um einen möglichst optimalen Prozessfluss zu ermöglichen. Da diese Rollen jedoch nicht starr festgeschrieben sind, ist es deutlich einfacher ein Framework wie Kanban in einem Unternehmen oder einem Unternehmensbereich einzuführen, ohne dabei völlig neue Strukturen schaffen zu müssen. Bei der Einführung eines neuen Frameworks für die Softwareentwicklung in einem Unternehmen sollte meiner Meinung nach außerdem zwischen produktiven Betrieb und Projektarbeit unterschieden werden. Für Projektarbeit sehe ich Scrum gegenüber Kanban im Vorteil, da durch die definierten Iterationen der Projektfortschritt klarer ersichtlich ist. In diesem Fall können die Iterationen z.b. an definierte Meilensteine angepasst werden. Es entsteht kein gefühlter Kontrollverlust des Manage-