DevOps - Berücksichtigung der Cognitive Load als Erfolgsfaktor

Mit der Einführung von DevOps ergeben sich sehr schnell einige grundlegende Fragen: Wie organisiere ich meine Teams? Wie gestalte ich die Produkte? Welche Freiheiten überlasse ich den Teams?

Mitunter spielen bei dieser Gestaltung nicht nur inhaltliche Aspekte, ausgehend von der eigentlichen Aufgabe, eine Rolle. Oft werden Entscheidungen auch getroffen, getrieben aus rein wirtschaftlichen Gesichtspunkten oder aufgrund von Rahmenbedingungen der bestehenden Organisation. Diese Entscheidungen sind oft Kompromisse und im weiteren Verlauf manchmal nicht hilfreich für die Lösung der eigentlichen Aufgabe und das Erreichen der damit verbundenen Ziele. 

Ein Aspekt der oft keine oder zu wenig Berücksichtigung findet ist der sogenannte Cognitive Load. Als Cognitive Load wird der geistige Aufwand bezeichnet, der für eine Aufgabe im Arbeitsgedächtnis benötigt wird (John Sweller). Ursprünglich kommt der Begriff aus der Lerntheorie. Cognitive Load entsteht durch die Art der Aufgabe für sich: Hat sie Abhängigkeiten? Kann ich einzelne Elemente betrachten? Wie komplex ist die Gesamtstruktur? Aber auch durch die Art und Weise wie Inhalte zugänglich gemacht oder aufbereitet werden. Ein Aspekt, der z.B. in der Gestaltung von User Interfaces eine Rolle spielt.

Es ist sehr schnell klar, dass jeder Mensch und damit auch jedes Team nur über einen begrenzten maximalen Cognitive Load verfügt. Übersteigt der für die Lösung der Probleme notwendige Aufwand den verfügbaren maximalen Cognitive Load, scheitert das Team zunehmend an seinen Aufgaben und wird ineffizient. Es kann den Flow nicht mehr aufrecht erhalten.

Die Belastung des Teams wird dabei durch unterschiedlichste Elemente erzeugt. Beispiele sind hier die verwendeten Technologien in einem Vorhaben, die eingesetzten Programmiersprachen und deren Anzahl, die Struktur und Architektur der betrachteten Systeme, Anzahl und Komplexität der Schnittstellen, sowohl technisch als auch organisatorisch. Weiterhin spielt die Gestaltung der Prozesse, in welche sich das Team einbetten muss oder die es selbst für seine Arbeit verwendet, eine Rolle. Ebenso wie die inhaltliche Komplexität der zu verstehenden Anwendungsfälle und der fachlichen Domäne. 

Ich stelle mir immer vor, dass ähnlich wie bei meinem Notebook, jedes Team immer bestimmte (Hintergrund-)Prozesse behandeln muss, die vielleicht auch gar nicht transparent sind. Zum Beispiel der Umgang mit einer komplexen, nicht zu den Aufgaben passenden Organisation. Diese Dinge muss ich von der “Rechenleistung” des Teams abziehen. Was übrig bleibt, kann für das genutzt werden, was tatsächlich produktive Arbeit ausmacht. In manchen Organisationen scheint das dann nicht mehr viel zu sein.

Wie kann uns das Konzept Cognitive Load in unseren Vorhaben helfen?

In erster Linie sollten wir uns bewusst machen, dass ein Team nicht beliebig viel bearbeiten kann. Versucht man den Cognitive Load zu berücksichtigen, tun sich verschiedene Spannungsfelder auf, die individuell aufzulösen sind: 

• Die Organisation, Prozesse und Schnittstellen, die das Team bedienen muss
• Die eingesetzten Technologien, Werkzeuge und Frameworks
• Die Komplexität des oder der zu betrachtenden Produkte und Domänen

Organisation, Prozesse und Schnittstellen

