Scrum mit Kanban und DevOps – Das Erfolgstrio – Blogserie

Teil 1: Scrum, Kanban und DevOps in der Praxis

Einleitung:

Geht es um die Durchführung und Planung von Software und IT Projekten, können wir zweifelsfrei feststellen, dass sich Agile Verfahrensweisen mittlerweile als weltweiter Standard etabliert haben. Die neueste „Status Quo Agilität“ Studie von 2017 hat dies erneut bestätigt und stellt heraus das 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 die 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 es Agilität, Unternehmen auf disruptive Marktherausforderungen angemessen zu reagieren. Es hat sich vielfach erwiesen, dass sich ein erheblicher Wettbewerbsvorteil daraus ergibt neue Produkte bereits innerhalb weniger Wochen oder Monate auf den Markt bringen zu können. Die so schnell gewonnenen Erkenntnisse aus der ersten Produktversion, können durch agile Entwicklung ebenso schnell in Folgeversionen verarbeitet und veröffentlicht werden. Das steigert die Erfolgswahrscheinlichkeit eines neuen Produkts erheblich.

Vielleicht haben Sie sich in diesem Kontext auch schon öfters gefragt wann sich ein Vorgehen nach Scrum und wann nach Kanban lohnt und wie überhaupt DevOps ins Bild passt?

Diese Frage versuche ich in diesem Blog-Beitrag kurz und prägnant zu beantworten.

Zunächst möchte ich Ihne eine kurze Zusammenfassung der Gemeinsamkeiten geben:

In allen drei Verfahren finden sich agile und „schlanke“ (lean) Konzepte deren Sinn es ist, häufig und nachhaltig funktionierende Software auszuliefern und dabei die Funktionalität mit dem jeweils höchsten Geschäftswert zuerst fertig zu stellen.

Dies wird ermöglicht durch die Bildung eines Entwicklerteams, in dem alle fachlichen und technologischen Fähigkeiten vorhanden sind, um diese fertige Software ohne fremde Hilfe zu liefern. Eine klare Definition was der fertige Zustand bedeutet, in der sogenannten Definition of Done, bildet die Grundlage dafür.

In enger Verbindung mit jeder Auslieferung steht dabei die kontinuierliche Inspektion der Ergebnisse durch alle Beteiligten und die sofortige Anpassung entsprechend der neu gewonnenen Erkenntnisse.

Weiterhin liegt der Fokus auf direkter Kommunikation unter Entwicklern und mit Kunden, sowie auf der hohen Autonomie des Teams. Es gilt das Prinzip, diejenigen Personen zu ermächtigen die sich am nächsten zur Information befinden.

Schließlich muss erwähnt werden, dass keines der drei Verfahren in der Praxis zum Erfolg führt, ohne weitreichende Automatisierung derjenigen Prozesse, die typischerweise viel manuellen Aufwand dabei verursachen die entwickelte Funktionalität in den auslieferbaren Zustand zu bringen. Dazu gehören insbesondere die Automatisierung der Software Tests gemäß der agilen Test-Pyramide und der Aufbau der sogenannten Continuous Integration und Delivery Pipeline mit entsprechenden Software Tools.

Agile Projekte in der Praxis:

Was gilt es nun zu beachten beim Einsatz von Scrum, Kanban und DevOps 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 (Abbildung 8) angestrebt wird. Vereinfacht kann man sagen, Scrum eignet sich besonders gut in Projekten in denen das Ziel sehr beweglich ist und entsprechende Richtungswechsel mit eingepreist werden müssen.

Bei komplexen Produktneuentwicklungen sind die Markterfordernisse zu Beginn noch im Nebel und werden erst mit der Zeit klarer, nachdem erste Erfahrungen aus den Sprint Lieferungen gesammelt und ausgewertet wurden. Eine stetige enge Abstimmung zwischen dem Entwicklungsteam und dessen Auftraggeber muss gewährleistet sein, um die notwendigen Änderungen Sprint für Sprint zu erkennen und umzusetzen. Scrum bietet dafü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. Und er kann bereits die frühen Produktinkremente für erste Marktforschung nutzen, um getroffenen Annahmen in Bezug auf seine Geschäftsidee zu bestätigen oder nachzusteuern.

Dabei hat der Einsatz der Kanban Methoden innerhalb von Scrum stets erheblichen Mehrwert gebracht, denn dadurch konnten wir im Team mehr Fokus erreichen auf die zügige Fertigstellung einzelner Funktionalitäten. Das heißt wir kamen nicht in die Gefahr an Stichtagen viele Aufgaben angefangen, aber kaum eine fertig zu haben. Und 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.

Nach meiner Beobachtung führt die Kombination von Scrum und Kanban regelmäßig zu einer höheren Motivation der Mitarbeiter durch die gefühlte und erlebte Autonomie, was wiederum in direktem Zusammenhang mit steigender Qualität der Arbeitsergebnisse steht.

Kanban ohne Scrum einzusetzen bietet sich dagegen in Projekten an, in denen das Ziel eher statisch ist. Zum Beispiel für die Weiterentwicklung eines Bestandssystems um neue Regularien zu erfüllen (aktuell etwa die neue EU Datenschutzgrundverordnung), oder für das entwickeln neuer Produkt KPIs. Außerdem kann ein Indikator die zu geringe Teamgröße sein, also bei weniger als 3 Entwicklern.

Durch Kanban können wir also in einem weniger dynamischen Umfeld trotzdem die Vorteile agiler Entwicklung nutzen.

Abschließend möchte ich feststellen das weder beim Einsatz von Kanban noch von Scrum, die Etablierung einer DevOps-Kultur fehlen darf. DevOps ist schließlich nur das konsequente Weiterdenken von Agilität. Wir sollten es als ihre nächste Stufe sehen, in der interdisziplinäre, cross-funktionale Teams die Gesamtheit des Produktlebenszyklus gestalten und bestimmen. DevOps, also 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, stellt eine grundlegende Voraussetzung für eine erfolgreiche agile Projektdurchführung dar. Nur wenn die Spezialisten aus Entwicklung, Operation, Test, Sicherheit und Business Hand in Hand zusammenarbeiten hin auf ein gemeinsames Ziel, 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.

Teil 2 Scrum und Kanban erklärt 

Teil 3 DevOps erklärt

Quellen Angabe:

Status Quo Agilität 2016 / 17