Wie schnell bringt mein Unternehmen eine index.html Seite in die Produktion? (The Zero Dev Walk)

DevOps und Cross Functional Teams sind in aller Munde und wer es noch nicht kennt, dem sei das Buch “The Phoenix Project” von Gene Kim, Kevin Behr und George Spafford sehr empfohlen. Wie aber bekommt man aber nun ganz konkret heraus was zu tun ist? Was sind die konkreten Schritte, die gemacht werden müssen, damit eine DevOps Kultur entsteht?

Bestandsaufnahme aus Sicht der Entwicklung

Man startet mit einer Analyse was derzeit innerhalb der eigenen Organisation möglich ist

Meine Empfehlung ist, es am konkreten Beispiel zu machen und den eigentlichen Softwareentwicklungsaufwand als konstanten Wert in die Aufwands- und Durchlaufzeit-Gleichung zu nehmen. Idealerweise setzt man den Wert auf Null. Das geht nun nicht wirklich vollständig, da es ja um die Entwicklung einer Software geht, aber man kann es fast schaffen. Der entscheidende Teil von DevOps oder Cross Functional Teams ist das Zusammenspiel aller beteiligten Personen. Wenn nun die eigentliche Programmierung nicht signifikant – weil nahe 0 – ist, dann kann man gut beobachten wie das Zusammenspiel aller anderen organisatorisch notwendigen “Mitspieler” ist.

Ein Beispiel

Nehmen wir an, wir haben eine Produktidee und taufen sie auf “GreenTrain”. Es ist ein innovatives Auskunftssystem für Eisenbahnverbindungen.

Und hier startet man schon die Entwicklung und versucht das System so schnell wie möglich in die Produktion zu bekommen.

Keine Architektur, kein Design, keine Use Cases, keine Stories, nichts… nur die Idee und ein Entwickler. Das reicht.

Ein Auskunftssystem muss einfach zu erreichen sein und möglichst von vielen Geräten unterstützt werden. Eine Webseite ist also keine schlechte Wahl.

Nun also die Webseite, eine minimale index.html Datei:Die Seite ist fertig.

Die erste Iteration im Entwicklungsprozess ist abgeschlossen. Die Datei wird in eine Source Code Control System – Git ist sicher keine schlechte Wahl – eingecheckt.

Und nun ab damit in die Produktion.

Interessanterweise wird es hier für manche Unternehmen schwierig. Über die Jahre wurde eine eigene technische und organisatorische Infrastruktur aufgebaut um die Softwareentwicklung effizient und effektiv zu machen:

• Operating-Team,
• Configuration und Release Management
• Sicherheitsrichtlinien
• Qualitätssicherung-Team
• Advisory Boards
• Architektur-Teams
• …

Ein kleiner Webshop wird diese Aufgabe in wenigen Minuten erledigt haben. Warum: die Webseite ist so klein, dass nichts davon wirklich benötigt wird, bzw – und das ist der Schlüssel – das Projektteam selber alle Arbeiten vornehmen kann.

Zurück zu den Unternehmen die mehr als einen Tag benötigen. Die für das Projekt verantwortliche Person der Produkt Owner – inzwischen ist sicher eine solche Person benannt worden – wird damit beauftragt, unser Projekt “GreenTrain” produktiv zu setzen.

Unser Product Owner wird eventuell bemerken, dass er viele, zum Teil recht umfangreiche, Dokumente ausfüllen muss. Warum sind diese so gross? Nun, da sie für alle Projekte im Unternehmen Pflicht sind, müssen sie auch alle möglichen Anwendungsfälle abdecken. Selbst wenn das ausfüllen nur wenige Minuten dauert, so dauert es doch meist eine Weile, bis man ein OK zurückbekommt. Im schlimmsten Fall trifft sich z.B. das Architekturboard nur einmal im Monat um die Projekte zu besprechen und der letzte Termin war gestern.

Es müssen Meetings organisiert werden und ein freier Termin für alle notwendigen Teilnehmer ist erst in zwei Wochen.

Diese Wartezeiten und die unterschiedlichen Organisationseinheiten muss sich der Product Owner notieren, um später Maßnahmen einleiten zu können.

Inzwischen haben auch das Marketing und die Fachabteilung mit den entsprechenden Prozessverantwortlichen bemerkt, das da etwas Neues entsteht und fordern die Einhaltung des UX Konzeptes und die Erstellung einer Spezifikation. Wieder müssen die Leute “ins Boot” oder “abgeholt” werden.

Der Entwickler hat inzwischen die Version 2 unserer Applikation gebaut:

Die Versionen gehen nacheinander, so schnell wie möglich in die Produktion. Wie nun die folgenden Versionen aussehen, kann man sich leicht vorstellen – hier die Version 3:

http://www.nautsch.net/greentrain/

Nun werden einige Leser denken: “Ja aber unsere Applikationen sind ja viel grösser, wir müssen noch die Daten in einer Datenbank speichern und Umsysteme müssen wir auch einbinden.”

