3.5.2.1.1 Artefakte

Die Entwicklungsmethode Scrum schreibt einige Artefakte zur Dokumentation von Anforderungen und Tasks vor, um den Überblick und die Kontrolle über das gesamte Projekt behalten zu können. Dabei finden Artefakte, wie das Product Backlog, Sprint Backlog, das Scrum-Board und das Burndown-Chart Anwendung. Kanban hingegen nutzt ausschließlich das Kanban-Board zur Organisation der Anforderungen bzw. Tasks. Zur Überwachung des Workzyklus wird aber wie in Scrum auch ein Brundown-Chart genutzt. Im Folgenden werden die verschiedenen Artefakte beschrieben und verglichen.

3.5.2.1.1.1 Product Backlog

Das Product Backlog enthält alle Anforderungen und Spezifikationen in der Form von Product Backlog Items, die vom Kunden gewünscht sind, ähnlich einer Agenda, die ständig nach Rentabilität vom Product Owner repriorisiert wird. Die im Product Backlog befindlichen Product Backlog Items werden üblicherweise in User Stories definiert und vom Scrum Team in ihrer Komplexität geschätzt. Dem Product Owner unterliegt die volle Verantwortung, dennoch besteht für Jeden die Möglichkeit, das Product Backlog einzusehen, um eine bessere Planung zu ermöglichen.
Vor jedem Sprint werden die Anforderungen mit den höchsten Prioritäten in Betracht gezogen und das Team wählt sich dann Stories in Anlehnung an die Summe der Story Points aus, die Sie denken in einem Sprint erledigen zu können.

3.5.2.1.1.2 Sprint Backlog

Das Sprint Backlog ist eine Liste mit Tasks(Aufgaben) die das Team definiert, um erfolgreich die vom Team ausgewählten Stories zu implementieren. Das Resultat am Ende des Sprints ist ein potentiell auslieferbares Product. Die Tasks werden kooperativ vom Team identifiziert und dann idealerweise in Story Punkten nach Komplexität und Zeitaufwand geschätzt.
Die Aufgabe des Scrum Masters ist es, die Schätzung für Tasks im Bereich von 0,5-2 Tagen zu halten, da auf Dauer die Konzentration der Teammitglieder nachlassen kann und somit falsche Schätzungen zu Stande kommen können.
Alle im voraussichtlich im Sprint benötigten Tasks müssen geplant und in das Sprint Backlog eingetragen werden. Da in der Softwareentwicklung meist nicht immer alles ohne neue Probleme(Bugs in der Software) abläuft, müssen daher Zeiten für Bug fixes mit eingeplant werden.

3.5.2.1.1.3 Kanban-Board

Abbildung 4: Kanban Tafel mit Beschränkung auf den Status "In Bearbeitung"

Das Kanban-Board ist das Organisationsmedium für Kanban. Auf ihm werden die Anforderungen bzw. Tasks festgehalten und durchlaufen dabei den Workflowzyklus von Kanban. Es werden drei verschiedene Status von links nach rechts auf dem Board gelistet:

• To-Do
• In Bearbeitung
• Fertig

Die einzelnen Aufgaben durchwandern als Notiz von links nach rechts die Tafel bis zur Fertigstellung dieser Anforderung. Durch eine Zahl in der oberen Hälfte der mittleren Spalte "In Bearbeitung” (siehe Abbildung 4) wird die Anzahl an gleichzeitigen Arbeiten begrenzt. Solange sich z.B. zwei Anforderungen in dieser Station befinden darf keine neue Anforderung aufgenommen werden bis diese durch das Pull-System abgeholt werden^[17]

3.5.2.1.1.4 Burndown-Chart

Abbildung 5: Burndown-Chart

