Scrum – Kurzübersicht mit Infografik

Scrum erlangte seit Mitte der 1990er Jahren größere Bekanntheit als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten. Es beruht auf Erkenntnisse von Ken Schwaber und Jeff Sutherland über Wettbewerbsvorteile, die durch die Verbindung von inkrementellem, iterativem und empirischem Vorgehen im Vergleich zum Wasserfallvorgehen in Software­entwicklungs-Projekten entstehen. Ersteres erzeugt eine Risikominimierung durch eine hohe Transparenz des Entwicklungsfortschrittes und Letzteres sorgt für eine kontinuierliche Überprüfung der Ergebnisse und die Anpassung der Produktentwicklung. Damit erhöht sich die Wahrscheinlichkeit deutlich, Projekte innerhalb von Budget und Zeit abzuschließen und gleichzeitig ein marktgerechtes Produkt abzuliefern.

Scrum besticht durch sein minimalistisches Regelwerk und seine leichtgewichtige Struktur, die den Einstieg sehr einfach macht. Die drei wichtigsten internen Rollen des Projektteams sind der Scrum Master, der Product Owner und das Entwicklungs-/Umsetzungs-Team. Jeder dieser Rollen werden feste Aufgaben und Verantwortlichkeiten zugeordnet. Gemeinsam sollen sie autark und autonom ein Produkt entwickeln und in fortlaufenden Zyklen ausliefern. Für die Steuerung eines Scrum-Projekts stehen die sogenannten „Artefakte“ zur Verfügung:

  • Sprint (kontinuierlicher Entwicklungszyklus, 1 – 4 Wochen, abhängig davon wie oft Lieferung und Feedback sinnvoll sind)
  • Produkt Backlog (Anforderungskatalog, gepflegt vom PO)
  • Sprint Backlog (die Anforderungen des laufenden Entwicklungszyklus, umgesetzt vom Entwicklungsteam)
  • Product Inkrement (wird ausgeliefert vom Entwicklungsteam nach Abnahme durch PO und Stakeholder)

Eine Definition of Done gibt an, wann ein Inkrement als fertig gelten kann. Sie besteht aus einer Liste mit Fertigstellungskriterien und Definitionen des fertigen Zustands, z.B. kann darin stehen, dass eine bestimmte Testabdeckung nicht unterschritten werden darf und bestimmte Arten von Tests vorgeschrieben sind, wie die für innere Logik (Unit) und Integration. Sinnvollerweise sollten auch die erforderlichen Schritte zur Auslieferung, die sogenannten Build und Deployment Tätigkeiten, darin festgelegt werden.

Nach jedem Sprint findet ein Sprint Review Meeting statt, in welchem das Team dem Product Owner und dem Kunden das Sprintergebnis vorstellt. Idealerweise handelt es sich um ein Produktinkrement, welches in Echtzeit vorzuführen ist. Je nach Zufriedenheit mit dem Ergebnis wird das Produkt akzeptiert, oder es werden ergänzende Anforderungen definiert bzw. eine Neuausrichtung eingeschlagen. In der Retrospektive erfolgt eine Betrachtung auf den vergangenen Sprint, um für künftige Sprints Optimierungsmöglichkeiten aufzudecken.

Ein neuer Sprint wird schließlich nahtlos mit einem Sprint Planning Meeting eingeläutet. In dieser Sitzung stellt der Product Owner die am höchsten priorisierten Anforderungen vor und das Entwicklungsteam schätzt erfahrungsbasiert deren Aufwand. Gemeinsam legen sie fest, welche Anforderungen im Sprint umgesetzt werden und bestimmen (optional) dafür ein übergeordnetes Sprint Ziel. Nur solche Anforderungen können dabei berücksichtigt werden, die vom Team im Vorfeld genau genug spezifiziert und klein genug zerteilt wurden. Dieses sogenannte Refinement wird zumeist als regelmäßiges Arbeitstreffen vom Team durchgeführt.  Anschließend an das Sprint Planning wird im Sprint Planning 2 von den Entwicklern bestimmt, in welcher Weise die Arbeitspakete erreicht und welche Details umgesetzt werden.

