Scrum. Schnelleinstieg (3. Aufl.)
()
Über dieses E-Book
Ähnlich wie Scrum. Schnelleinstieg (3. Aufl.)
Ähnliche E-Books
Tasks & Teams: Die neue Formel für bessere Zusammenarbeit Bewertung: 0 von 5 Sternen0 BewertungenThe People's Scrum: Revolutionäre Ideen für den agilen Wandel Bewertung: 0 von 5 Sternen0 BewertungenScrum: Agiles Projektmanagement und Scrum erfolgreich anwenden Bewertung: 0 von 5 Sternen0 BewertungenAgile Moderation: Ob und wie sich die Ideen der agilen Produktentwicklung auf die Moderation von Gruppen und Teams übertragen lassen Bewertung: 0 von 5 Sternen0 Bewertungen23 Wege um eine (agile) Transformation an die Wand zu fahren: Der ultimative Leitfaden zur Eliminierung von Selbstorganisation und Mitarbeitermotivation Bewertung: 0 von 5 Sternen0 BewertungenScrum: Schnelleinstieg Bewertung: 0 von 5 Sternen0 BewertungenRight to Left: Der Leitfaden zu Lean und Agile für Digital Leader Bewertung: 0 von 5 Sternen0 BewertungenAgiles Produktmanagement mit Scrum: Erfolgreich als Product Owner arbeiten Bewertung: 3 von 5 Sternen3/5Leadership im Produktmanagement: Wie Sie Stakeholder und Entwicklungsteams effektiv führen Bewertung: 0 von 5 Sternen0 BewertungenModellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall Bewertung: 0 von 5 Sternen0 BewertungenScrum Master: Vorbereitung auf die PSM I Prüfung Bewertung: 0 von 5 Sternen0 BewertungenErfolgreiche Design Thinking-Teams aufbauen: Agile Innovation für Unternehmen und Organisationen gestalten Bewertung: 0 von 5 Sternen0 BewertungenGeschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten Bewertung: 4 von 5 Sternen4/5Erfolgreich mit dem agilen Spotify Framework: Squads, Tribes und Chapters - der nächste Schritt nach Scrum und Kanban? Bewertung: 0 von 5 Sternen0 BewertungenProjektmanagement von Online-Projekten Bewertung: 0 von 5 Sternen0 BewertungenAgile Leadership im Scrum-Kontext: Servant Leadership für agile Leader und solche, die es werden wollen Bewertung: 0 von 5 Sternen0 BewertungenAgiles Arbeiten: Das Wesentliche kurz erklärt. Version 3.0 Bewertung: 0 von 5 Sternen0 BewertungenSolution Focused Feedback Lösungsorientiert mehr erreichen: Die Feedback-Technologie des 21. Jahrhunderts Bewertung: 0 von 5 Sternen0 BewertungenPRINCE2: Die Erfolgsmethode einfach erklärt Bewertung: 0 von 5 Sternen0 BewertungenWorkshops im Requirements Engineering: Methoden, Checklisten und Best Practices für die Ermittlung von Anforderungen Bewertung: 4 von 5 Sternen4/5SCRUM: Das Erfolgsphänomen einfach erklärt Bewertung: 0 von 5 Sternen0 BewertungenAgiles Projektmanagement und Scrum: Praxishandbuch Agiles Arbeiten Bewertung: 0 von 5 Sternen0 BewertungenRoadmap durch die VUCA-Welt: Für Führungskräfte, Scrum Master und Agile Coaches Bewertung: 0 von 5 Sternen0 Bewertungen
Programmieren für Sie
Eigene Spiele programmieren – Python lernen: Der spielerische Weg zur Programmiersprache Bewertung: 0 von 5 Sternen0 BewertungenLinux Grundlagen - Ein Einstieg in das Linux-Betriebssystem Bewertung: 0 von 5 Sternen0 BewertungenSQL – kurz & gut Bewertung: 0 von 5 Sternen0 BewertungenAlgorithmen: Grundlagen und Implementierung Bewertung: 0 von 5 Sternen0 BewertungenPython-Grundlagen Bewertung: 0 von 5 Sternen0 BewertungenJavaScript kurz & gut Bewertung: 3 von 5 Sternen3/5Python kurz & gut: Für Python 3.x und 2.7 Bewertung: 3 von 5 Sternen3/5Einstieg in TypeScript: Grundlagen für Entwickler Bewertung: 0 von 5 Sternen0 BewertungenDas Excel SOS-Handbuch: Wie sie Excel (2010-2019 & 365) schnell & einfach meistern. Die All-in-One Anleitung für ihren privaten & beruflichen Excel-Erfolg! Bewertung: 0 von 5 Sternen0 BewertungenHacken mit Python und Kali-Linux: Entwicklung eigener Hackingtools mit Python unter Kali-Linux Bewertung: 0 von 5 Sternen0 BewertungenSQL von Kopf bis Fuß Bewertung: 4 von 5 Sternen4/5C++: Kurzportträt einer zeitlosen Sprache Bewertung: 0 von 5 Sternen0 BewertungenPowerShell: Anwendung und effektive Nutzung Bewertung: 5 von 5 Sternen5/5Das große Python3 Workbook: Mit vielen Beispielen und Übungen - Programmieren leicht gemacht! Bewertung: 4 von 5 Sternen4/5XML für Eilige Bewertung: 0 von 5 Sternen0 BewertungenDas Franzis Starterpaket Arduino Mega 2560: Das Handbuch für den Schnelleinstieg Bewertung: 0 von 5 Sternen0 BewertungenProgrammieren für Einsteiger: Teil 1 Bewertung: 0 von 5 Sternen0 BewertungenLinux Befehlsreferenz: Schnelleinstieg in die Arbeit mit der Konsole, regulären Ausdrücken und Shellscripting Bewertung: 0 von 5 Sternen0 BewertungenAndroid-Entwicklung für Einsteiger - 20.000 Zeilen unter dem Meer: 2. erweiterte Auflage Bewertung: 0 von 5 Sternen0 BewertungenWeniger schlecht programmieren Bewertung: 4 von 5 Sternen4/5Programmieren lernen mit Python 3: Schnelleinstieg für Beginner Bewertung: 0 von 5 Sternen0 BewertungenRichtig einsteigen: Excel VBA-Programmierung: Für Microsoft Excel 2007 bis 2016 Bewertung: 0 von 5 Sternen0 BewertungenMikrocontroller in der Elektronik: Mikrocontroller programmieren und in der Praxis einsetzen Bewertung: 0 von 5 Sternen0 BewertungenSoftwareentwicklungsprozess: Von der ersten Idee bis zur Installation Bewertung: 0 von 5 Sternen0 BewertungenCoole Projekte mit dem Arduino™ Micro: Physical Computing im Projekteinsatz Bewertung: 0 von 5 Sternen0 BewertungenMicrocontroller für das IoT Bewertung: 0 von 5 Sternen0 BewertungenDas Franzis Starterpaket Arduino Uno: Das Handbuch für den Schnelleinstieg Bewertung: 0 von 5 Sternen0 BewertungenHTML5-Programmierung von Kopf bis Fuß: Webanwendungen mit HTML5 und JavaScript Bewertung: 0 von 5 Sternen0 BewertungenPython | Schritt für Schritt Programmieren lernen: Der ultimative Anfänger Guide für einen einfachen & schnellen Einstieg Bewertung: 0 von 5 Sternen0 BewertungenC von Kopf bis Fuß Bewertung: 3 von 5 Sternen3/5
Rezensionen für Scrum. Schnelleinstieg (3. Aufl.)
0 Bewertungen0 Rezensionen
Buchvorschau
Scrum. Schnelleinstieg (3. Aufl.) - Dr. Andreas Wintersteiger
können.
1 Einleitung
Agile Softwareentwicklung hat es in den Mainstream geschafft. Nach beinahe fünfzehn Jahren nach dem Agilen Manifest sind agile Vorgehensweisen keine exotischen Modelle mehr von Eigenbrötlern, die sich ihre eigene Welt schaffen, sondern eine anerkannte und bewiesenermaßen erfolgreiche Art und Weise, Software zu entwickeln¹. Agile Entwicklung ist heute nicht nur erfolgreich, sondern deutlich erfolgreicher als klassische, wasserfallorientierte Vorgehensmodelle – dafür haben wir heute Evidenz.
Mussten wir vor zehn Jahren immer wieder den Beweis antreten, so sind wir heute einen bedeutenden Schritt weiter: Es ist nicht nur die Akzeptanz im breiten Feld vorhanden, ein großer Teil der Unternehmen strebt agile Entwicklungspraktiken und -methoden initiativ an. Darunter ganz besonders Scrum, das aus heutiger Sicht sicherlich das erfolgreichste Framework² unter den agilen Vorgehensweisen ist. Scrum erfreut sich zunehmender Beliebtheit und Verbreitung. Immer mehr Unternehmen und Teams setzen Scrum und agile Entwicklungspraktiken ein oder behaupten das zumindest.
Als Scrum Coach komme ich zu vielen Unternehmen, und als Trainer führe ich viele Gespräche mit Teammitgliedern oder Vertretern von Organisationen, die Scrum – oft schon seit Jahren – verwenden. Dabei stelle ich manchmal fest, dass es viele Missverständnisse gibt, was Agil und Scrum ausmacht und was nicht.
1.1 Agile Softwareentwicklung
Im Gegensatz zu den klassischen Vorgehensweisen stützen sich agile Prozesse auf frühes und häufiges Feedback aufgrund von fertiggestellten Teillieferungen. Diese Teile müssen jedoch voll funktionsfähig sein, um den Anspruch an wertvolles Feedback zu erfüllen. Nur wirklich funktionierende Software erzeugt realistisches Feedback. Pläne, Diagramme oder Folienpräsentationen im Kontrast dazu verlangen danach, dass sich Menschen immer etwas vorstellen müssen, denn das Ergebnis ist (noch) nicht real. Je nach Komplexität und Vorstellungsvermögen der Beteiligten entsteht damit auch realistisches oder eben unrealistisches Feedback. Im klassischen Vorgehen entsteht reales Feedback oft erst nach Durchlauf vieler Phasen, was oft mehrere Monate, manchmal sogar mehr als ein Jahr dauert.
Iteratives Vorgehen
Im Kern einer jeden agilen Vorgehensweise stehen so genannte Iterationen, das sind Zyklen fixer Dauer, die zum Ziel haben, Feedback zu liefern. In iterativen Vorgehensweisen werden sämtliche Aktivitäten, die wir aus den klassischen Vorgehensmodellen kennen, wie Analyse, Design, Implementierung, Testen, Integrieren, Systemtest etc., durchgeführt, jedoch mehrmals. Wir durchlaufen diese Phasen in Zyklen.
Inkrementelles Vorgehen
Bei der inkrementellen Entwicklung wird das iterative Vorgehen verwendet, jedoch auf andere (neue) Teile des Systems angewendet (manchmal wird hierfür auch der Terminus „iterativ-inkrementell" verwendet). Es handelt sich also um eine Erweiterung des Produkts, und die Iteration betrachtet damit eine neue Entwicklung³ Bei der inkrementellen Entwicklung wird auch der Prozess verbessert. Das Ergebnis einer Iteration ist ein Inkrement des Produkts, es wird damit ausgehend von einem kleinen, funktionierenden Durchstich ständig erweitert und funktional gehalten.
Inkremente sind beispielsweise Features oder Teile der Produktfunktionalität. Es ist wesentlich, festzustellen, dass bei der inkrementellen Entwicklung ein vertikal durch die Systemarchitektur liegender Querschnitt geliefert wird. In klassischen Vorgehensweisen geschieht oft das exakte Gegenteil, es werden dabei horizontale Schichten sequenziell und oft gänzlich geliefert. Ein funktionaler und damit feedbackfähiger Querschnitt ist erst nach Lieferung der letzten Schicht möglich. Aus diesem Grund erfolgt bei klassischer Entwicklung das Testen der Funktionalität sehr spät.
In der inkrementellen Entwicklung konzentriert man sich auf kleine (vertikale) Teile, die auch sehr früh getestet werden können. Alle anderen Aktivitäten können damit auch beinahe zeitgleich in einer Iteration erledigt werden (Details dazu werden in Kapitel 6 vertieft).
Das Entwicklungsvorhaben wird nicht mehr für den gesamten Umfang und damit auch nicht für die gesamte Zeit im Detail geplant. Eine Planung mit hohem Detailgrad beschränkt sich hier auf die kommende Iteration. Planung und Entwicklung und damit auch die Validierung der Planung wechseln sich in raschen Rhythmen ab.
Mit einem deutlich geringerem Detailgrad beschäftigt sich der nächsthöhere Planungshorizont, der der unmittelbar folgenden Iterationen: Hier werden nur mehr gröbere Ziele auf Basis der Erkenntnisse aus den bisherigen Iterationen geplant.
Mehr Kundenwert in kürzerer Zeit
Agile Prozesse liefern schneller bessere Ergebnisse und sind fokussiert auf die frühe Bereitstellung von Kundenwert. Es wird bei der Priorisierung auf die Auslieferung von Features mit hohem Kundenwert geachtet. Mit jedem Inkrement steht so nach wenigen Wochen ein lieferbarer Teil des Produkts zur Verfügung, das im Idealfall vom Kunden bereits genutzt werden kann.
In einem typischen Scrum-Projekt wird z. B. alle zwei Wochen ein voll funktionsfähiger Teil der Software geliefert und steht für Feedback durch Kunden, Anwender oder Management zur Verfügung. Durch den Fokus auf die frühe Auslieferung von Features mit hohem Kundenwert entsteht deutlich früher ein bereits einsetzbares Produkt, das auf die Problemstellung fokussiert ist.
1.2 Agile Werte und Prinzipien
Die Bewegung in Form einer Ablehnung von klassischen, schwerfälligen Methoden und Vorgehensmodellen begann in den frühen 90er Jahren damit, dass einzelne Produktentwicklungsteams die bisher bekannten Prozesse der Softwareentwicklung wie iterativ und inkrementelles Vorgehen weitergetrieben haben. Darunter fallen auch Ken Schwaber und Jeff Sutherland, die Scrum entwickelt haben. Neben ihnen gab es eine Reihe weiterer, heute bekannter Persönlichkeiten, die ähnliche Praktiken einsetzen und damals noch „leichtgewichtig" genannte Methoden entwickelten. Viele von ihnen haben dazu auch auf wissenschaftlichen Konferenzen publiziert. Die zweite Hälfte der 90er Jahre war geprägt von vielen alternativen teilweise sehr revolutionären Ansätzen, die allesamt gegen die schwergewichtigen Methoden ankämpften.
Das Agile Manifest
Im Februar 2001 trafen sich diese Personen und versuchten zusammenzutragen, was ihre Vorgehensweisen gemeinsam haben, und kamen – obwohl sie es zuvor nicht glaubten – am letzten Tag zu einer Menge an Werten, die sie gleichermaßen hochhielten, und einem Dutzend Prinzipien sowie zu einem Konsens über deren Formulierung. Sie erschufen ein Manifest aus Werten, basierend auf Vertrauen und Respekt für einander, die die Organisationsmodelle fördern, die auf Individuen und Zusammenarbeit fußen. Übersetzt klingt das Manifest in etwa so:
Wir entdecken dadurch bessere Wege, Software zu entwickeln, indem wir es selber tun und andere dabei unterstützen, es zu tun. Durch diese Arbeit sind wir dazu gekommen,
Individuen und deren Interaktionen über Prozesse und Werkzeuge,
funktionierende Software über umfassende Dokumentation,
die Zusammenarbeit mit dem Kunden über Vertragsverhandlungen und
das Eingehen auf Veränderung über das Befolgen eines Plans
zu stellen. Während die Dinge auf der rechten Seite durchaus einen Wert darstellen, schätzen wir die Dinge auf der linken Seite mehr.
Sehr oft wurde dieses Manifest missverstanden und fehlerhaft interpretiert. Keineswegs war damit gemeint, dass es von nun an gar keine Dokumentation mehr geben sollte, sondern lediglich hinterfragt werden muss, wie viel Dokumentation nun wirklich notwendig ist und dass es besser ist, eine funktionierende Software zu haben, als schöne Dokumente, aber keine Software dazu.
Diese Aussagen wurden durch zwölf Prinzipien gestützt, die den Kern der agilen Softwareentwicklung definieren. Diese Prinzipien greifen ineinander und wirken als Ganzes:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung werthaltiger Software zufriedenzustellen.
Wir begrüßen veränderte Anforderungen auch in einer späten Entwicklungsphase. Agile Prozesse nutzen Veränderungen für den Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software häufig, von wenigen Wochen bis zu wenigen Monaten, mit einer Präferenz für kürzere Intervalle.
Anwender und Entwickler müssen täglich zusammenarbeiten.
Entwickle Projekte um motivierte Personen herum. Schaffe die Umgebung und Unterstützung, die sie benötigen, und vertraue ihnen, dass sie ihre Arbeit machen.
Die effizienteste und effektivste Methode, Informationen in ein und innerhalb eines Entwicklungsteams zu übermitteln, ist von Angesicht zu Angesicht.
Funktionierende Software ist das primäre Maß für Projektfortschritt.
Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Anwender sollen unendlich lang ein konstantes Entwicklungstempo beibehalten können.
Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design unterstützt Agilität.
Einfachheit – die Kunst, unnötige Arbeit zu vermeiden – ist essenziell.
Die besten Architekturen, Anforderungen und Designs entstehen in selbstorganisierenden Teams.
Das Team reflektiert in regelmäßigen Abständen über die Verbesserung seiner Arbeitsweise, verbessert sie und passt sie an.
1.3 Agile Vorgehensweisen
Zum Zeitpunkt der Publikation des Agilen Manifests wurde auch die Agile Alliance durch die Teilnehmer und originalen Unterzeichner gegründet. Diese waren gleichzeitig auch Vertreter der damals breiten agilen Methodenlandschaft. Von den ehemaligen rund 20 Vertretern dieser agilen Methoden sind heute nur noch einige wenige relevante übrig geblieben, die in der Praxis tatsächlich Anwendung finden. Ich möchte kurz auf drei davon eingehen, die mir heute wichtig erscheinen: XP und Scrum sowie eine aus einer anderen Bewegung entstandene Methodologie: Lean bzw. darin die Methode Software Kanban.
1.3.1 Extreme Programming
Extreme Programming (XP) war zumindest in Europa früher deutlich bekannter als Scrum. Kent Beck publizierte 1998 die Methode erstmals mit vier Werten und zwölf Praktiken. In einer zweiten Ausgabe wurde sie leicht erweitert und hat nun fünf Werte, 13 Praktiken, außerdem sind 14 Prinzipien beschrieben.
Extreme Programming hat, wie der Name bereits vermuten lässt, seinen Schwerpunkt in den Praktiken der Entwicklung (Programmierung), definiert aber auch einen Ablauf (Prozess), siehe Abbildung 1.1.
Zu den Praktiken gehören unter anderem testgetriebene Entwicklung, kontinuierliche Integration, inkrementeller Entwurf, räumliche Nähe, Pair Programming, kollektive Verantwortung für den Code etc. Diese Praktiken gehören heute zum guten Ton bei der agilen Entwicklung und haben damit für das Überleben von XP gesorgt. XP hatte immer einen stärkeren Fokus auf die Praktiken und weniger auf den Prozess.
Abbildung 1.1: Feedbackzyklen und Prozesse in XP (vgl. [17] und [18])
XP definiert dennoch Rollen, Iterationen und auch Meetings, z. B. das tägliche Treffen (Daily Standup) oder die Retrospektive. Kent Beck hat viele Ideen aus Scrum übernommen und damit eine mächtigere Methode entwickelt. In XP liegt jedoch der Schwerpunkt auf den Feedbackzyklen, wovon es sieben definiert (Abb. 1.1). Diese greifen ineinander, sodass ein konzentrisches Zyklensystem entsteht, das vom Minutentakt bis zum Rhythmus von mehreren Monaten dauert.
Ein wesentliches Merkmal von XP ist auch die Unterteilung der Planung in unterschiedliche Horizonte und damit unterschiedliche Detailgrade.
1.3.2 Scrum
Bei Scrum hingegen findet man gar keinen Schwerpunkt auf technischen Praktiken. Scrum legt deutlich mehr Wert auf die geregelte Zusammenarbeit in selbstorganisierten Teams. Es definiert dazu drei Rollen, Iterationen mit vier Meetings und drei Artefakte. Eines der Artefakte ist die Forderung nach einem auslieferbaren Produktinkrement am Ende einer Iteration (in Scrum „Sprint" genannt).
Betrachtet man die Mächtigkeit der Methoden, so ist XP deutlich mehr „verordnend" als Scrum, hat also mehr Regulative. Um jedoch Scrum erfolgreich in der Praxis umzusetzen, z.B. das auslieferbare Inkrement am Ende einer Iteration, benötigt man gute Entwicklungstechniken, z.B. die aus XP bekannten technischen Praktiken.
Scrum wurde von Jeff Sutherland zum ersten Mal bei der Smalltalk-Firma Easel in der heute bekannten Form eingesetzt und hat seine Wurzeln in der empirischen Prozesssteuerung. Durch zeitnahe Feedbackschleifen wird in Scrum zunächst auf Prozessverbesserung fokussiert⁴. Der Name Scrum kommt aus dem Rugby-Sport, wo dieser Begriff übersetzt etwa „Gedränge bedeutet. Das Scrum in Rugby ist ein komplexer Vorgang, bei dem sich zwei Teams gegeneinander drängen, um auf einer Seite des Gedränges den Ball zu „befreien
. Das geschieht durch eine Bewegung des gesamten Teams. Diese Bewegung des ganzen Teams ist Pate für den Namen Scrum, denn auch hier in der Softwareentwicklung geht es darum, dass ein selbstorganisiertes Team die Bewegung durch eine Iteration von der Anforderung bis hin zum auslieferbaren Produktinkrement als eine homogene Einheit durchführt. Jeff Sutherland, einer der beiden Väter von Scrum, spricht oft auch von einem „All at once"-Ansatz [24], bei dem jedes Teammitglied gleichermaßen Verantwortung für die gesamte Lieferung übernimmt, was auch impliziert, dass alle Aufgaben von Anforderung bis Lieferung wahrgenommen werden, und sich dazu selbst organisiert.
Abbildung 1.2: Der Scrum Flow
Unter anderem hat sich Sutherland angesehen, was Organisationen tun, wenn sie extrem erfolgreiche, effiziente und effektive Arbeitsleistungen benötigen. Dabei stieß er auf „Task Forces, die immer dann eingesetzt werden, „wenn’s um die Wurst geht
, also wirklich etwas Großes auf dem Spiel steht. Dieses Konzept hatte einen signifikanten Einfluss auf das Design von Scrum, insbesondere im Bereich der Teams. Es können daraus drei wesentliche Merkmale von Scrum-Teams abgeleitet werden:
1. Funktionsübergreifend: Es werden aus allen Disziplinen Experten benötigt. Diese arbeiten eng zusammen, um das Ziel zu erreichen. Ein hervorragendes Beispiel hierfür ist, wie bei IBM der Personal Computer entwickelt wurde. Nachdem der Branchenriese 1980 festgestellt hat, dass sich gerade ein wichtiger Markt an IBM vorbei entwickelt, wurde eine Task Force zusammengestellt, bestehend aus einem knappen Dutzend Experten aus unterschiedlichen Disziplinen, die in einem Jahr ein wettbewerbsfähiges Produkt auf den Markt zu bringen hatte. Diese Task Force war fokussiert, multidisziplinär und mit einer harten „Deadline" versehen.
2. Selbstorganisierend: Es gibt niemanden, der dem Team vorgibt, welche Aufgaben im Detail zu erledigen sind. Es gibt ein klares Ziel (und ein gewünschtes Lieferdatum), und das Team muss sich selbst organisieren, um alle notwendigen Aufgaben wahrzunehmen. Es muss sich selbst darum kümmern, dass jeder ausreichend und die richtigen Arbeiten verrichtet, sodass am Ende das gewünschte Ergebnis auch in der gewünschten Qualität herauskommt. Das Beispiel vom IBM PC verdeutlicht diesen Aspekt ebenfalls.
3. Kollektive Verantwortung: Das Team ist kollektiv für Erfolg oder Misserfolg verantwortlich, nicht ein Einzelner! In klassischen Organisationen sprengt das das Vorstellungsvermögen so mancher Personen, denn es braucht ja immer einen, der dann zur Verantwortung gezogen wird... wirklich? Nein, in Scrum können auch alle gemeinsam verantwortlich sein.⁵
So ein Team arbeitet in einem Sprint an einer von ihm ausgewählten Menge an Aufgaben. Diese Aufgaben oder besser Anforderungen an die Software stehen in einer Liste, dem Produkt-Backlog. Sprints sind geschützte Zeiträume fixer Dauer, zum Beispiel von zwei Wochen, während derer das Team nicht gestört wird. Im Gegenzug liefert das Team am Ende fertiggestellte, funktionierende Software, die die zuvor gewählten Anforderungen umsetzt. Ein wesentliches Merkmal von Scrum sind selbstorganisierende Teams.
Scrum definiert explizit keinen Prozess, wie und mithilfe welcher Arbeitstechniken das Team die Software entwickelt. In Scrum geht es um die ständige Reflexion und Verbesserung. Dazu definiert Scrum kurze Feedbackzyklen: Der Sprint erlaubt dem Team, im Rhythmus weniger Wochen über die Ergebnisse und den Prozess der Entwicklung zu reflektieren. Ein weiterer Zyklus auf Tagesebene – das „Daily Scrum" – erlaubt es dem Team, täglich zu reflektieren und seine Arbeit zu organisieren.
1.3.3 Lean und Kanban
Neben der agilen Bewegung hatte sich ein anderer Trend in die Softwarebranche bewegt, der jedoch aus dem Management von Produktionsunternehmen stammt. Genauer gesagt, entspringt diese Bewegung der Automobilbranche: Die Ideen Lean, Lean Production und Lean Product Development von Toyota haben sowohl die Entwicklung als auch die Produktion von Automobilen weltweit revolutioniert und fanden ihren Weg über viele weitere Branchen im letzten Jahrzehnt nun auch in die Softwareentwicklung.
Lean basiert auf zwei Säulen:
Kontinuierliche Verbesserung (Kaizen): Hier geht es um den Problemlösungsprozess an sich und damit darum, die Arbeit, die vom Team gemacht wird, permanent zu verbessern.
Respektiere die Leute: Es geht darum, zunächst Leute (und Teams) zu entwickeln und damit gute Produkte zu erzeugen. Dazu gehört neben Teamentwicklung und persönlicher Entwicklung, Partner zu entwickeln, aber auch verschwendungsvolle Arbeit zu vermeiden, die Wünsche des Kunden zu erfüllen usw.
Das Grundprinzip ist gleichzeitig auch eine grundlegende Philosophie von Lean: Ein nachhaltiges und langfristiges Denken zu etablieren und sich nicht auf kurzfristige Gewinne zu fokussieren. Basierend auf diesem Grundprinzip, konzentrieren sich die weiteren Prinzipien auf das Vermeiden von Verschwendung, holistische Managementprinzipien und laufende Prozessverbesserung. Toyotas Lean umfasst sowohl den Produktionsprozess (Manufacturing) als auch den Entwicklungsprozess von Produkten, also Automobilen.
Lean Software Development
Lean Software Development ist eine Menge an Prinzipien und Ideen, die von Toyotas Lean-Prinzipien auf Softwareentwicklung übertragen wurden. Mary und Tom Poppendieck haben dazu eine Menge an Arbeit geleistet, diese Ideen zu transformieren. Es entstanden daraus sieben Prinzipien und 22 „Denkwerkzeuge" für die Anwendung in der Entwicklung von Software [19], [20] und [21].
Abbildung 1.3: Die 14 Prinzipien von Lean (Quelle: [19])
Viele Ideen aus Lean Software Development und agiler Softwareentwicklung überlappen bzw. ergänzen sich sehr gut. So finden wir in Scrum und in Lean gleichermaßen die kontinuierliche Verbesserung (Kaizen), die Selbstreflexion (Hansei) sowie den Fokus auf die Entwicklung von selbstorganisierenden Teams aus Lean.
Kanban
David Anderson hat mit Kanban⁶ ebenso einige der Ideen aus Lean in das Umfeld der Softwareentwicklung transformiert und verfolgt damit die Idee, den Wertschöpfungsprozess, also den Prozess von der Idee über die Entwicklung bis hin zum auslieferbaren Produkt, in Form von Arbeitsschritten (Workflow Steps) zunächst einmal zu visualisieren [22]. Für diese Visualisierung wird ein physisches Board verwendet, das diese Schritte in Spalten aufträgt und Kärtchen verwendet, um den Status der Bearbeitung einer Aufgabe in diesem Prozess – also in den entsprechenden Spalten – zu signalisieren. Auf dieser Basis werden Schwachstellen transparent und Prozessverbesserungen forciert.
Kanban ist eine Change-Management-Methode, die sich im Wesentlichen drei Ideen aus Lean zunutze macht: Signalkarten (jap. „kan-ban"), verbrauchsgesteuerte Prozesse (Pull Systems) und Visualisierung. In Kanban gibt es fünf Regeln bzw. Schritte:
Visualisiere die Wertschöpfungskette (Fluss der Arbeit, Workflow)
Setze Limits für gleichzeitige Arbeit pro Schritt (Work in Progress Limits)
Messe und optimiere den Fluss der Arbeit (Manage Flow)
Mache die Regeln explizit
Verwende geeignete Werkzeuge (aus Lean), um den Prozess zu verbessern
Kanban beschränkt sich