Brauchen wir DevOps? 1/2

DevOps ist ein spannendes Verfahren innerhalb der Entwicklung von Software im laufenden Betrieb. Es kommt von Agile Teams, die ihre Software laufend ausliefern wollen. Dies bedeutet, dass ein Entwickler eine Software erstellt oder wartet und sie dann ausrollt, sobald sie in einer zentralen Software-Repository abgelegt wird – ohne jegliche Einwirkung von anderem IT-Personal.
Die Endbenutzer der Software können sie also sofort benutzen. Dieses Phänomen nennt sich laufende Auslieferung oder continuous delivery.
Entwicklungsteams geben auch an, dass sie Kennzahlen über das Verhalten der Benutzer ihrer Software benötigen. Solche Teams sind Lean-Startup-Teams innerhalb größerer Organisationen oder kleine, technologiegetriebene Firmen. Sie setzen eine wilde Idee um, sammeln Daten über deren Erfolg und verbessern sie dann Schritt für Schritt.
Brauchen Sie eine sehr kurze Time-to-Market und eine höchst innovative IT? Dann ist das Geschäftspotential so hoch, dass Sie vermutlich nicht ohne DevOps auskommen können. Es fügt einen kompletten „Inspect & Adapt“, sprich „Prüf- und Anpassungszyklus“ zur Lieferkette hinzu. Prüfen und Anpassen ist das Kernprinzip, das höchst innovative Teams vorantreibt.
Laufende Auslieferung und das Konzept solcher Lean-Entwicklung werden durch DevOps abgedeckt. Die DevOps-Community hat das Verfahren noch nicht einheitlich definiert, Sie werden deshalb viele Definitionen finden. Lesen Sie dazu meinen zweiten Blogeintrag; hier schlage ich vor, DevOps basierend auf seinen Geschäftswert für einen spezifischen Kontext zu definieren.
Womöglich haben Sie gute Gründe, die Anwendung von DevOps in Erwägung zu ziehen. Für Sie habe ich die folgende Checkliste erstellt, in der Sie erkennen können, ob DevOps in seiner Reinform das Passende für Ihr Unternehmen ist.

Brauchen wir DevOps? 2/2

DevOps ist nicht das, was Ihre Firma braucht, es sei denn Sie betreiben Lean Startup, eine Social-Website, ein Musik-Streaming-Dienst oder ähnliches. Was Sie stattdessen brauchen, sind die Ergebnisse, die damit erzielt werden können.
Begrenzen wir das Thema auf rund 80% der Fälle, denen ich in meiner Arbeit als Agile Coach begegne.
Zum Teil verdankt DevOps seinen Erfolg dem Bestseller The Phoenix Project. Das Buch beschreibt die Art von IT-Katastrophe, an der viele „normale“ Firmen leiden. Es spricht Leser an, die den Schmerz schlechter Qualität in der IT nachempfinden können. Im Buch rettet DevOps eine Firma vor der Pleite. Ein Happy End also.
Wenn Sie keine praktische Erfahrung mit Agile und Lean in der IT haben, dann kann DevOps schon verwirrend sein. Es herrschen viele verschiedene Ansichten über DevOps, die, je nach Kontext und wen man fragt, variieren. Sie werden also keine einheitliche Definition dafür finden. Und wenn Sie der Meinung sind, doch eine gefunden zu haben, wird sie von den DevOps-Leuten bestritten, da die Definition von DevOps noch nicht ausgereift ist.
Es kann also schwierig sein anzukündigen, dass die IT in Ihrer Organisation DevOps „machen“ wird. Wie kann das implementiert werden, wenn Ihre Mitarbeiter sich nicht auf ein gemeinsames Verständnis des Konzeptes einigen können?
Umgehen wir das Problem indem wir eine andere Frage stellen: „Was ist das gewünschte Ergebnis von DevOps?“ oder: „Was ist der Geschäftswert von DevOps?“
Eine Firma, die mit DevOps erfolgreich arbeitet, kann von sich behaupten: „Wir können jederzeit ein fehlerfreies Rollout jeder Software, die wir – oder unsere Kunden – brauchen, starten“.
Dies zu bewerkstelligen verlangt viel Automation, Feedback und Testen. Im Buch ist es dargestellt als „first and second Way“.
Zur obigen Beschreibung des Geschäftswertes könnte man hinzufügen: „Das Ziel erreichen und in Zukunft beibehalten“, das könnte „the third Way“ sein.
Es ist mir schon bewusst, dass die Autoren dieses hervorragenden Buches womöglich beleidigt sein könnten. Meine Beschreibung von DevOps ist eine fürchterliche Übervereinfachung des Umgangs mit IT-Problemen, die über Jahre gewachsen sind und deren Lösung sich äußerst schwierig gestaltet. Im Grunde möchte ich sagen: DevOps handelt vom „Machen“.
Vor allem für bestehende Organisationen aber ist die Durchführung von DevOps keineswegs schnell und einfach durchzusetzen. Der Grund dafür ist die technische Altlast innerhalb der IT, woran jede Organisation leidet. Eine fiktive Geschichte lässt sich leichter schreiben, als sich Taten in der realen Welt verwirklichen lassen. Lesen Sie dazu meinen ersten Beitrag unter demselben Titel.
Mein Vorschlag für ein Unternehmen mit einem durchschnittlichen Technologiestand ist: Konzentrieren Sie sich auf den Geschäftswert. So bleibt alles leicht verständlich.
Aufgrund meiner Überlegungen rate ich davon ab, eine einheitliche Definition von DevOps anzustreben. Stattdessen möchten Sie vielleicht eine einzige Userstory erarbeiten. Nehmen wir als Beispiel den großen Chemiekonzern, für den ich gerade tätig bin. Eine solche Story könnte lauten: „Als ‚Business‘ möchte ich eine neue Version eines Softwareproduktes auswählen und ausrollen, ohne dass IT-Mitarbeiter per Hand eingreifen müssen“.
DevOps folgt dann ganz natürlich, sobald diese einfache Userstory aufgestellt wird. Wenn sie einmal besteht, dann wird jeder in Ihrer Firma wissen, was DevOps bedeutet.

