Entwickler zu Fluglotsen. Ein Plädoyer für autonome Entscheidungen

Meetings nerven. Kommen wir zu einer Entscheidung, handelt es sich oft um einen faulen Kompromiss. Im besten Fall ist es der kleinste gemeinsame Nenner, ein dünner Konsens von zweifelhafter Verbindlichkeit, oft getroffen, um das gesteckte Zeitfenster nicht zu überziehen oder einen Punkt hinter eine leidige Diskussion zu setzen. Die erhoffte Reduktion der Optionen endet unter dem Druck der Zeit und der Meinungsvielfalt leicht in einer hässlichen Lösung: der Alternativlosigkeit als Letztbegründung. Oder in einem Blumenstrauß der Widersprüchlichkeiten mit Flucht in die Vertagung. Bitter für die, die eine schnelle Entscheidung dringend brauchen.

Problematisch wird es, wenn Meetings Gremien-artig oder hierarchisch gegliedert sind, wenn Fachabteilungs- oder Head-of-Runden, Gilden oder COP gar die Instanz sind, in denen Entscheidungen getroffen und nach „unten“ kommuniziert werden. Jede unsichtbare Entscheidung hinter verschlossenen Türen wirkt der Bildung autonomer Entscheidungen entgegen, weil sie den Prozess der Entscheidungsfindung verbirgt, den Pool an Wissen willkürlich reduziert und um die das Resultat flankierenden Informationen beschneidet. Eine Entscheidung wird zum Marathon durch Instanzen, die jeweils eigene Welten abbilden, weit entfernt davon, effizient zu sein.

Eine gesicherte Entscheidung, jetzt!

Entscheidungen müssen getroffen werden,  wenn der Kontext akut eine Entscheidung fordert. Dann brauchen wir sie schnell, mit den richtigen Leuten, mit dem allen Beteiligten maximal verfügbaren Know How; wir brauchen sie am richtigen Ort. Jetzt wollen, oft können wir nicht warten. Wie aber kann ich das bewerkstelligen, wen muss ich ins Boot holen, wann ist der passende Slot? Was muss ich berücksichtigen, um auch den Kollegen, die sich in 3 Jahren um die Software kümmern, gerecht zu werden? Noch schlimmer: welche Anforderungen kenne ich nicht einmal, wie viele Betroffene habe ich gar nicht im Blick?
Zusätzlich wollen wir unseren „Need for Closure“ bedient sehen. Visionen und Ziele sollen uns Orientierung und Richtung geben,  Richtlinien sollen dem Handeln Leitplanken setzen, Anforderungen wollen ausreichend verstanden sein. Muss ich wirklich das große Rad drehen, um eine Entscheidung zu treffen? Kann ich das nicht selbst entscheiden?

Gute Prognosen mit Schadensbegrenzung in einer komplexen welt

Viele dieser Probleme hätte ich nicht, wäre ich in einer einfachen und überschaubaren Welt unterwegs, in der ich immer Orientierung hätte. Auch in komplizierten Welten könnte ich noch alle wichtigen Aspekte recherchieren und klären. In einer komplexen Welt brauche ich hingegen ein hinreichend gutes Verständnis des aktuellen Kontextes. Es sollte zumindest so gut sein, dass es wahrscheinlich ist, dass das von mir gewünschte Resultat eintritt. Sogar so gut, dass die Seiteneffekte gegenüber anderen Abteilungen und Kollegen nicht in mehr Schaden bei Ihnen als Nutzen bei mir resultieren. Was also tun?

Map, reduce

Der folgenden Überlegung liegen zwei Theorien des 20. Jahrhunderts zur Modellierung von Wahrnehmung und Lernen zugrunde: Mentale Modelle und die drei Ebenen der Wahrnehmung. Danach erzeugen wir ein Situationsbewusstsein durch das Wahrnehmen von Daten (gather data), die wir ihm Rahmen unserer bisherigen Erfahrung verstehen und Interpretieren (generate insight). Basierend auf diesem Verständnis sind wir in der Lage, Prognosen über zukünftige Ereignisse zu treffen (das Erkennen einer Notsituation durch einen Lotsen im Flugverkehr zum Beispiel). Darauf basierende Entscheidungen können wiederum die bisherigen Grundlagen erschüttern und eine neue Basis der Verstehens und damit neuer Vorhersagen bewirken. Mentale Modelle wiederum helfen jedem verständigen Individuum, die Komplexität der Umwelt auf ein erfassbares und mit bisheriger Erfahrung und Muster kompatibles Modell der Wirklichkeit zu reduzieren und somit schnell und Kontext-bezogen Prognosen zu erstellen und aufgrund dieser Prognosen Entscheidungen zu treffen. Folgt man dieser Erkenntnis, gewinnt der Prozess der Ergebnisfindung an Gewicht.