Bei Scrum wird die Abarbeitung der Sprints anhand eines Burndown-Charts in einer Kurve visualisiert. Jedes Item im Sprint Backlog hat einen geschätzte Bearbeitungszeit. Pro Tag wird der noch vorhandene Restaufwand eingetragen und es entsteht, idealerweise, eine fallende Kurve (deswegen der Name Burndown). Auf der X-Achse wird die Dauer des Sprints bzw. die benötigte Zeit für einen Sprint dargestellt. Auf der Y-Achse sieht man hingegen den Restaufwand. Die Einheiten lassen sich auch beliebig, z.B. durch Story Points, ersetzen.
So lässt sich gut verfolgen ob das Team noch im Zeitplan liegt oder ob Zeit aufzuholen ist um das vordefinierte Ziel zu erreichen.

3.5.2.1.2 Meetings

Scrum schreibt im Gegensatz zu Kanban einige Meetings vor, um die Sprints zu planen, zu überwachen und Revue passieren lassen zu können. Dadurch können das Scrum Team, der Product Owner und die Stakeholder den Entwicklungsprozess überwachen, kontrollieren und verbessern. Zu den Meetings in Scrum zählen:

3.5.2.1.2.1 Sprint-Planung

Ein Sprint Planungs Meeting dient zur Planung eines anstehenden Sprints.
Zunächst präsentiert der Product Owner die Stories, die er gerne in dem folgenden Sprint von dem Team erledigt haben möchte, und das Team bestimmt dann, welche es für den Sprint akzeptiert. Das Meeting ist time-boxed und sollte deshalb nicht mehr als 4 Stunden dauern, wenn Beispielsweise ein Sprint 4 Wochen dauert.
Das Sprint Planungs Meeting ist mit einer groben Implementierungsplanung und einem Analyse- und Designworkshop gleichzusetzen. Anforderungen, die neu in das Product Backlog eingestellt wurden, werden vom Team geschätzt und akzeptierte Stories für den folgenden Sprint werden analysiert.
Im 2. Teil der Sprint-Planung werden vom Team die zuvor besprochenen und akzeptierten Stories für den folgenden Sprint in einzelne Arbeitsschritte (Tasks) aufgesplittet, vom Zeitaufwand geschätzt und an dem Scrum-Board festgehalten. Die Summe des Zeitaufwandes der einzelnen Tasks sollte dabei nicht die Summe der verfügbaren Arbeitszeit des Team für den folgenden Sprint überschreiten.
Das Ziel des Meetings ist 'Commitment' des Teams gegenüber dem Product Owner, über selektierte Product Backlog Items die zum Ende des Sprints 'done' (fertig) sind^[18].

3.5.2.1.2.2 Daily-Scrum/Standup

Das in Scrum sogenannte Daily-Scrum Meeting unterscheidet sich von dem sogenannten Standup Meeting von Kanban in keinem Punkt.
Beide Entwicklungsmethoden nutzen dieses Meeting um täglich im Scrum Team/Kanban Team, zu einem festen Zeitpunkt für ca. 15Minuten, zusammen zu kommen. Dabei synchronisiert sich das Team, damit jeder Entwickler weiß, an welcher Story/Task der andere Entwickler zurzeit arbeitet und was am Vortag erreicht wurde. Somit kann Doppelarbeit vermieden werden.
Hat ein Entwickler Probleme in der Erfüllung eines Tasks/einer Story, so kann dies in dem Meeting angesprochen werden. Das Meeting dient dennoch nicht zur Problemlösung, sondern soll nur den Status bzw. Probleme der einzelnen Teammitglieder wiederspiegeln. Lösungsansätze von Problemen können nach dem Meeting z.B. in Peer-Programming(2 Entwickler sitzen zusammen um ein Problem zu lösen) entwicklet werden^[19].
Daily-Scrum-bzw. Standup-Meetings wiederholen sich solange, wie das Projekt aktiv weiterentwickelt wird.

3.5.2.1.2.3 Sprint-Review