Sobald der Sprint beginnt, trifft sich das Team einmal täglich immer zur gleichen Zeit, um die Zusammenarbeit zu koordinieren und den Fortschritt auf das Sprint Ziel zu überprüfen. Es wird empfohlen, dieses sogenannte Daily Scrum im Stehen abzuhalten, um Aufmerksamkeit zu fördern.

Zusammengefasst sprechen wir von den vier Scrum Events, die zeitlich durch eine feste Timebox (maximale Länge) reglementiert sind, sowie einen festen, wiederkehrenden Abstand haben. In einem Projekt mit zweiwöchigen Sprints dauern Review und Retrospektive üblicherweise 1-2 Stunden und die Planung 2-4 Stunden. Unabhängig von der Sprint-Länge ist die Timebox des Daily immer 15 Minuten.

Scrum sieht zusätzlich zu den Entwicklern und dem PO noch den Scrum Master vor. Er soll seinem Team bei der korrekten Anwendung von Scrum behilflich sein und sie zu einer selbstorganisierten Arbeitsweise hinführen. Der Scrum Master soll auch dabei helfen, agile Prinzipien und Kultur in der übergeordneten Gesamtorganisation zu fördern. Das heißt, die Aufgaben des klassischen Projektmanagers werden in Scrum-Projekten nicht vom Scrum Master, sondern vom Product Owner und den Entwicklern übernommen.

2010 wurde der Scrum Guide unter scrumguides.org von Schwaber und Sutherland als gültiger Leitfaden für Scrum veröffentlicht und seitdem regelmäßig aktualisiert. Die einheitliche und klare Beschreibung von Scrum förderte dessen Popularität stark und es entwickelte sich dadurch zum weltweit meist angewendeten agilen Verfahren. Unter agilemanifesto.org werden die Agilität definiert und ihre 12 Prinzipien beschrieben, die sich auch in Scrum wiederfinden. Meine Scrum-Kreislauf Grafik bringt das Ganze auf den Punkt:

Scrum Infografik mit BiKaBlo

DevOps erklärt

Teil 3 DevOps

Die DevOps Bewegung

Anders als bei Scrum oder Kanban handelt es sich bei DevOps nicht um definierte Methoden oder Prozesse, sondern genau wie bei Agilität um eine Bewegung die einen Paradigmenwechsel in der Unternehmenskultur anstrebt. Initiiert wurde diese Bewegung von dem Belgier Patrick Debois der mit Gleichgesinnten eine agile Infrastruktur anstrebte und inspiriert von dem Vortrag „10 Deploys per Day: Dev and Ops Cooperation at Flickr“ von John Allspaw und Paul Hammond, 2009 die ersten DevOps Days in Gent organisierte.

Was unterscheidet nun die DevOps Bewegung von der agilen Bewegung?

Die agile Bewegung hat sich seit der Deklaration des Manifestes 2001 für die Fokussierung auf Erzeugung von Kundenwert durch frühe, kontinuierliche Auslieferung und für die Humanisierung der Arbeitsprozesse in der Softwareindustrie eingesetzt. Durch die Einführung von Scrum und Kanban im Softwareentwicklungsprozess haben viele Unternehmen seither versucht die Vorteile dieser Agilität für sich zur erschließen. Allerdings scheitern bis heute sehr viele dieser Agilen Transitionen daran, dass die beteiligten Mitarbeiter an Entwicklung und Betrieb des Softwareprodukts in streng und bürokratisch voneinander getrennten Silos angesiedelt sind. Denn dadurch wird die gemeinsame Zielorientierung auf die Erzeugung des Kundenwerts untergraben und keine echte Zusammenarbeit gemäß den agilen Prinzipien kann entstehen. Diese Silos bestehen in größeren Unternehmen häufig aus innerhalb der IT-Organisation getrennten Abteilungen für Softwareentwicklung, Betrieb, Qualitätssicherung und IT-Sicherheit die im Auftrag diverser Fachabteilungen der Business-Organisation arbeiten. Konkret entsteht bei Mitarbeitern dadurch eine verzerrte Wahrnehmung von entgegengesetzten Interessen, obwohl sie am gleichen Produkt arbeiten. Beispiele dafür sind Entwicklungsteams die schnell viel Funktionalität schaffen, aber sich nicht für den Betrieb und die Qualitätssicherung des Produkts verantwortlich fühlen, sondern stattdessen nur über Incident-Tickets und Bug-Reports mit den Kollegen aus Betrieb und QA kommunizieren. Andererseits Betriebsingenieure die möglichst wenige Änderungen am Produkt wollen um die Stabilität nicht zu gefährden. Und die sich gleichzeitig nicht genügend Einblick in die Entwicklung verschaffen, um gemeinsam sinnvolle Metriken für die Produktverbesserung zu entwickeln. Dann haben wir Tester die meinen aus Gründen der Objektivität nicht zu eng mit den Entwicklern zusammenarbeiten zu können, wodurch der Testbetrieb ineffektiv und langsam wird. In diesem Kontext werden bürokratische Genehmigungsverfahren aufgebaut und streng formale Übergabeprozesse eingerichtet zwischen Entwicklung, QA, IT-Sicherheit und Betrieb, mit dem Ziel die jeweils eigene Position abzusichern und bei Zwischenfällen die jeweils andere Seite zur Rechenschaft ziehen zu können. Der Erfolg des Unternehmens und des anvertrauten Produktes gerät dabei zur Nebensache. Dementsprechend dauert es oft Monate bis ein neuentwickeltes Produktfeature in Betrieb genommen wird.