IT-Strategien in Zeiten der Agilität

Agilität ist hipp, IT-Strategieentwicklung dagegen irgendwie altmodisch und unbeweglich.
Erst jetzt, wo es nicht nur die Early Adapter sind, die sich mit dem Thema Agilisierung beschäftigen,
merken wir, dass uns oft ein strategischer Rahmen fehlt, wenn wir nur mit der These starten:
„Wir müssen beweglicher werden.“ Eine gezielt entwickelte IT-Strategie gibt uns wichtige und wertvolle
Hinweise darauf, wo und in welchen Bereichen agile Prozesse einen wirklichen Nutzen erzeugen und wo nicht.

Zum Artikel

Über Vertrauen und Kontrolle

Editorial von Dr. Thorsten Janning in der Ausgabe Juli/August 2016 des OBJEKTspektrum.
In der internationalen politischen Landschaft gibt es in der jüngeren Zeit das Phänomen, dass viele Leute sich „den starken
Mann“ an die Führung wünschen. Viele Menschen wünschen sich keine differenzierten Diskurse in einer durch viele
Kulturen, Religionen und Anschauungen heterogenen Welt, sondern klare Ansagen, eine harte Hand und scheinbar überschaubare
nationale Lösungen in einer internationalisierten und wegen ihrer Komplexität eigentlich nicht mehr durch einen
Einzelnen überschaubaren Welt. Am Horizont ist ein neuer Autoritarismus erschienen.

Interview mit Dr. Thorsten Janning auf der Manage Agile 2015

Agilität. Wie weit sind wir heute?
Ist es ein „Hip-Thema“, dass wieder verschwindet?

Hier geht’s zum Interview!

Der Scrum Master

Die Definition zum Scrum Master ist im Scrum Guide der Scrum.org mit ein paar wenigen Zeilen beschrieben: „Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Er tut dies, indem er dafür sorgt, dass das Scrum Team die Theorie, Praktiken und Regeln von Scrum einhält. Der Scrum Master ist ein Servant Leader für das Scrum Team. Der Scrum Master hilft denjenigen, die kein Teil des Scrum Teams sind, zu verstehen, welche ihrer Interaktionen mit dem Team sich hilfreich auswirken und welche nicht. Der Scrum Master hilft dabei die Zusammenarbeit so zu optimieren, dass der durch das Scrum Team generierte Wert maximiert wird.“ (scrum.org)

Doch was heißt das für den Alltag eines Scrum Masters?
Vom Moderator, Regel-Einhalter bis hin zum Coach muss ein Scrum Master ein vielfältiges Aufgabenspektrum erfüllen. Am einfachsten gelingt hierbei noch der Regel-Einhalter. Mit dem Scrum Guide sind die Regeln festgelegt und können einfach angewendet werden. Schwieriger wird es schon beim Moderator. Meetings müssen moderiert werden und Retrospektiven so vorbereitet werden, dass ein gutes Ergebnis erzielt wird. Hierfür sind Techniken sowie Menschenkenntnis gefragt, die dem Scrum Master helfen, ein gutes Vertrauensverhältnis aufzubauen.
Am anspruchsvollsten wird es für den Scrum Master als Coach. Das Team muss so unterstützt werden, dass Lösungen erarbeitet, aber auch Konflikte gelöst werden können.

Was muss ein Scrum Master für Sie noch leisten können?

Führungskraft – Quo vadis?

Das Zeitalter der agilen Methoden bricht an und man bekommt das Gefühl, dass sich alles radikal verändert. Auch das Thema Führung wird intensiv diskutiert. Googelt man das Thema dann stößt man schnell auf Begriffe wie z.B. Leadership, Management 3.0, Führung, Beispiele für Organisationsformen und noch vieles mehr.

Selbstorganisation durch Freiräume

Agile Praktiken fordern von Teams und Mitarbeitern selbstorganisiertes Arbeiten. Viele Vorgesetze fordern diese Selbständigkeit zwar auch von ihren Mitarbeitern, im Gegenzug wollen sie aber bei Entscheidungen gefragt werden und ständiges Feedback erhalten.

Wie soll in diesem Umfeld mit ständiger Kontrolle selbständiges Arbeiten möglich sein?

Wie man einen Tanker beschleunigt

Die Geschwindigkeit der Bearbeitung von Anforderungen an meine Software wird zunehmend zum kritischen Erfolgsfaktor für Entwicklungsorganisationen. Die Erfahrung zeigt aber, dass die meiste Zeit nicht bei den Entwicklungsteams selbst, sondern auf dem Weg von der Idee bis zur Aufnahme in das Sprint Backlog verloren geht. In dem Vortrag werden erfolgreiche praktische Veränderungen real existierender Organisationen auf der Basis von Prinzipien des Product Development Flow von Don Reinertsen und in der Anwendung skalierter agiler Praktiken vorgestellt.

OOP 2015 Webcast KEGON AG from KEGON AG on Vimeo.

Kommunikation fördert Agilität

Kommunikation ist nicht erst seit dem Agilen Manifest ein Thema in Teams und Organisationen,
auch davor war es der Grundstein einer guten Zusammenarbeit. Dennoch steht die Kommunikation heute stärker im Focus denn je.