Das Sprint-Review Meeting wird in Scrum angewendet und ist gleichzusetzten mit einer Präsentation erledigter Arbeit.
Am Ende eines jeden Sprints setzten sich das Scrum Team, der Product Owner, die zukünftigen Anwender, die Geschäftsleitung und der Abteilungsleiter zusammen. Dabei präsentiert das Scrum Team, die am Anfang des Sprints festgelegten User Stories, welche vom Team als fertig und als umgesetzt angesehen werden. Es wird ausschließlich laufende Software gezeigt.
Es natürlich vorkommen, dass das Entwicklerteam eine Story als fertig ansieht, wobei der Product Owner diese aber als unfertig bewertet. Dies kann passieren, wenn die Funktionalität der Story nicht erfüllt ist, der Product Owner sich was ganz Anderes darunter vorgestellt hat, oder evtl. die Performance(Geschwindigkeit) der Software durch die Story zu langsam geworden ist.
Alle diese Kriterien bestimmen über abgenommene, oder im anderen Fall, fehlgeschlagene Stories. Daher sollten diese Kriterien vorher genau festgelegt werden, damit dem Team auch bewusst ist, dass Beispielsweise die Performance auch ein Abnahmekriterium ist^[19].

3.5.2.1.2.4 Retrospektive

Eine Retrospektiven-Runde besteht aus dem eigentlichen Scrum Team, dem Scrum Master und dem Product Owner.
Am Ende jedes Sprints wird im Kreise des Scrum Teams besprochen, wie die Arbeit im nächsten Sprint noch weiter verbessert werden kann. Im Mittelpunkt steht dabei nicht das Ergebnis den Sprints(Erfolg oder Nichterfolg), sondern vielmehr der eigentliche Entwicklungsprozess und die Zusammenarbeit des Teams. Das Team blickt zurück und rekapituliert die während des letzten Sprints aufgetretenen Probleme, Ereignisse und Erfahrungen. Positive Erfahrungen werden dadurch offengelegt und dienen somit zusätzlich als Motivation für den nächsten Sprint.
Retrospektiven folgen dem 'Beobachten und Anpassen'-Prinzip und sollen dazu beitragen Entwicklungsprozesse kontinuierlich zu verbessern. Das Team entscheidet dabei selbst, welche Arbeitsweisen es behalten und in welche Richtung es sich weiterentwickeln will.
Mit der Durchführung einer Retrospektive investiert das Team in seine Zukunft, denn selbst sehr gute Teams können sich immer noch kontinuierlich weiterverbessern. Scrum-Teams streben(im Sinne der japanischen Lebens- und Arbeitsphilosophie Kaizen) nach ständiger Verbesserung.
Zusammenfassend kann man sagen, das es im groben Ablauf einer Retrospektive immer darum geht, Daten zu sammeln, Erkenntnisse zu gewinnen und aufbauend auf diesen Erkenntnissen Ziele zu bestimmen und Aktionen zu planen^[20].

Die Retrospektive in Kanban verläuft hingegen sehr ähnlich wie in Scrum. Der einzige große Unterschied ist, dass in der Kanban Retrospektive keine Product Owner bzw. ScrumMaster etc. sitzen, sondern das Kanban-Team und deren Kunden.

3.5.2.2.1 Scrum

3.5.2.2.1.1 Product Owner

Der Product Owner ist meist der Kunde, kann aber auch ein Mitarbeiter des Unternehmens sein. Zu seinen Hauptaufgaben zählen das Halten des regelmäßigen Kontakts zu Kunden, Anwendern und Stakeholdern^[21], das Aufnehmen und Priorisieren der Anforderungen in das Product Backlog und die Definition der Abnahmekriterien.
Der Product Owner repräsentiert die Kundenbedürfnisse bzw. die fachliche Sicht und ist zusätzlich auch der erste Ansprechpartner im Unternehmen für alle Produktanforderungen, weswegen der regelmäßige Kontakt zu Kunden, Anwendern und Stakeholdern unbedingt erforderlich ist. Aufgrund dieser fortwährenden Kommunikation repräsentiert er auch das Scrum-Team nach außen, berichtet über den Projektstatus und ist für die Abstimmung mit anderen Projekten oder Produkten zuständig. Hierzu muss er folglich auch eng mit dem Team zusammenarbeiten.
Seine zweite Hauptaufgabe ist das Aufnehmen aller Produktanforderungen. Diese werden von ihm nach ihrem Business Value priorisiert und anschließend klar und eindeutig in das Product Backlog aufgenommen. Da der Product Backlog aber kein finalisiertes Anforderungsdokument ist, sondern vielmehr fortlaufend zu ergänzen ist, ist diese Aufgabe für den Product Owner vielmehr eine laufende Priorisierung.
Für diese Anforderungen muss der Product Owner gleichzeitig auch Abnahmekriterien definieren und bei erfolgter Entwicklung die Ergebnisse akzeptieren bzw. ablehnen^[22]. Somit ist er für die Qualität des Produkts verantwortlich und entscheidet letztendlich auch über den Auslieferungszeitpunkt^[1].