Das heißt diese Struktur verhindert häufige und kontinuierliche Inbetriebnahme (Continuous Deployment) entwickelter Funktionalität, denn die Freigaben (Releases) stecken im Stau. Dadurch entsteht zu großer Release-Umfang, wodurch die Deployments wiederum hochgradig fehleranfällig werden. Auch das schnelle Messen und Auswerten der Ergebnisse aus dem Betrieb ist damit unmöglich. Das führt zum Verlust wichtiger Erkenntnisse zur Produktverbesserung und letztendlich dazu, dass die Produkte nicht konkurrenzfähig sind und oft wieder von Markt verschwinden.

Die DevOps Bewegung widmet sich genau dieser Problematik, die mit dem Einführen von Agilität in vielen Unternehmen nicht überwunden wurde. Das Ziel von DevOps ist also Unternehmen dazu zu bringen ein Umfeld und eine Infrastruktur zu schaffen, die es Entwicklern, Testern, Betriebsingenieuren und Business-Ownern ermöglicht als echtes Team mit gemeinsamem Ziel ein Produkt so zu entwickeln und zu betreiben, dass dabei häufig und kontinuierlich neuer Kundenwert geliefert und messbar gemacht wird. Die Techniken, Prozesse und Werkzeuge die DevOps-orientierte Unternehmen dafür einsetzen heißen zusammengefasst Continuous Delivery (CD), erstmals definiert 2010 durch Jez Humble und David Farley in ihrem gleichnamigen Buch.

Erfolgreich mit DevOps zu sein erfordert neben echter Zusammenarbeit ohne Silos, auch dass Scrum oder Kanban Teams von der ersten Zeile Code an die Optimierung für Continuous Delivery mitentwickeln und dies in ihrer Definition of Done auch festlegen.

Bei der Komposition solcher agilen Teams reicht es also nicht wenn Business Owner und Projekt-verantwortliche darauf achten, für die Erstellung der gewünschten Funktionalität qualifizierte Entwickler zu finden (zum Beispiel Java, JavaScript, Backend Framework XY, Frontend Framework YZ). Um DevOps gerecht zu werden müssen Teams auch solche Methodenkompetenz beherrschen und stetig erweitern, die es braucht um eine automatisierte Lieferkette inklusive Qualitätssicherung (Continuous Delivery Pipeline) in eine Entwicklungs-, dann Test- und schließlich fehlertolerante Live-Umgebung zu schaffen. Außerdem müssen sinnvolle Metriken laufend entwickelt werden, die wertvolle Erkenntnisse zurück in die Entwicklung liefern. Das bedeutet Entwicklung und Betrieb werden teilweise von denselben Personen ausgeführt, beziehungsweise Entwickler sind Teil von Betrieb und umgekehrt. Entweder müssen dazu sogenannte Team of Team Konstrukte zwischen Entwicklungs- und Betriebsmannschaft gebildet werden, oder ein Team umfasst die nötigen Experten aus Entwicklung und Betrieb. In jedem Fall geschieht eine Bevollmächtigung der Entwickler für den Betrieb des Softwareproduktes. Dies bedeutet aber nicht das Ende von spezialisierten QA-, IT-Sicherheits- und Betriebsingenieuren, vielmehr arbeiten diese nun bereits in frühen Projektphasen mit der Entwicklung im Team zusammen, um mit ihrer Kompetenz den Aufbau der Continuous Delivery Pipeline zu begleiten.

