Share ZU:
10 October 2017 @ Andreas Kreß

Als der System Product Owner mit dem Daily Build den Stairway to Heaven hinaufstieg

This entry is part 4 of 4 in the series Agile Organisationsentwicklung

Giorgio Vasari II - Jacob's Dream - Walters 372508

Dass neue Technologien die Arbeitswelt verändern, manchmal schnell, manchmal langsam und unmerklich, das ist heutzutage offensichtlich. Dieser Wandel vollzieht sich auch in der Arbeitswelt der Erfinder und Entwickler. Es fängt damit an, dass wir am Entwicklungsplatz Neuerungen in den Entwicklungsgegenstand einbringen können. Dieser wird dann virtuell gebaut und wir können sofort testen. Klingt jetzt nicht atemberaubend, nur war das früher mit viel mehr Wartezeit verbunden. Für den Informatiker und Softwaretechniker ist der schnelle Change-Build Zyklus schon lange geübte Praxis. Kommt Hardware ins Spiel, sind wir heute auch auf dem besten Weg diese Praxis zu übernehmen. Das wird übrigens auch Thema auf der AGILE SYSTEMS KONFERENZ – ASK nächste Woche am 17. und 18. Oktober sein.

Das Erstellen großer Systeme im Team und Teamverbund ist in der Softwareentwicklung einfachste Rocket-Science:  Wie ein Raumfahrt-System wird alles aus Modulen und Komponenten aufgebaut, das Bibliotheksprinzip wird angewendet um Erzeugnisse von Teams anderen Teams nutzbar zu machen. Datentechnische Ablage und Verteilmechanismen wie z.B. Github sind dabei eine Technologie, deren „Game Change“ Aspekt nicht unbedingt ins Auge fällt.  Im Verbund mit Fast-Prototyping Technologien (besser wohl Fast-Production) hat man, vorausgesetzt man weiß es zu nutzen, die Grundlage für eine schnelle marktadaptive und marktbestimmende Produktgenerierung.

Voyager 2 in Launch Vehicle PIA21727

 

So kann man, im Unterschied zu einer einmaligen Mondmission, heute täglich eine etwas bessere Rakete und Raumkapsel bauen und losschicken. Ähnlich wie das mit der Planeten Sonde Voyager II passiert ist, könnten wir in kurzen Intervallen immer wieder Software-Updates einbringen um Verbesserungen oder neue Features in den ausgesendeten Systemen zu ermöglichen. Ein kontinuierlicher Austausch von HW Elementen wäre für erreichbare Systeme so auch denkbar.

Die schwedischen Wissenschaftler Olsson, Alahyari und Bosch nennen das Continuous Deployment. In ihrer im Jahr 2012 veröffentlichten Studie  „Climbing the Stairway to Heaven“ beschreiben sie organisatorische Ausbaustufen und deren Liefer-Fähigkeit. Diese Ausbaustufen kann man auch als eine Arbeitskultur verstehen, die entsteht, wenn verschiedene Technologien Einzug halten.

Die Wasserfall-Kultur

In der Studie wird Stufe A mit langsamen Entwicklungszyklen und sequentiellen Interaktionen zwischen Produkt Marketing, Produkt Entwicklung, System Test und Kunden beschrieben. Projektteams werden in sehr großen Abteilungen gehalten und sind in viele, entwicklungs-V-Modell-konforme Spezialisten unterteilt.

Wir werden hier wohl eine Filesystem-Technokultur entdecken. Jede Abteilung und jede Phase hat ihren Ordner und eine Dokumentensteuerung erwartet nach Q-Plan zum geplanten Zeitpunkt ein Ergebnisdokument.

Im Kern agil, aber…

Stufe B als „Agile R&D Organization“ bezeichnet, verwendet agile Praktiken. Diese werden aber umrandet von konventionellen Ansätzen des Produkt Managements und der System Verifikation, also einem traditionellen, organisatorisch isolierten Systemtest. Eine kurze Rückkopplung zum Kunden ist in dieser Stufe nicht notwendigerweise sichtbar.