3.5.2.2.1.2 Scrum Master

Der Scrum Master ist Mitglied des Teams und der Verantwortliche für die Scrum-Regeln und erklärt Scrum. Zu seinen Hauptaufgaben zählen das Unterstützen des Teams und das Moderieren der Teammeetings.
Der Scrum Master unterstützt das Team und sorgt für eine bestmögliche Zusammenarbeit im Team. Außerdem versucht er die Störung des Teams bei ihrer Arbeit minimal zu halten. Um dies zu erreichen, kümmert er sich um die Probleme, die das Team selber nicht lösen kann, fordert Ressourcen an und schützt das Team vor äußeren Einflüssen. Zusätzlich dazu Treibt er das Team zur Verbesserung der Prozesse an^[1].
Diese Verbesserungen sollen vor allem durch die Teammeetings am Ende jedes Sprints, die einen wertfreien Überblick über Erfahrungen und Verbesserungspotential zur Erhöhung der Motivation und des Wissens für den nächsten Sprint bieten, erreicht werden.

3.5.2.2.1.3 Team

Das Team ist funktional übergreifend besetzt, setzt die Anforderungen aus dem Product Backlog um und organisiert und kontrolliert sich dabei selbst. Darunter fällt auch, dass es selbst über die Anforderungsmenge je Sprint entscheidet und die Aufwände der Product Backlog-Elemente selbst schätzt. Es verpflichtet sich nach erfolgter Aufwandschätzung zur Fertigstellung des Produkt Inkrements innerhalb des Sprints und hält die Schätzungen laufend aktuell. Um dies gewährleisten zu können bespricht es sich regelmäßig im Daily Scrum, wodurch ihm auch gleichzeitig die Möglichkeit gegeben ist, sich kontinuierlich zu verbessern^[1].

3.5.2.2.2 Kanban

3.5.2.3.1 Organisation

Abbildung 6: Projektsteuerung Scrum

Abbildung 7: Projektsteuerung Kanban