Die CD Pipeline ist also eine Instrumentenkette die gleichzeitig zum eigentlichen Produkt entwickelt werden muss, damit Teams die Funktionalitäten dieses Produkts auch in kurzen Abständen dem Kunden ausliefern können. Dabei soll das Risiko von Betriebsstörungen durch die kleinteiligen Auslieferungen auf ein Minimum reduziert werden. Zusätzlich soll die Pipeline automatisiert solches Feedback liefern, das es Teams erlaubt zu lernen wie das Produkt für Kunden noch besser gemacht werden kann.

Dementsprechend lauten die drei Kernprinzipen die DevOps ausmachen nach Wichtigkeit sortiert: „Establish Flow“ (Erzeuge Fluss), „Enable Feedback“ (Sorge für Feedback) und „Amplify Learning“ (Fördere das Lernen), siehe Abbildung 11.

Abbildung 11

Technische Anwendungstipps aus der Praxis

Während ich bisher die technischen Details bewusst im Vagen gelassen habe, möchte ich nun einige wichtige Techniken konkretisieren.

Die nötigen technischen Methoden zum Aufbau der CD Pipeline bauen logisch und zeitlich aufeinander auf. Sie haben ihren Ursprung in der agilen Softwareentwicklung und wurden durch die DevOps Bewegung wesentlich weiterentwickelt.

Am Anfang in Stufe Eins steht die Versionsverwaltung und die im Team geteilte Code Basis. Zum Beispiel nutzen wir dafür die Open-Source Tools Git, GitLab (CE) und Nexus Repository Manager. Es gilt hier die Regel das die Entwickler ihren neuen Code mehrmals täglich in die geteilte Basis integrieren und dabei auftretende Fehler sofort beheben.

Darauf bauen in Stufe Zwei die automatisierten Software Tests gemäß der agilen Test-Pyramide auf (siehe Abbildung 12). Üblicherweise setzen wir in der Umsetzung die agilen Methoden Test Driven Development und Pair Programming oder Code Review ein. Hier empfiehlt es sich Open-Source Testwerkzeuge zu nutzen, die es für jede Programmierumgebung gibt und durch die wir viel Zeit beim Erstellen der Tests sparen können. Die Auswahl des Werkzeugs hängt von den technischen Rahmenbedingungen des Produkts ab das wir bauen. Für webbasierte Produkte die mit Schnittstellen basierend auf dem http-Protokoll arbeiten und über grafische Interfaces im Browser bedient werden, empfehle ich eine Testwerkzeug-Kombination aus xUnit für die Code Klassen, Rest Assured für die Code Schnittstellen (API), Cucumber allgemein für anforderungsbasierte Tests und Selenium für das Browser Interface.

Abbildung 12

In der dritten Stufe, der Continuous Integration, werden diese Tests dann systematisch ausgeführt sobald der Code einer neuen Funktionalität in die Basis integriert wird. Hierfür nutzen wir den Continuous Integration Server, der den Code nach erfolgreichen automatischen Tests von den Entwicklungs- in die Testumgebungen und schließlich in die Live-Umgebung bringt (siehe Abbildung 13). Sowie bei nicht erfolgreichen Tests sinnvolle Meldungen zurück an die Entwicklung gibt. Unterm Strich sparen wir mit diesem System viele Ressourcen, da die Aufwände für manuelle Tests auf ein Minimum reduziert werden. Auch bei der Auswahl des Continuous Integration Server kann man guten Gewissens zu Open Source Produkten greifen. Gute Erfahrung habe ich mit Jenkins und mit GitLab CI (CE), beides Open Source, gemacht.

 

Abbildung 13