Auch diese Dinge lassen sich in sehr elementare Schritte zerlegen. Grösse oder Komplexität hindern uns nicht in kleinen Schritten, schnell auszuliefern. Wie gross die Funktionen in den einzelnen Iterationen sind, legen wir Menschen fest. Dazu eventuell mal mehr in einem weiteren Artikel.

Massnahmen

Hat man nun erkannt, wo die längsten Wartezeiten liegen, versucht man die Situation Schritt für Schritt zu verbessern.

Verantwortung ins Team

Eine Variante besteht darin ein Mitglied aus den entsprechenden Bereichen in das Projektteam zu holen und für den Erfolg des Projektes mitverantwortlich machen. Ziel ist ein Umdenken von Handlungsanweisungen zu übergeordneten Zielen, die dem Projektteam ermöglichen selber alle Maßnahmen durchzuführen. Nicht die Optimierung jeder Organisationseinheit, sondern die einfache und schnelle Auslieferung des Produktes stehen im Fokus.

Über kurz oder lang wird dann erkennbar, dass strukturelle Veränderungen notwendig sind und man sich von den funktionalen Organisations-Silo trennen muss.

Von Push zu Pull

Eine weitere Massnahme besteht darin alle Maßnahmen optional zu machen. Die Teilnahme an Sitzungen nicht mehr obligatorisch zu machen, ist sicher ein einfacher Schritt – aber auch andere Vorgaben (z.B. welche Infrastruktur, wie Security und was für eine Architektur) sind optional und werden so zu Empfehlungen. Das Team muss selber wählen können, was es der Reihe nach macht, um die Wartezeiten optimieren zu können oder gar zu vermeiden. Die “anderen” Teams beraten und unterstützen nur noch, sind aber nicht mehr weisungsbefugt.

Dies führt dazu, dass das Team sich zum richtigen Zeitpunkt die richtigen Hilfen holen muss. Hält man den Funktionsumfang klein, so bleibt auch das Risiko klein.

Erfahrungen

Folgende Dinge sind unter anderem passiert, als wir dies bei einem Kunden von mir durchgeführt haben:

Zu viele Features im Produkt

Das Produkt wurde zu gross. Wir konnten den Entwicklungsanteil nicht auf nahe Null herunterschrauben. Dies lies sich auf folgende Gründe zurückführen:

• Entwickler zogen Features an, da sie schon nach ein paar Minuten fertig waren und die Situation nicht zu programmieren ungewohnt war – nichts tun ist manchmal besser (wer sich da einlesen will, dem sei “The Goal” von Eliyahu M. Goldratt empfohlen).
• Es wurde ein bestehendes Produkt verwendet, um dort weiter zu kommen. Die Abhängigkeiten innerhalb des Produktes führten wieder zu Problemen und Wartezeiten innerhalb der Entwicklung.

 

Bereiche arbeiten besser zusammen

Auch wenn wir noch eine funktional gegliederte Organisation haben, so arbeiten die Bereiche besser zusammen. Beim “Daily Stand-Up-Meeting” sind Leute aus fast allen betroffenen Bereichen versammelt und dies führt zu kürzeren Reaktionszeiten.

Lokale Optimierungen

Es wurde zu wenig an den Wartezeiten gearbeitet. Eine Entscheidung fiel noch zu Gunsten des Bereiches aus, in dessen Hoheit das Ergebnis der Entscheidung lag. Es wurde noch nicht die Perspektive des Endkunden eingenommen.

Die Organisation muss lernen

Es geht bei weitem nicht alles so schnell, wie man es sich wünscht. Wenn bisher sehr viele Leute bereichsübergreifend zusammengearbeitet haben, so muss man diesen Personen erklären, warum man es jetzt anders macht. Es ist notwendig diese Erklärungen zu machen und dies geht oft nur auf den alten Pfaden.

Fazit

Auch wenn nicht alles auf Anhieb klappen wird, ist dies eine einfache Art und Weise ein Umdenken zu initiieren. Insbesondere wenn es gelingt den Fokus auf die schnelle Auslieferung einer so einfachen Sache wie einer index.html-Seite zu bringen, können sehr viele Zäune abgerissen werden. Schlussendlich muss man aber strukturelle Änderungen in der Organisation durchführen, damit alle am Produkt und nicht mehr im bzw für den Bereich arbeiten.

Fragen, Anregungen und Feedback ist sehr willkommen.

Weiterführendes Material

• Walking Skeleton von Alistair Cockburn – weil diese index.html Seite das “dünnste” Skelet darstellt
• Gesetz von Conway (Conway’s Law) – warum Software die Kommunikation innerhalb der Organisation wiederspiegelt in der sie gebaut wird
• Minimum viable product – zur Bewertung der Zusammenhänge bei der Auslieferung reicht eine index.html Seite da die fachliche Funktionalität in den Hintergrund rückt