Die Basis der Autonomie herstellen

Damit ich im Zusammenhang eines oder mehrerer Teams eine gute Prognose machen kann, brauche ich ein taugliches gemeinsames Modell, das eben nicht nur meine Welt, sondern auch die Welt meiner Kollegen widerspiegelt, um dort die Folgen meines Handels bewerten zu können. Dieses gemeinsame Modell – mit einem gemeinsamen Verständnis darüber, aus welchen Teilen es besteht, welche Interaktionen es hat und wie man es bewegen kann – muss ich zunächst erzeugen. Dazu brauche ich Kontakt zu allen Beteiligten und damit direkten Zugriff auf Wissen und bereits gemachte Erfahrung. Die Erkenntnis darüber, wie in einer solchen Runde Wahrnehmungen gesammelt und abgeglichen werden und anschließend zu Prognosen und Entscheidungen führen, ist der Grundstein für die Fähigkeit zur schnellen Entscheidung jedes Einzelnen. In solchen Meetings darf die Verantwortung nicht mehr an einzelne Personen nach Rangordnung oder einem Gremium, z.B. einer Gilde, abgegeben werden.
Für den Abgleich von Wahrnehmung muss ich systematisch gemeinsame Bilder vervollständen, eine Prognose auf dieser Basis erstellen und eine Entscheidung treffen, die „good enough“ ist.
Diese Meetings sollen neben dem Ergebnis – der Entscheidung – also auch im Prozess der Entscheidungsfindung einen Gewinn an Autonomie erzielen. Dabei darf ich mich nicht durch individuelle Inkompetenz, Alpha-Verhalten, sowie Deutungshoheit, die sich aus Dauer von Zugehörigkeit ableitet, stören  lassen.

Wie erkenne ich, ob ich autonom arbeite?

Die richtigen Leute finden sich, sie finden die rechte Zeit sowie den passenden Ort. Ohne ein Meeting als Entscheidungsrunde einzuberufen oder einen Entscheider zu befragen. Sie kennen den nötigen Kontext, sie teilen ein gemeinsames mentales Modell. Sie teilen die gleichen Prognosen und finden die richtige Entscheidung. Sie verbreiten Ihre Lösungen in die anderen Teams und dort ist diese Entscheidung willkommen. Sie kennen das Ausmaß ihrer Entscheidungen und sind sich der Risiken der Umsetzung wie der Unterlassung bewusst. Sie nehmen Entscheidungen anderer Teams war und können den Einfluss auf ihre Arbeit abschätzen. Ein autonomes Team hat die Fähigkeit zum Richtungswechsel, zur Korrektur und Verbesserung.

Einmal autonom – immer autonom?

Die Reife zur Autonomie erreiche ich nicht einmalig und final, ich muss sie in einem fortwährenden Adaptionsprozess des gemeinsamen mentalen Modells immer wieder  aufs neue suchen. Z.B. wenn sich die Teams ändern,  sich die Anforderungen verschieben, die Technik erneuert wird. Hier gilt es, rechtzeitig zu reagieren, zu erkennen, dass Abstimmung wieder notwendig ist. Eingespielte Teams werden diese Meetings suchen und einfordern, um wieder Flow, Fokus und Effizienz zu erreichen und die richtigen Entscheidungen zu treffen.

Dieser Beitrag ist ein Kompilat aus einer Diskussion im internen Mayflower Blog inklusive der Kommentare.

Noch ein VPN? vagrant up!

These: Aufsetzen von VPNs für ein ganzes Team ist Zeit- und Geldverschwendung!

Aber von vorne:

Wenn wir ein Projekt für einen neuen Kunden starten, steht für uns ganz am Anfang der Zugriff auf dessen Infrastruktur.

Viele Kundeninterna (Jira, Confluence, Sharepoint, SQL-Server, Dateifreigaben) liegen im Netz des Kunden, und wir brauchen erst mal ein VPN, um aufs Netz des Kunden zugreifen zu können.

Hier wird es bunt gemischt: Einige Kunden setzen auf IPsec, wieder andere auf OpenVPN, Tinc oder ein halbes Dutzend herstellerspezifische Lösungen. Weiterlesen

Do you know the difference between continuous integration, continuous delivery and continuous deployment?

Probably every common agile developer has heard these terms. But have you ever thought about the difference between them. I have really been wondering about this question and after some investigation I would like to share all information on this topic i have gathered.

To be able to understand continuous deployment it can be helpful to define its predecessors first – continuous integration and continuous delivery. Continuous integration (CI) usually refers to integrating, building and testing code within an integration environment. It assumes frequent integration of developers code into a shared repository, at least once a day. This makes sure that the local version of every individual developer doesn’t differ too much. Weiterlesen