Für die letzte Stufe muss schließlich ein Feedbacksystem, basierend auf Metriken aus dem Betrieb des Produkts, entwickelt werden. Hier empfiehlt sich Grafana zur Visualisierung und Analyse kombiniert mit Prometheus zum aggregieren der Metriken. Alternativ bietet sich die Elastic-Stack Werkzeugkette an. Egal welche Kombination wir wählen, alle genannten sind unter Open-Source Lizenz nutzbar. Abbildung 14 zeigt vereinfacht den Feedback-Fluss aus dem Betrieb zurück in die Entwicklung.

Abbildung 14

Abschließend möchte ich zwei weitere technologische Voraussetzungen nicht unerwähnt lassen, ohne die wir Continuous Delivery nur eingeschränkt umsetzen können.

Die erste Voraussetzung ist Infrastructure as a Service (IaaS), das heißt wir sollten entweder eine Private oder eine Public Cloud für unser Produkt nutzen. Der Grund ist die viel leichtere Skalierbarkeit der Infrastruktur die mit den Ansprüchen des Produkts mitwachsen muss. Mittlerweile gibt es ein allumfassendes Angebot in diesem Bereich, der vom Marktführer Amazon (AWS)
angeführt wird, gefolgt von Microsoft (Azure). Für den privaten Cloud Bereich empfiehlt sich zum Beispiel Red Hat OpenShift Container Platform.

Die zweite Voraussetzung ist eine CD-taugliche Softwarearchitektur für das zu entwickelnde Produkt zu wählen. Dazu gehört das Produkt technisch in sogenannte Microservices zu gliedern, das heißt Produktdomänen wie zum Beispiel die Webseitenoberfläche oder die Userauthentifizierung als eigenständige Miniprodukte zu verpacken. In dem man das Gesamtprodukt aus einer Kombination von Miniprodukten entwickelt die nur lose miteinander gekoppelt sind, ergeben sich wesentliche Vorteile. Zum einen löst der Ausfall eines Miniprodukts nicht mehr einen kompletten Betriebsausfall des Produkts aus. Zum Beispiel lässt sich der Katalog eines Webshops noch browsen, aber der Bestellvorgang nicht auslösen, wenn das Miniprodukt zur Bezahlung ausfällt. Zum anderen kann ein Miniprodukt unabhängig vom Gesamtprodukt weiterentwickelt und ausgeliefert werden, ohne den Aufwand eines Deployment des Gesamtproduktes zu erfordern. Je kleiner die auszuliefernden Miniprodukte gegliedert sein können, desto einfacher und schneller lassen sich Fehler eingrenzen und beheben. So übersteigt dann der geschäftliche Vorteil der aus sehr häufigen Deployments entsteht das damit eingegangene Risiko von Betriebsstörungen. Weiterhin können dadurch Hypothesen-getriebene Produktexperimente zu äußerst geringen Kosten durchgeführt werden.

Für beide CD Voraussetzungen gibt es bewährte Open-Source Werkzeuge mit denen sich eine Microservice Architektur in Verbindung mit IaaS optimal umsetzen lässt. Die beiden Hauptwerkzeuge die sich empfehlen sind Docker und Kubernetes. Docker kapselt die Miniprodukte in leichtgewichtigen virtuellen Laufzeitumgebungen, genannt Container, samt allen ihren Abhängigkeiten ab, so dass sie auf dem Linux Hostserver keine eigene Installation brauchen und nur sehr wenig Ressourcen verbrauchen. Es ist sinnvoll, wenn Entwickler bereits von Beginn an Docker Container für ihren Code erstellen und auf der Entwicklungsumgebung testen. Die Mini-Produkte eines Gesamtproduktes können in Containern auf verschiedenen Hostservern betrieben werden und kommunizieren untereinander durch definierte Schnittstellen über ein IP basiertes Netzwerk. Um mit diesem System das Produkt robust und fehlertolerant betreiben zu können, bedarf es zusätzlich einer Orchestrierung die dafür sorgt das Container mehrfach redundant auf unterschiedlichen Hostservern an verteilten Standorten repliziert werden und das Container mit Fehlfunktionen automatisch erneuert werden. Hierfür ist das Werkzeug der Wahl Kubernetes. Abbildung 15 zeigt das Kubernetes Betriebssystem welches aus Master und Nodes besteht, die über mehrere verbundene Hostserver verteilt installiert sind. Innerhalb der Nodes werden die Docker Container in sogenannten Pods betrieben, überwacht und repliziert. Zusätzlich bietet es sich an die Zusammensetzung eines Kubernetes Produktiv Systems in ein Paket zu schnüren und zu Versionieren, so dass wir bestimmte Zustände unseres Produkts einfrieren und bei Bedarf beliebig oft wiederherstellen können. Hierfür steht uns der Kubernetes Package Manager Helm zur Verfügung.