Typischerweise wird jetzt eine Backlog-Technologie eingesetzt und ein Tracker der „Jira“ Klasse zu finden sein. Schnittstellen zu PDM- Systemen und Ablage-Synchronisation bestimmen die Diskussionsrunden der übergreifenden Gremien.

Die Booster Stufe: „Continuous Integration“

Continuous Integration ist die Stufe C. Eine Entwicklungsorganisation mit dieser Fähigkeit, integriert sehr häufig neue Arbeitsergebnisse in neue Integrationsstände. Sie ist gekennzeichnet von einem Automatisierungsgrad der beim Bau und Test von Produkten nur noch wenig manuelle Tätigkeiten benötigt. Eine System-Validation arbeitet nun auch nach agilen Prinzipien.

In der Technologiewelt sind jetzt Werkzeuge wie Docker, Ant, Jenkins im Einsatz. Es wird mit MockUps und weit entwickelten Werkzeugen für kontrollierte Änderungspfade und Zusammenführungen gearbeitet.

Der kontinuierliche Wertstrom

Stufe D, das „Continuous Deployment“ schließt den Kunden kurz. Jetzt kann sehr effektiv unnütze Arbeit, die nicht den Kundensinn trifft, vermieden werden. Bedingung ist, dass Nutzungsverhalten und Kundenfeedback ständig rückgeführt werden. Die Forscher sprechen jetzt von einem „rapid, agile cycle of product development“.

Die technologische Seite ist hier weniger durch neue Techniken, als vielmehr von einer durchgehenden Infrastruktur und einer breiten, alle Organisationsteile einbeziehenden Nutzung gekennzeichnet. Auf der Produktseite ist die technologische Fähigkeit vorhanden, diese schnell und ohne Nutzungsunterbrechung verändern zu können.

Almost Heaven

Tatsächlich sehen die Forscher noch eine weitere Stufe vor. „E“ wird als „R&D as an experiment system“ bezeichnet. Diese Stufe macht sozusagen den Paradigmenwechsel komplett. Ein ständiger Austausch von Kundenfeedback und neuen Auslieferungen, immer mit der Sicht verbunden etwas über den Nutzer und seine Bedürfnisse zu erfahren und diese mit einer neuen Auslieferung besser befriedigen zu können.

Die verfügbaren Techniken, die diese Stufe evozieren, sind in der IT mit dem Begriff DevOps verbunden. In anderen Domänen könnte man es etwas trocken betriebsnahe Entwicklung nennen. Hinzu kommen aber noch Analyse-Technologien, die Nutzungsverhalten transparent und schnell verfügbar machen. So wird ein Schuh daraus und ein dynamisches Produkt-Markt-System entsteht.

Aber Vorsicht! Manche Wasserfall-Kultur gibt sich agil und auf den ersten Blick könnte man es glauben. Tatsächlich werden wir aber dort nur eine ad-hoc Bug Fix Kultur antreffen, die nur sehr eingeschränkt um die wirklichen Kunden und Marktbedürfnisse weiß.

Wer also nicht möchte, dass ein „Cargo Cult“ entsteht, ist gut beraten die Technologieseite immer mitzubetrachten.

Schon viele haben sich auf den „Stairway to Heaven“ gemacht. Dieser ist aber leider keine Rolltreppe. Viel Beschäftigung mit den oben angeklungenen Themen ist notwendig!

Die ASK ist eine Möglichkeit dies zwei Tage intensiv zu tun. Ich würde mich freuen, wenn wir uns beim World Café am Mittwoch, den 18. Oktober 2017 wiedersehen.

Series Navigation<< Holokratie als Organisationsform

Andreas Kreß

Kontaktieren Sie Andreas Kreß

The Software Engineer Andreas Kreß has served in roles like start-up product owner and requirements team manager at critical customer projects in the tech industries. He is the inventor of a widely used SCADA tool and helped set up methods and engineering tool environments from Y2K IT projects over large federal fiscal software standardization programs to automotive autonomous driving components development. He is a connoisseur of many intimate secrets of the art of developing systems. His focus is on the more far-reaching methods and tools in regulated and security-oriented systems engineering.