Fight your Project – Transfer von Kampfsport und agilem Projektmanagement (Theorie)

Projektmanagement und Kampfsport — zwei doch recht unterschiedliche Begriffe, die sich auf den ersten Blick nicht verheiraten lassen. Ersteres bezeichnet einen Pool von Anwendungsmethoden, der in Zusammenwirkung die Initiierung, Planung, Steuerung und den Abschluss von einem oder mehreren Projekten innehat. Im Kampfsport hingegen steht ein Leistungsvergleich innerhalb des Kampfringes im Vordergrund und die Vorgabe, sich außerhalb des Rings in Zurückhaltung und Selbstbeherrschung zu üben. Was beide Termini jedoch eint ist, dass man sich — um Erfolg zu haben — eine hohe sensitive Wahrnehmung im Bereich der zwischenmenschlichen Aktionsebene und des eigenen Bewusstseins erarbeiten muss. Weiterlesen

Crowdtesting – Wie kann man das nutzen?

 

Eine Freundin von mir kam neulich ganz erfreut auf mich zu und erzählte mir von ihren ersten Crowdtesting-Erfahrungen innerhalb ihres aktuellen Projekts. Crowdtesting? Was ist das denn? Und wie kann das in der Praxis funktionieren? Von ihrer Begeisterung ein wenig angesteckt, begab ich mich auf die Suche nach diesen Fragen und löcherte sie nochmal ausgiebig, denn auch ich fand das einen äußerst interessanten und zukunftsträchtigen Ansatz. Schließlich dachte ich mir, das wäre doch eigentlich was für ‘alle’ – Praxiserfahrungen zu einem noch recht neuen Testing der ganz anderen Art! Die Ergebnisse hierzu also im folgenden Blogartikel! Weiterlesen

Zend Framework 3 – Status? (Teil 2)

 

Nachdem ich euch im ersten Teil dieses Blogartikels die ursprüngliche Roadmap vorgestellt und einen Überblick zum ersten großen Statusupdate im Herbst 2015 gegeben habe, möchte ich nun im zweiten Teil darauf eingehen, was weiter passiert ist, welche 3.0-Releases seitdem schon veröffentlich wurden, ob die bisherigen Ziele erreicht wurden und was der aktuelle Stand ist. Weiterlesen

Zend Framework 3 – Status? (Teil 1)

 

In Zeiten der Symfony und Laravel Hypes stellt sich doch mal wieder die Frage, was ein alter Bekannter von uns eigentlich gerade so treibt: Das Zend Framework. Unter dem Motto “Totgesagte leben länger”, hat Matthew Weier O’Phinney im Januar 2015 [1] die Roadmap für das nächste Major Release ausgegeben.
Die neue Version soll eine Weiterentwicklung des Zend Framework 2 sein und Verbesserungen vor allem im Hinblick auf Einfachheit, Wiederverwendbarkeit und Performance bieten.

Wie es seitdem voranging und was der heutige Stand ist, dazu möchte ich euch Einblick in diesem zweiteiligen Blogartikel geben. Weiterlesen

Resource Handling im Repository

PHP-Applikationen sind inzwischen stark modularisiert, composer.json ist inzwischen kaum noch aus dem Projektalltag wegzudenken. Doch dadurch entstehen auch neue Probleme. Irgendwie wollen verschiedene Resourcen (CSS, JS, Templates, …) aus externen Libraries in die Applikation eingebunden werden. Im Symfony-Umfeld hilft dabei in Teilen zwar eine saubere Ordnerstruktur und das Assets-Handling, doch nicht alles ist ein Symfony-Bundle. Ende letzten Jahres hat uns dann Bernhard Schussek (@Webmozart) ein Tool vorgestellt, das hier Abhilfe schafft: Puli. Weitere Infos zu Puli finden sich in seinem Blog.
Weiterlesen

Mit einem Wurf

– oder wie ich strategisch Fokus aufbaue, um große Softwareaufgaben zu lösen

Will man Softwareprojekte mit Expeditionen vergleichen, wird man wahrscheinlich schnell hinken. Dennoch gibt es faszinierende Erkenntnisse, die sich mit etwas Übersetzung gut übertragen lassen. Ein Aspekt ist die enorme und lange Vorbereitung, die je nach Qualität über Gedeih und Verderb einer zeitlich sehr eng gesteckten Umsetzung entscheiden kann. Ein anderer die Fähigkeit zur Reaktion in unbekannten Gegenden, das Parieren des Unvorhersehbaren. Meinen letzten Softwarelaunch als PO hat die Lektüre über Shackleton’s gescheiterte Arktisexpedition begleitet und inspiriert. Weiterlesen