Produkte die eine Kubernetes-Betriebsarchitektur nutzen eignen sich hervorragend für CD, da sie Deployments ohne Downtime ermöglichen und auch langsames phasenweises ausrollen, sowie schnelles zurückrollen neuer Versionen beherrschen, falls Fehler auftreten.

Abbildung 15

Je nachdem welche Programmiersprachen für die Schaffung eines Softwareprodukts gewählt wurden, bieten sich bestimmte Frameworks und Werkzeuge an, die sich sowohl gut eignen für eine Microservice Architektur, als auch geeignet für den Betrieb mit Docker und Kubernetes sind. Ich kann im Java Backend Umfeld hier Spring Boot empfehlen und für Browser basierte Frontends das JavaScript Framework Angular. Außerdem empfiehlt sich für das Management der Datenströme zwischen den Backend und Frontend Services der Einsatz des Java-basierten Werkzeuges Kafka. Zur persistierung von Daten bieten sich noSQL Datenbanken wie MongoDB an, da sie schemafrei sind und somit besser für CD geeignet.

Die gute Nachricht ist das jedes einzelne dieser Frameworks oder Werkzeuge wiederum unter Open-Source Lizenzen vertrieben wird.

Teil 1: Scrum, Kanban und DevOps in der Praxis

Teil 2 Scrum und Kanban erklärt

Quellen Angabe:

Patrick Debois – Agile Infrastruktur (2009) PDF

Kim, Gene; Humble, Jez; Debois, Patrick; Willis, John: Das DevOps Handbuch (2017)

Phillips, Andrew, Michiel Sens; de Jonge, Adriaan; van Holsteijn, Mark: The Manager’s Guide to Continuous Delivery (2014)

Humble, Jez; Farley, David: Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation (2010)

Continuous Delivery Grafik von Slideshare Solidify-Sverige

Continous Integration Grafik von Jason Z

https://de.wikipedia.org/wiki/XUnit

http://rest-assured.io/

https://www.seleniumhq.org/

https://jenkins.io/

https://about.gitlab.com/features/gitlab-ci-cd/

https://www.elastic.co/de/elk-stack

https://prometheus.io/

Kubernetes Grafik von Khtan66 – Eigenes Werk, CC BY-SA 4.0

https://www.docker.com/

https://kubernetes.io/

https://helm.sh/

https://projects.spring.io/spring-boot/

https://angular.io/

https://kafka.apache.org/

https://www.mongodb.com/de

Scrum und Kanban erklärt

Teil 2 Scrum und Kanban erklärt

Scrum:

Scrum erlangte seit Mitte der 1990’er Jahren durch Publikationen und Vorträge von Ken Schwaber und Jeff Sutherland größere Bekanntheit als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten (Abbildung 10). Es beruht auf durch Schwaber und Sutherland in der Praxis gewonnen Erkenntnissen, über den Wettbewerbsvorteil der durch die Verbindung von inkrementell, iterativem mit empirischem Vorgehen in Softwareentwicklungs-Projekten entsteht, insbesondere im Vergleich zum Wasserfall Vorgehen. Ersteres erzeugt Risikominimierung durch hohe Transparenz des Entwicklungsfortschrittes und letzteres sorgt für die kontinuierliche Überprüfung der Ergebnisse und die Anpassung der Entwicklung an neue Erkenntnisse. Damit erhöht sich die Wahrscheinlichkeit deutlich, Projekte innerhalb von Budget und Zeit abzuschließen und dabei ein marktgerechtes Produkt abzuliefern. Abbildungen 7, 8 und 9 machen dies anschaulich.

Abbildung 5

Abbildung 6

Abbildung 7

Abbildung 8