In Scrum beginnen die Stakeholder die Produktentwicklung mit einer klaren Produktvision. Der Product Owner ist für den ökonomischen Erfolg des Produktes verantwortlich. Dieser erstellt aus den Anforderungen der Stakeholder sogenannte Userstories und priorisiert diese im Product Backlog. Natürlich bindet er alle relevanten Parteien früh in die Definition der Produktvision und des Product Backlogs ein. Der Product Owner bleibt aber immer der „Herr“ über das Product Backlog.
Zu Beginn jedes Entwicklungszyklus, bei Scrum der sogenannte Sprint, findet das sogenannte Sprint Planning Meeting statt. Darin vereinbaren der Product Owner und das Entwicklungsteam, welche Anforderungen aus dem Product Backlog im Sprint erledigt werden sollen. Diese Anforderungen werden in das Sprint Backlog übertragen und vom Entwicklungsteam anschließend in einzelne Task aufgesplittet und jeweils in User Story Points geschätzt um einen genauen Zeitplan(Burndown Diagramm) für den Sprint erhalten zu können. User Story Points sind dabei relative Werte, die den Entwicklungsaufwand einer User Story, im Vergleich zu einer Anderen, darstellen. Wichtig ist, dass sich Product Owner und das Entwicklungsteam auf das Sprint Backlog committen^[24]. Entscheidungsgrundlage ist hierbei die angenommene Velocity des Teams. Diese gibt vor, wie viele Story Points das Team in folgendem Sprint abarbeiten und als erfolgreich erledigen kann. Beispielsweise bedeutet eine angenommene Velocity von 8 Punkten, dass das Team User Stories mit einer Summe von maximal 8 Story Points annehmen kann.
Die Velocity ist dabei der Faktor in kumulierten User Story Points der innerhalb eines Sprints von dem Team abgearbeitet werden kann und von Sprint zu Sprint genauer wird. Die Betrachtung der Velocity innerhalb der Sprint Planung garantiert, dass Schätz- und Planungsfehler vermieden werden.
Das dahinterstehende Prinzip ist, sich die in einem zurückliegenden Sprint abgearbeiteten User Stories anzuschauen und deren Punktesumme als Basis für die Velocity des nächsten Sprints zu nehmen.
Im Laufe eines Sprints kann das Team somit auf feste Werte zurückblicken und beobachten, ob Sie sich eventuell zu viele Anforderungen, mit in der Summe zu vielen Story Points, vorgenommen haben. Das Team kann daraus lernen und gegebenenfalls die Entwicklungsgeschwindigkeit für den nächsten Sprint von vornherein auf weniger Story Points drosseln.
Ein Sprint hat eine feste, immer gleiche, Länge(z.B. 3 Wochen). Die Entwicklung erfolgt in direkt aufeinanderfolgenden Sprints. Das selbstorganisierte Team arbeitet während des Sprints störungsfrei an der Abarbeitung des Sprint Backlogs. Das bedeutet auch, dass während eines Sprints keine neuen oder geänderten Anforderungen an das Team gestellt werden.

In Kanban werden die einzelnen Prozessschritte in unterschiedliche Spalten, am besten auf einem Whiteboard visualisiert. Wobei der Workflow von links nach rechts verläuft.
In dem Kanban-Board(Beispiel Abb. Projektsteuerung Kanban) sind die Prozessschritte das Backlog. Alle Prozessschritte, die gesammelten Anforderungen, die Programmierung, die fertige Programmierung, das Testen, fertige Tests und die Auslieferung werden hier abgebildet.
Die Anforderungen werden auf Notizzetteln festgehalten. Dabei spielt es keine Rolle, ob mit Features, Tasks oder, wie in diesem Fall, mit Stories gearbeitet wird. Die Anforderungen laufen als Ticket durch die unterschiedlichen Prozessschritte und wandern mit der Zeit von links nach rechts über das Kanban-Board.
Mit der Zeit wird ein Pull-System etabliert und die Menge an paralleler Arbeit begrenzt. Diese Begrenzung führt dazu, dass die einzelnen Tickets schneller erledigt werden, weil nicht parallel an anderen Tickets gearbeitet werden kann und, weil blockierte Tickets auf Dauer nicht ignoriert werden können. Die Tickets werden stets aus den vorgelagerten Stationen gezogen. Dabei gilt, dass neue Tickets nur dann gezogen werden dürfen, wenn vorher bestehende Tickets abgearbeitet wurden. Der Work in Progress, also die Menge an paralleler Arbeit, sollte am jedem Prozessschritt konstant bleiben. So wird gewährleistet, dass alte Aufgaben auch wirklich erledigt sind, bevor mit neuen begonnen wird. Das Pull-System gewährleistet außerdem einen wirksamen Schutz vor Überlastungen, da sich an keinem Prozessschritt jemals mehr Tickets befinden, als realistischer Weise in kurzer Zeit abgearbeitet werden können.

3.5.2.3.2 Geschwindigkeit

