Im folgenden Text sind die Begriffe Product Owner, Developer(s), Product Goal, (usable) Increment, und Product Backlog Item(s) Im Sinne des Scrum Guides zu verstehen.
Im Gegensatz zum fehlenden Fokus auf Entwickler in agilen Transformationen, wird im Folgenden besonderes Augenmerk auf die Rolle von Entwicklern im Kontext agiler Transformation, Organisation, und Teams gelegt: Developer benötigen bei der Arbeit in agilen Teams im Gegensatz zur traditionellen Softwareentwicklung neue technische Fähigkeiten, ein verändertes Mindset, und grundlegendes unternehmerisches Wissen.
Als Teil eines erfolgreichen Scrums, müssen Developer eine proaktivere Rolle in der Produktentwicklung übernehmen, indem sie wertvolle Veränderungen vorschlagen. Dazu müssen die Developer Kenntnisse in der Domäne des Product Owners erlangen und das Selbstbewusstsein haben, mit dem Product Owner als gleichberechtigte Partner zu diskutieren. Außerdem benötigen die Developer das DevOps-Know-how und die –Kultur um die häufigen inkrementellen Releases, die von agilen Teams erwartet werden, zu ermöglichen.
Developer müssen eine proaktivere Rolle in der Produktentwicklung übernehmen, indem sie wertvolle Veränderungen vorschlagen.
Entwickler müssen verstehen, wo das eigentliche Kundenproblem endet und wo die „Lösungs-Voreingenommenheit“ des vorschlagenden Kunden oder Product Owners beginnt.
Wenn wir ein Problem beschreiben, neigen wir dazu, bereits eine Lösung im Kopf zu haben. Es ist schwer, Problem und Lösung voneinander zu trennen. Und bei der Erklärung des Problems kann die Beispiellösung dem Adressaten tatsächlich helfen, das Problem besser zu verstehen. Aber diese „Lösungs-Voreingenommenheit“ kann dazu führen, dass die naheliegendste Lösung gewählt wird, anstatt die Zweckmäßigste – vor allem, wenn den Developern das Vertrauen, oder die Erfahrung und das Wissen in dem Geschäftsfeld fehlen, um sie zu hinterfragen.
Hinzu kommt, dass das Trennen des Kundenproblems von möglichen Lösungen Erfahrung und Training erfordert und von einem Entwickler in traditionellen Entwicklungsmodellen nicht erwartet wird. Dennoch sollte dem Kundenproblem mit der „besten“ Lösung begegnet werden – diese muss Komplexität, Aufwand, und Auswirkungen auf die Produktlösung insgesamt berücksichtigen (man denke an technische Schuld oder komplexere UX ("feature creep")).
Architekturelle Änderungen, die die Qualität verbessern oder eine schnellere Entwicklung neuer Funktionen ermöglichen, sollten von Developern identifiziert werden – nicht Anderen.
Diese Änderungen müssen mit dem Ausblick des Product Goals übereinstimmen, was bedeutet, dass die Developer strategisch denken und die Initiative für potenzielle Product Backlog Items ergreifen müssen. Dieses Verhalten ist bei traditioneller Entwicklung weniger wichtig, da das Produkt nicht inkrementell wächst, sondern neue Versionen mit einer Vielzahl von neuen Funktionen geplant werden, was eher Diskussionen über architektonische Änderungen auslöst. Die technische Implementierung des Produkts liegt in der Verantwortung der Developer, somit sind sie die Einzigen, die eine fundierte Entscheidung darüber treffen können, wann eine Änderung der Architektur erforderlich ist.
Der Einblick der Developer in die technische Umsetzung ermöglicht, wenn sie die strategische Denkweise mitbringen, die Identifikation von „Quick Wins“.
„Quick Wins“ sind Änderungen, die sehr leicht zu implementieren sind und dennoch einen beträchtlichen Wert schaffen. Um diese zu identifizieren, muss man ein tiefes Verständnis für die technische Implementierung des Produkts haben (was nur von Developern erwartet werden kann) und gleichzeitig das Product Goal verstehen und verfolgen, was eine strategische oder unternehmerische Denkweise erfordert.
Developer müssen Kenntnisse in der Domäne des Product Owners erlangen und das Selbstbewusstsein haben, mit dem Product Owner als gleichberechtigte Partner zu diskutieren.
Für eine Diskussion auf Augenhöhe ist ein gewisses Maß an gemeinsamem Vokabular und Methoden sehr wichtig.
Für Developer gehört dazu ein gewisses Know-how in betriebswirtschaftlichen Themen ebenso wie fundiertes Domänenwissen (schließlich geht es beim Produkt und somit auch bei seiner Entwicklung um diese Domäne).
Bei der Umstellung von einem traditionellen Modell müssen die Developer das Vertrauen aufbauen, sich als gleichberechtigte Partner zu fühlen und als solche zu diskutieren. Denn traditionell steht das Management organisatorisch „über“ ihnen.
Diese veränderte Konstellation tatsächlich zu leben, erfordert Zeit und wiederholtes Reflektieren, da wir Menschen dazu neigen in alte Gewohnheiten zurückzufallen. In Diskussionen innerhalb einer hierarchischen Struktur wird von den Führungskräften erwartet, dass sie den Impuls geben, und die endgültigen Entscheidungen treffen. Dies gibt den Anderen eine eher passive Rolle, was automatisch dazu führt, dass sie weniger Initiative zeigen und weniger aktives und energisches Feedback geben.
Developer brauchen das DevOps-Know-how und die DevOps-Kultur, um häufige inkrementelle Releases zu ermöglichen.
Eine DevOps-Kultur, die den gesamten Prozess aus Entwicklung, Integration, Ausrollung und Betrieb von Software berücksichtigt, ist vielleicht nicht unbedingt erforderlich, wenn es eine Version pro Jahr gibt, wohl aber, wenn es mindestens monatlich ein neues usable Increment gibt.
Die häufigen Incremente erfordern eine ständige Integration (mit anderen Worten: Bau) der Software, was bei manueller Durchführung zu zeitaufwändig ist. Lange Bugfixing-Perioden mit rigorosen manuellen Tests jeder Komponente haben in dieser schnelllebigen Umgebung ebenfalls keinen Platz, weshalb es zumindest ein gewisses Maß an automatisierter Qualitätskontrolle geben muss. Und um die „Ops“ zum „Dev“ zu bringen: Wenn mindestens jeden Monat neue Funktionen in Produktion gebracht werden, kann der Betrieb der neuen Software nicht nur eine Nebensache sein, sondern muss bei jedem Schritt berücksichtigt werden. Andernfalls ist das „usable Increment“ doch nicht so nutzbar.[4]
Der Aufbau einer DevOps-Kultur und die Aneignung der erforderlichen Kenntnisse und Fähigkeiten muss in den Köpfen der Developer und eines ihrer Ziele sein – nicht das des Product Owners oder Scrum Masters, da es sich um das Herz der Developerdomäne handelt.
Das bedeutet, dass die Developer beim Product Owner die Zeit einfordern müssen, um in diese neuen Themen hineinzuwachsen. Sobald die notwendige Basis vorhanden ist, bleiben wiederkehrende Anpassungen und Verbesserungen notwendig. Die Identifikation und das Vorantreiben dieser potenziellen Verbesserungen liegt in der Verantwortung der Developer. Schließlich wirken sich Verbesserungen in diesem Bereich stark auf ihre tägliche Arbeit aus.
Der obige Inhalt gilt für höhere "Ebenen" der (bisherigen) Organisationshierarchie und weniger IT-fokussierte Teams analog.
Der Artikel betrachtet ein Scrum-Team, da es die kleinste Einheit einer cross-funktionalen Organisation mit gut etablierter Terminologie ist, doch gelten die allgemeinen Konzepte auch für andere Bereiche:
Die agile Transformation verlagert einen Teil der Verantwortung von den bisherigen Führungskräften auf andere. Diese neuen Verantwortlichen brauchen eine veränderte Denkweise und neue Fähigkeiten mindestens so sehr wie die angehenden „Servant Leader“.
Wenn Sie an ihre Entwickler als wichtigen Teil ihrer agilen Transformation glauben, können wir als Tallence Sie auf dieser Reise begleiten.
Artikel von: Philip Wintersteiner
[1] Zwei beispielhafte Artikel dazu:
Campgemini: Agile Befähigung - was Servant Leadership konkret bedeutet
scrum.org: why agile transformations sometimes fail
[2] Artikel der die Transition der Schulung erklärt
[3] Laut der aktuellen Statistik (Stand 2021-11-01), gibt es rund 445.000 Professional Scrum Masters und rund 121.000 Professional Scrum Product Owner, während es nur circa 14.000 Professional Scrum Developer gibt, was noch schlimmer ist, wenn man die tatsächliche Verteilung der Rollen in der realen Welt berücksichtigt.
[4] Mit klaren Worten: Eine DevOps–„Einheit“ oder –„Person“ kan n dies nicht beheben, da jedes Feature jedes Developers einfach betreibbar sein muss.