Scrum besticht durch sein minimalistisches Regelwerk und seine leichtgewichtige Struktur die den Einstieg sehr einfach macht. Es definiert ein Team bestehend aus: den Entwicklern (3-9 Personen), dem Produkt Owner (PO) und dem Scrum Master. Gemeinsam sollen sie autark und autonom ein Produkt entwickeln und in fortlaufenden Zyklen, genannt Sprint, alle 1-4 Wochen ausliefern. Dazu müssen sie alle technologischen und fachlichen Kompetenzen die dazu nötig sind im Team vereinigen. Dieses Team erzeugt, inspiziert und adaptiert dazu laufend drei Artefakte: den Produkt Backlog (Anforderungskatalog), den Sprint Backlog (die Anforderungen des laufenden Entwicklungszyklus) und das potentiell auslieferbare Produkt Inkrement als Ergebnis jeden Sprints. Die Auslieferbarkeit der Produkt Inkremente wird vom Team gegen die Definition of Done (Akzeptanz und Abnahmekriterien) des Projektes im Rahmen der Sprint Review Sitzungen geprüft, bevorzugt im Beisein der Kunden und Anwender. Das Review markiert den Abschluss eines Sprints, zusammen mit der nahtlos folgenden Retrospektive Sitzung, in der das Team plant wie es sich noch weiter verbessern kann. Der neue Sprint wird schließlich auch nahtlos durch die Sprint Planungssitzung eingeläutet. In dieser Sitzung stellt der PO die am höchsten priorisierten Anforderungen vor und das Entwicklungsteam schätzt erfahrungsbasiert deren Aufwand, bevor es entscheidet wie viele es in den Sprint Backlog zieht und dann die Details der Umsetzung bespricht. Nur solche Anforderungen können dabei berücksichtigt werden, die vom Team im Vorfeld klein genug geteilt und genau genug spezifiziert wurden. In der Sprint Planung formuliert das Team auch das Sprint Ziel an dem sich das nächste Inkrement messen muss. Sobald der Sprint angefangen hat trifft sich das Team einmal täglich immer zur gleichen Zeit zu einer kurzen Sitzung, um die Zusammenarbeit zu koordinieren und den Fortschritt auf das Sprint Ziel zu überprüfen. Dieses sogenannte Daily Scrum wird meistens im Stehen abgehalten um Aufmerksamkeit zu fördern. Zusammengefasst sprechen wir von den vier
Scrum Ereignissen die zeitlich reglementiert sind durch eine feste Timebox (maximale Länge), sowie einem festen wiederkehrenden Abstand haben. In einem Projekt mit zweiwöchigen Sprints dauern Review und Retrospektive üblicherweise 1-2 Stunden und die Planung 2-4 Stunden. Unabhängig von der Sprint Länge ist die Timebox des Daily immer 15 Minuten.

Scrum sieht zusätzlich zu den Entwicklern und dem PO noch den Scrum Master vor, der seinem Team bei der korrekten Anwendung von Scrum behilflich sein und sie zu einer selbstorganisierten Arbeitsweise hinführen soll. Der Scrum Master soll auch dabei helfen agile Prinzipien und Kultur in der übergeordneten Gesamtorganisation zu fördern. Das heißt die Aufgaben des klassischen Projekt Managers werden in Scrum Projekten nicht vom Scrum Master, sondern vom PO und den Entwicklern übernommen.

Abbildungen 7 und 8 zeigen schematisch das Rahmenwerk Scrum und dessen Team Komposition.

Die meisten Scrum Teams ergänzen innerhalb von Scrum auch die im vorherigen Kapitel beschriebenen Kanban Methoden, da sie eine noch feinere Optimierung des autonomen Arbeitens ermöglichen. Die Kanban Visualisierungstechnik fördert die Scrum Prinzipien der Transparenz, Überprüfung und Anpassung wesentlich. Außerdem gilt das Pull-Prinzip gleichermaßen in Scrum, da es wie Kanban auf selbstorganisiertes Arbeiten setzt.

Seit 2010 wird unter der Führung von Schwaber und Sutherland der Scrum Guide als weltweit gültiger Leitfaden für Scrum veröffentlicht und regelmäßig aktualisiert. Er steht übersetzt in etlichen Landessprachen zur Verfügung.

Diese einheitliche und klare Beschreibung von Scrum, hat dessen Popularität stark gefördert und es zum weltweit meist angewendeten agilen Verfahren gemacht.