Die immer gleiche Länge der Sprint in Scrum führt zu einer guten Vergleichbarkeit, sodass - insbesondere aus der Geschwindigkeit der bisherigen Iterationen - ziemlich genau die Geschwindigkeit der nächsten Sprints prognostiziert werden kann.
Die Limits für einige Prozessschritte auf dem Kanban-Board sorgen dafür, dass Probleme schnell sichtbar werden und zwingen alle Teammitglieder umgehend Lösungen für diese Probleme zu finden. Für fortgeschrittene Teams stellen die Limits darüber hinaus Regler dar, mit denen der Fluss stetig verbessert und die Durchlaufzeiten immer weiter verkürzt werden können.
Um sich zu verbessern und schneller zu werden, werden in beiden Entwicklungsmethoden täglich sogenannte „Daily-Scrum Meetings“ bzw. in Kanban, auch wenn keine Meetings zwangsweise vorgeschrieben sind, sogenannte „Standup Meetings“ durchgeführt. So begutachtet das Team täglich die Fortschritte auf dem Scrum- bzw. Kanban-Board, diskutiert insbesondere über blockierte Tickets und diskutiert Maßnahmen, um sowohl die konkreten Blockaden, als auch die tieferliegenden Ursachen zu beseitigen.
In größeren Abständen werden außerdem Retrospektiven durchgeführt, in denen das Team über Prozessverbesserungen reflektiert und konkrete Verbesserungsmaßnamen beschließt.
Scrum als auch Kanban nutzen beide Visualisierungsmöglichkeiten, wie Statistiken oder Diagramme, die den Workflowzyklus wiederspiegeln. Sie sollen Auskunft darüber geben, wie viele Storys/Tasks im letzten Workflowzyklus oder in Scrum im letzten Sprint fertiggestellt werden konnten und wie sich die Menge an paralleler Arbeit mit der Zeit verändert hat. Somit kann man nachhaltig auf Unregelmäßigkeiten reagieren und letztlich die Geschwindigkeit des nächsten Sprints bzw des gesamten Projekts erhöhen.

3.5.2.4.1 Projektumfang

Der Projektumfang bezeichnet die Anforderungen an die zu entwickelnde Software.
Scrum nimmt die Kundenanforderungen des Projektes in das Product Backlog auf. Bei steigendem Projektumfang wird zwar das Product Backlog proportional komplexer, jedoch bleibt die Übersichtlichkeit durch die Aufwandschätzung und iterationsweise Aufteilung in das Sprint Backlog gegeben.
Kanban hingegen zeigt den Projektumfang in Form von User Stories am Kanban-Board auf. Je größer der Projektumfang wird, desto unübersichtlicher wird die Darstellung am Kanban-Board.

3.5.2.4.2 Projektbesonderheiten

Die Projektbesonderheiten sind Anforderungen der Stakeholder an die Software, die extravagant und außergewöhnlich sind.
In Scrum werden diese, wie alle anderen Anforderungen, in das Product Backlog aufgenommen. Anschließend priorisiert der Product Owner diese Anforderungen nach ihrer Wichtigkeit im Bezug auf die Fertigstellung des Projektes und auf ihren Business Value. Zusätzlich schätzt das Team den Aufwand der Anforderung für jeden Sprint. Auf diese Weise werden Projektbesonderheiten ihrer Komplexität bzw. ihrem Aufwand entsprechend bewertet und können frühzeitig in die Projektplanung mit einfließen.

In Kanban wird normalerweise keine Aufwandschätzung betrieben, können jedoch bei Bedarf vorgenommen werden. Der Grund hierfür liegt darin, dass es bei Anforderungen aus dem Product Backlog keine Gewissheit gibt, ob bzw. wann die Produktanforderungen bearbeitet und umgesetzt werden, so dass Aufwandschätzungen in Kanban überdies z.T. als Vergeudung angesehen werden. In Kanban hingegen wird viel mehr der Focus auf die Schätzung des Zeitpunktes für die Fertigstellung der Anforderung gelegt. Diese Schätzung basiert dann auf den bisher empirisch gemessenen durchschnittlichen Durchlaufzeiten und lässt sich mit der Wahrscheinlichkeit für die Termintreue konkretisieren und belegen^[23].

3.5.2.4.3 Teamgröße und Teamorganisation