Oft sind Teams mehr damit beschäftigt die Organisation zufriedenzustellen, in welche sie eingebettet sind, als damit, ihrer eigentlichen Arbeit nachzugehen. Man verbringt mehr Zeit in Meetings als damit, Code zu schreiben. Dieser Bereich ist vermutlich am schwierigsten zu verbessern, da es gilt, viele Dinge zu adressieren, die außerhalb des Einflussbereichs des Vorhabens liegen. Was man hier aber auch berücksichtigen muss, ist die Teamgröße an und für sich. Schnittstellen können auch im Team selbst liegen. Die Zahl der in einem Feature-Team durch jeden einzelnen zu bedienenden Schnittstellen steigt exponentiell zur Anzahl der Teammitglieder. Die Teamgröße muss gleichzeitig in einem guten Verhältnis zur Komplexität des Produktes und der benötigten Kompetenzen sein. 

Technologien, Werkzeuge und Frameworks

Oft werden DevOps Initiativen auch mit dem Ziel ins Leben gerufen die Freiheit der Entwickler zu erhöhen. Gemeint ist damit oft, den Entwicklern den flexibleren Einsatz von Tools, Frameworks oder anderen Produkten zu ermöglichen. Traditionell haben vor allem große Unternehmen aus der Vergangenheit starke Governance Funktionen ausgeprägt, die sehr klar vorgeben, welche Software, wann und zu welchem Zweck von wem wie lange verwendet werden darf. Wer sich nicht daran hält, wird sanktioniert oder bekommt keine Betriebsfreigabe. Wer sich aber nun ganz auf die andere Seite schlägt und jedem freie Wahl beim Einsatz der Mittel lässt, dem wird plötzlich wieder der Grund für diese Einschränkungen bewusst: Es entsteht ein Zoo, der nicht mehr gemanagt werden kann. Jedes eingesetzte Werkzeug muss betrieben werden, jedes Werkzeug muss gewartet werden. Die Komplexität der Aufgaben im Team kann durch diese Ansammlung schnell deutlich steigen und die Produktivität mittelfristig spürbar senken. Selbst wenn die Werkzeuge ihre eigentliche Aufgabe erfüllen.

Technologien und Werkzeuge können aber natürlich auch dabei helfen die Cognitive Load zu verringern, in dem Aufgaben automatisiert und vereinfacht werden. Damit sinkt der für sie benötigte geistige Aufwand.

Komplexität der Produkte

Die Komplexität der Produkte kann sich unterschiedlich äußern. Ich habe erlebt, dass Kunden “einzelne” Produkte für Entwicklung und Betrieb ausgeschrieben haben, die sich dann aber als Ansammlung von einzelnen Systemen mit verschiedensten Aufgaben präsentiert haben. Die Systeme wurden nur organisatorisch zusammengelegt, damit ein vergabefähiges Volumen entsteht oder aber die Systeme überhaupt irgendwo untergebracht waren. Wenn dann 1 oder 2 Feature-Teams jeweils 5 oder 6 dieser Systeme betreuen sollen, mit jeweils unterschiedlichen Technologien, wird von den ursprünglich mit der DevOps Einführung verfolgten Zielen nicht mehr viel übrig bleiben.

Was auch in diese Kategorie fällt ist die technische Architektur der betrachteten Produkte. Wie ist das System modularisiert? Wie ist die Pipeline aufgebaut? Was kann automatisiert werden? Wie gut können Fehler identifiziert und das System gemonitort werden?

Fazit

Am Ende läuft es auf ein Abwägen hinaus. Ist das Produkt komplex, sollte das Team nicht mehrere betreuen. Sind Organisation und Prozesse schwerfällig, muss ich meine Aufgaben anders verteilen und kann eventuell kein komplexes Produkt betreuen. Komplexe Produkte sollten vielleicht stärker reglementiert sein, was den Einsatz von verschiedenen Technologien angeht, um das Team vor weiterer Komplexität zu bewahren.

Nicht zuletzt spielt natürlich der Reifegrad des eingesetzten Teams auch eine Rolle. Ein erfahrenes Team ist anders belastbar als ein junges Team. 

Empfehlenswert ist das Buch "Team Topologies" von Manuel Pais und Matthew Skelton. Sie haben sich inbesondere der Frage wie strukturiere ich meine Teams im Kontext Cognitive Load gewidmet.

Wenn euch das Thema interessiert hat, freue ich mich über Feedback in Form von Likes. Wenn ihr auch eine Meinung dazu habt, freue ich mich noch mehr über Kommentare und Austausch oder eine Kontaktaufnahme.