Seit 2018 gibt es nun von Scrum.org und Schwaber auch einen Guide zur Anwendung von Kanban innerhalb von Scrum. Was Kanban ist und wie es verwendet wird erkläre ich im nächsten Abschnitt.

Abbildung 9

 

Abbildung 10

Kanban

Ursprünglich wurde Kanban als Teil des Toyota Production System (TPS), auch Lean Production System genannt, in der Automobilproduktion eingesetzt. Das Wort ist Japanischen Ursprungs und bezeichnet eine Signalkarte zur Materialbestellung. Ab 2009 wurde es unter anderem durch Veröffentlichung von D.J. Anderson und Henrik Kniberg für den Einsatz in der Softwareentwicklung populär gemacht.

Kanban besteht aus Strategien zur Flussoptimierung von Wert an Stakeholder durch den Einsatz eines visuellen Pull Systems, dem Kanban Board, dass die angefangene Arbeit limitiert. Dieses Limit ist bekannt unter dem Englischen Akronym WIP Limit (Work in progress limit). Pull bedeutet hierbei das Aufgaben nicht mehr zugewiesen werden, sondern ein Entwickler aus dem Team den Zeitpunkt bestimmt wann er oder sie damit beginnt. Dabei bestimmt das Team auch wieviel Aufgaben gleichzeitig begonnen werden dürfen.

Das zentrale Element von Kanban ist also das Prinzip des Flusses von wertvollen Liefereinheiten durch alle Produktentwicklungsstufen. Durch Verbesserung von Effizienz, Effektivität und Vorhersagbarkeit des Entwicklungsprozesses soll dieser Fluss kontinuierlich verbessert werden.

Dadurch das Teams darauf achten nur wenige Aufgaben gleichzeitig in Arbeit zu ziehen und möglichst schnell die angefangenen Aufgaben zu beenden, können sie ihre durchschnittliche Cycle Time messen und bestimmen. Cycle Time ist die Zeit die eine Funktionalität vom Beginn der Entwicklung bis zur Bereitstellung beim Kunden benötigt. Damit kann ein Team nach einer Weile relativ präzise Vorhersagen treffen, wie lange es dauern wird bis Funktionalität X zur Verfügung steht, gemessen ab dem Zeitpunkt an dem die zugehörige Anforderung vom Product Owner (Kundenvertreter) an die Spitze des Backlogs (Liste der Anforderungen) geschoben wurde. Vorausgesetzt wird hierbei, dass es dem Product Owner gelingt die Anforderungen in ähnlich große Blöcke zu schneiden.

Andere Messgrößen in Kanban sind das Alter von Aufgaben (Work Item Age) und wieviel Aufgaben pro Zeiteinheit fertig werden (Throughput). In der Praxis lässt sich Work Item Age gut visualisieren in dem das Team einen Punkt pro Tag auf die Kanban-Karte am Board malt, solange die zugehörige Aufgabe in Bearbeitung ist. Wenn es dann noch das Datum ab wann eine Aufgabe begonnen wurde auf die Karte schreibt, kann das Team einfach ablesen wie hoch der Throughput ist.

Folgender Comic „One Day in Kanban Land“ (Abbildung 3 -6) von Henrik Kniberg bringt das Kanban Prinzip auf den Punkt, bekanntlich sagt ein Bild mehr als tausend Worte:

One Day in Kanban Land Comic:

Abbildung 1                     Abbildung 2

Abbildung 3                     Abbildung 4

Teil 3 DevOps erklärt

Teil 1: Scrum, Kanban und DevOps in der Praxis

Quellen Angabe:

Anderson, D. J.: Kanban -Successful Evolutionary Change for your Technology Business (2010)

Henrik Kniberg – One Day in Kanban Land (2009)

Henrik Kniberg – Produkt Owner in a nutshell

Scrum Guide 2017 Deutsch PDF

Kanban Guide for Scrum Teams 2018

Das Scrum Team – Grafik von Daniel Foo – Daniel Foo

Scrum.org Scrum Grafik

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

Agiles Prinzip Nummer Drei und Scrum + DevOps

das beinhaltet, schafft den Rahmen der es dir erlaubt funktionierende regelmäßig innerhalb weniger Wochen den Endkunden zur Verfügung zu stellen. Das heißt und gehen einher mit Prinzip Drei hinter

DOI – Scrum.org Partnership