Ein Scrum Team besteht normalerweise aus 5-9 Personen^[1]. Wenn das Projekt allerdings einen Komplexitätsgrad erreicht, bei dem mehr als vier Softwareentwickler benötigt werden, eignet sich Scrum besonders gut. Der Grund hierfür sind die regelmäßigen Meetings von Scrum, die den Prozess strukturieren. Da diese Meetings feste Termine und ein Zeitlimit haben, passiert es hier nicht, dass sie ausufern oder den temporären, unerwarteten Abbruch der Arbeit. Zudem ist klar definiert, welche Aufgaben auf welche Sitzungen verteilt wurden. Folglich existiert eine klare Struktur, so dass zum Beispiel in den täglichen Scrum-Meetings ein regelmäßiger Informationsaustausch stattfindet.
Scrum bietet außerdem eine Möglichkeit zur verteilten Produktentwicklung. Bei dieser Möglichkeit gibt es weiterhin ein gemeinsames Product Backlog und ein gemeinsam zu erstellendes Produkt, aber die Teams werden verteilt und dadurch findet eine Optimierung der Skalierbarkeit von großen Projekten statt. Scrum sieht hier vor ein ‚Scrum of Scrums‘ zu bilden. Bei diesen täglichen Meetings synchronisieren sich die Teams untereinander^[6].

In Kanban gibt es keinerlei Beschränkung bezüglich der Teamgröße. Es findet eine Synchronisierung der Aufgabenabarbeitung über das Kanban-Board statt, sodass auch mehrere Teams gleichzeitig an einem Produkt arbeiten können. Durch das Pull-Prinzip und die Übersichtlichkeit der Aufgabenverteilung durch das Kanban-Board ist sogar eine implizite Teilsynchronisierung vorhanden, die die Möglichkeit von Redundanzen minimiert^[6].

Für die Einführung von Scrum empfiehlt sich zuerst ein Pilotprojekt zu verwenden, um die Vorteile, auftretende Hindernisse und Reibungspunkte mit der bestehenden Organisation zu erkennen. Anschließend sollte die Organisation gemäß der Erfahrungen aus dem Pilotprojekt entscheiden, ob und in wie weit Scrum auf weitere Projekte ausgedehnt werden soll. Bei erfolgreichen Pilotprojekt sollte die Ausdehnung etappenweise mit i.d.R. Mitglieder des Pilotprojekts als Unterstützung geschehen. Es sollten weiterhin Überlegungen stattfinden, ob es bei der angrenzenden Organisation vor- oder nachgelagerte Prozesse gibt, die in die neuen Scrum-Projekte integriert oder nach Scrum organisiert werden sollen.
Hierbei ist jedoch zu beachten, dass in den ersten Scrum-Projekten zwar die Scrum-Techniken und –Meetings etabliert sind, aber die Reflexion, also das Denken der kontinuierlichen Verbesserung, noch nicht verinnerlicht wurde. Folglich ist nach Etablierung der Scrum Techniken, das Herstellen dieser Reflexion und die Maximierung des Nutzen der Retrospektive der nächste Schritt.
Für eine längerfristig erfolgreiche Einführung von Scrum muss eine flache Aufwandskurve sichergestellt werden, d.h., dass die neue Anforderungen keinen exponentiellen Kostenzuwachs hervorrufen.

Für die Einführung von Kanban haben sich in der Praxis zwei erste Schritte etabliert. Das wären zum einen die bisherige Wertschöpfungskette zu modellieren und die bisher in Projekten vorkommenden Stationen visuell darzustellen. Anschließend können grob aus der bisherigen Projekterfahrung Limits für einzelne Stationen festgelegt werden. Hierbei ist es wichtig, dass die Produktivität und die Durchlaufzeiten beobachtet werden, so dass Bottlenecks erkannt und eine Anpassung der Limits schrittweise durchgeführt werden kann. Da diese Anpassung regelmäßiges Feedback erfordert, haben sich in der Praxis tägliche Standup-Meetings durchgesetzt. Außerdem werden oft Reihenfolgen für die Abarbeitung der individuellen Kundenanforderungen, so genannte ‚Service Level Agreements’, eingeführt^[8].

