In der Durchführung und Planung von Software- und IT-Projekten haben sich agile Verfahrensweisen mittlerweile als weltweiter Standard etabliert. In der aktuellen „Status Quo Agilität“-Studie von 2017 wird dabei herausgestellt, dass Scrum, gefolgt von Kanban und DevOps am häufigsten zum Einsatz kommen. Die Gründe für die stetig steigende Popularität liegen in der besseren Beherrschbarkeit von komplexen Herausforderungen der Digitalisierung, sowie der damit verbundenen Notwendigkeit, Anforderungen häufig zu ändern. Beispiele solcher Herausforderungen, die der Markt zunehmend stellt, sind die Verbreitung von intelligent-autonomen Systemen wie dem selbstfahrenden Auto und die intensivere Vernetzung von Heim- und Industriegeräten. Anders ausgedrückt erlaubt Agilität, Unternehmen auf disruptive Marktherausforderungen angemessen zu reagieren. Vielfach hat es sich erwiesen, dass durch die schnelle Markteinführung von wenigen Wochen oder Monaten, ein erheblicher Wettbewerbsvorteil entsteht. Zügig gewonnenen Erkenntnisse aus der ersten Produktversion können durch agile Entwicklung ebenso schnell in Folgeversionen verarbeitet und veröffentlicht werden. Die Erfolgswahrscheinlichkeit eines neuen Produktes steigert sich dadurch enorm.
Haben Sie sich in diesem Kontext auch schon öfters gefragt, welche Verfahrensweise in welches Projekt passt? Wann sollte man sich für Scrum oder Kanban entscheiden und wie passt DevOps ins Bild?
Diese Fragen versuche ich in diesem Blog-Beitrag kurz und prägnant zu beantworten.
Gemeinsamkeiten von Scrum, Kanban und DevOps
In allen drei Verfahren finden sich agile und „schlanke“ (lean) Konzepte. Deren Sinn ist es, nachhaltig funktionierende Software auszuliefern und dabei die Funktionalität mit dem jeweils höchsten Geschäftswert zuerst fertig zu stellen.
Durch die Bildung eines Entwicklerteams, in welchem alle fachlichen und technologischen Fähigkeiten vorhanden sind, wird die Fertigstellung und Lieferung einer Software ohne fremde Hilfe ermöglicht. Mehr Details hierzu finden Sie in meinem Scrum und Kanban Blog-Beitrag.
Die sog. Definition of Done bildet die Grundlage für die Produkterstellung. In dieser werden Fertigstellungskriterien für ein Produkt festgestalten, an der sich das Team bei der Planung und Durchführung orientieren kann.
Mit jeder Produktauslieferung erfolgt kontinuierlich auch die Inspektion der Ergebnisse anhand von Anwender-Feedback sowie zuvor entwickelter Business und IT Metriken. Die so gewonnenen Verbesserungsvorschläge und Änderungswünsche werden in den nächsten Produktiterationen eingearbeitet, so dass ein immer besserer Prodct-Market-Fit über die Zeit entsteht.
Der Fokus von agilen Verfahrensweisen liegt auf der direkten Kommunikation unter den Entwicklern und mit Kunden. Das Entwicklerteam besitzt bei der Herstellung des Produktes stets eine hohe Autonomie und es gilt das Prinzip, diejenigen Personen zu ermächtigen, die sich am nächsten zur Information befinden.
Ein entscheidender Erfolgsfaktor für alle agilen Verfahrensweisen ist die weitreichende Automatisierung der Prozesse, die sonst für einen auslieferbaren Zustand typischerweise viel manuellen Aufwand verursachen. Dazu gehören insbesondere die Automatisierung der Softwaretests gemäß der agilen Test-Pyramide und der Aufbau der sogenannten Continuous Integration und Delivery Pipeline mit entsprechenden Software Tools.
Meine Beobachtungen von Agilität in der Praxis
Ich habe bisher gute Erfahrungen damit gemacht, Scrum in Projekten einzusetzen, in denen eine Neuentwicklung von komplexen Produkten gemäß der Stacey Matrix (siehe Abbildung) angestrebt wird. Vereinfacht gesagt, eignet sich Scrum besonders gut für Projekte, wo das Ziel sehr beweglich ist und entsprechende Richtungswechsel mit eingeplant werden müssen.
Abbildung 1: Komplexität in einem Projekt
Oft sind Markterfordernisse bei komplexen Produktneuentwicklung sehr unklar. Diese werden erst mit Zeit klarer, nachdem erste Erfahrungen aus Sprint Lieferungen gesammelt und ausgewertet wurden. Daher muss eine regelmäßige enge Abstimmung zwischen dem Entwicklungsteam und dessen Auftraggeber gewährleistet sein, um notwendige Änderungen Sprint für Sprint zu erkennen und umzusetzen. Scrum bietet hierfür den perfekten Rahmen, denn durch seine vorgeschriebenen Ereignisse werden alle Beteiligten in regelmäßiger Routine zusammengebracht. Besonders das Sprint Review erlaubt es dem Kunden, sich in kurzen Abständen ein realistisches Bild des Produkts zu machen. Darüber hinaus kann er bereits erstellte Produktinkremente für erste Marktforschungsmaßnahmen nutzen und so das Produkt entweder bestätigen oder nachsteuern lassen.
Der Einsatz der Kanban Methode innerhalb von Scrum hat dabei stets zu einem erheblichen Mehrwert geführt, denn dadurch konnten wir im Team den Fokus auf die zügige Fertigstellung einzelner Funktionalitäten setzen. D.h., wir kamen nicht in die Gefahr, an Stichtagen viele Aufgaben angefangen zu haben, aber kaum welche fertig erstellt zu haben. Die Gefahr, Mitarbeiter zu überlasten, wurde zusätzlich gebannt, da sich das Team ein WIP Limit setzte und nach Pull Prinzip arbeitete. Außerdem bot das Kanban Board auch im Rahmen von Scrum die beste Visualisierungsmethode, um den Fortschritt des Teams laufend sichtbar zu machen.
Die gefühlte und erlebte Autonomie des Entwicklungsteams, die in der Kombination von Scrum und Kanban mit einhergeht, führt meiner Beobachtung nach zu einer höheren Motivation der Mitarbeiter. Das wiederum steht im direkten Zusammenhang mit einer steigenden Qualität der Arbeitsergebnisse.
Kanban ohne Scrum einzusetzen bietet sich dagegen in Projekten an, in denen das Ziel eher statisch ist. Beispielprojekte sind die Weiterentwicklung eines Bestandssystems, um neue Regularien zu erfüllen (aktuell etwa die neue EU Datenschutzgrundverordnung) oder die Entwicklung neuer Produkt KPIs. Ein weiterer Grund für den Einsatz von Kanban kann eine geringe Teamgröße (kleiner drei) sein. Durch Kanban können wir in einem weniger dynamischen Umfeld trotzdem die Vorteile agiler Entwicklung nutzen.
Abschließend möchte ich festhalten, dass weder beim Einsatz von Kanban noch von Scrum die Etablierung einer DevOps-Kultur fehlen darf. DevOps ist als der Abbau von bürokratischen Silos und langwierigen Genehmigungsverfahren beim gleichzeitigen Aufbau weitreichend automatisierter Produkt-Lieferstrecken und Feedback-Flows von Entwicklungs- über Test- in die Live-Umgebungen zu verstehen. Somit ist DevOps das konsequente Weiterdenken von Agilität und sollte als seine nächste Stufe betrachtet werden, in der interdisziplinäre, cross-funktionale Teams die Gesamtheit des Produktlebenszyklus gestalten und bestimmen. Es stellt eine grundlegende Voraussetzung für eine erfolgreiche agile Projektdurchführung dar. Nur wenn die Spezialisten aus Entwicklung, Operation, Test, Sicherheit und Business gemeinsam auf ein Ziel hinarbeiten, wird sich das agile Erfolgsversprechen einlösen. Dementsprechend sollten wir Projektteams bereichsübergreifend bilden, in DevOps schulen und mit weitreichenden Berechtigungen für den Betrieb ausstatten.