Die Verständlichkeit für eine Methode ist allgemein besser, sobald weniger Regelwerk befolgt werden muss. Folglich ist Kanban mit seinen drei Hauptprinzipien eine sehr leicht verständliche Methode. Im Gegensatz zu Scrum gibt es z.B. keine geregelten Sprints mit bestimmten Intervallen, sondern nur einen kontinuierlichen Arbeitsablauf.
Dass der Komplexitätsgrad von Scrum weitaus höher, als der von Kanban ist, ist schon allein daran festzumachen, dass Scrum in Unternehmen ohne vorherige Schulung überhaupt nicht effektiv eingeführt werden kann. Vor allem der Scrum Master muss das umfangreiche Regelwerk von Scrum verinnerlicht haben, da ihm die Aufgabe zukommt, Scrum zu erklären.

Die Effizienz der Entwicklungsprozesse ist nicht direkt aus der Theorie ableitbar. Um aussagekräftige Vergleiche ziehen zu können, wäre hier weitreichende praktische Erfahrung notwendig. Weiterhin ist zu beachten, dass, aufgrund der hohen Flexibilität beider Methoden, hier auch keine pauschale Aussage im Komparativ getroffen werden kann. Aus der Theorie ist lediglich zu erkennen, dass der Produktivität die höchste Bedeutung zukommt. Da dies aber für beide Methoden gilt, wird im Folgenden eine eigene Schätzung zur Produktivität abgegeben, die die Erkenntnisse der bisherigen Analyse als Basis hat:

Planung und Kontrolle beinhaltet die verschiedenen Artefakte und Meetings innerhalb der Softwareentwicklungsprozesse und wird mit 15% gewichtet, da die Meetings und Artefakte wichtige Rollen in beiden Softwareentwicklungsprozessen einnehmen und die Teammitglieder in ihren Aufgaben unterstützen und die Produktivität der Projekte erhöhen.

Organisationsstruktur beinhaltet die Rollen- und Aufgabenverteilung innerhalb der Softwareentwicklungsprozesse. Sie wird mit 5% gewichtet, da die Rollen nur minderwichtig für das Projekt und in Kanban noch nicht einmal explizit vorhanden sind.

Projektsteuerung beinhaltet die Organisation, die Geschwindigkeit und den Zeitaufwand. Sie wird mit 20% gewichtet, da sie den Großteil der Eigenschaften umfasst, die Scrum und Kanban ausmachen.

Umgang mit komplexen Projekten beinhaltet den Projektumfang, Projektbesonderheiten und die benötigte Teamgröße. Dieser Punkt wird mit 15% gewichtet, weil gerade die Softwareentwicklung in den letzten Jahren stark an Komplexität zugenommen hat und entsprechende Projekte immer größer und komplexer werden, so dass dies auch ein Kriterium für das zukünftige der Entwicklungsprozessmethode ist.

Dauer der Einführung beinhaltet den Einführungsprozess und den damit verbundenen Aufwand. Da dies pro Unternehmen in der Regel nur einmal geschieht, wird dieser Punkt mit 5% gewichtet.

Verständlichkeit/Einfachheit der Entwicklungsprozessmethoden bezeichnet die Transparenz und den Grad der Komplexität der beiden Softwareentwicklungsprozesse. Da Projekte nur in den seltensten Fällen simpel konstruiert sind und oft durch noch komplexere System gesteuert und organisiert werden, wird dieser Punkt mit 5% gewichtet.

Produktivität/Effizienz der Entwicklungsprozessmethode steht für Fokussierung der Softwareentwicklungsmethode auf das zu erstellende Produkt und die Effizienz, mit der vorhandene Ressourcen genutzt werden, um das Produkt zu erstellen. Da dies der wichtigste Punkt der agilen Softwareentwicklung ist und von Scrum und Kanban jeweils mit der selben Priorisierung übernommen wurde, wird dieses Vergleichskriterium mit 35% gewichtet.