Developers, developers, developers!

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.

Throughout the rest of the text the terms Product Owner, Developer(s), Product Goal, usable Increment, and Product Backlog Item(s) are meant in the sense of the Scrum Guide.

To contrast the missing focus on developers in agile transformations, the following pays special attention to the role of developers in the context of agile transformation, organisation, and teams: Developers need new technical skills, a changed mindset, and basic business knowledge when working in agile teams as opposed to traditional software development.

As part of a successful Scrum, Developers must take a more proactive role in product development by proposing valuable change.
For this, the Developers need to gain knowledge in the Product Owner’s domain and the confidence to discuss with the Product Owner as equal partners. Finally on a more technical note, Developers require the DevOps knowhow and culture to allow for the frequent incremental releases expected from agile teams.

Developers must understand where the customer problem itself ends and the “solution bias” of the proposing costumer or Product Owner starts.
When describing a problem, we tend to already have a solution in mind. It is hard to separate the two, and for explaining the problem that solution can actually help the recipient with understanding the problem better. But this “solution bias” can lead to the selection of the most obvious solution instead of the most advisable – especially if the Developers lack the confidence or experience and knowledge in the business domain to question it. What is more, separating the customer problem from potential solutions needs experience and training and is not something expected from a developer in a traditional development model. Yet the customer problem should be solved with the “best” solution – which has to take into account complexity, effort, and impact on the product solution overall (think technical debt or more complex UX (“feature creep”)).

Architectural changes that improve quality or allow for faster development of new features should be identified by Developers – not others.
These changes must align with the outlook given by the Product Goal which means that Developers need to think strategically and take the initiative on potential Product Backlog Items. This behaviour is not as paramount in traditional development as the product does not grow incrementally and new releases are planned with a multitude of features in mind, which more easily spawns discussions on architectural changes. The technical implementation of the product is the responsibility of the Developers, so they are the only ones who can take an informed decision on when architectural change is needed.

The Developers’ insights on the technical implementation allow for identification of “quick wins” if they bring along the strategic mindset.
“Quick wins” are changes that are very easily implemented and still provide considerable value. To identify those, one must have deep understanding of the technical implementation of the product (which can only be expected from Developers) and at the same time understand and pursue the Product Goal which requires a strategic or business mindset.

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.

For an eye-to-eye discussion some level of shared vocabulary and methods is very important.
For Developers this includes some knowhow in business topics as well as profound domain knowledge (after all this is what the product and therefore its development should be all about).

Transitioning from a traditional model, Developers have to build the confidence to feel and discuss as equal partners, because traditionally the management is “above” them organisationally.
Actually living this changed constellation takes time and repeated reflection, because we, humans, tend to fall back into old habits. In discussions within a hierarchical structure the leaders are expected to give the input and to take the final decisions. This gives the others a more passive role which automatically results in less input and less active and vigorous feedback by them.

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.

A DevOps culture considering the whole process spanning development, integration, deployment, and operation of software might not be essential if there is one release per year, but it certainly is if there is a new usable Increment at least each month.
The frequent Increments demand constant integration of (in other words building) the software, which simply is too time consuming if performed manually. Long bug fixing periods with rigorous manual tests of every component have no place in this fast-paced environment either, which is why there has to be at least some level of automated quality control. And to bring the “Ops” to the “Dev”: if there are new features brought to production at least each month, the operation of the new software cannot be merely an afterthought but needs to be considered in every step of the way. Otherwise the “usable Increment” will not be that usable after all.^[4]

Building a DevOps culture and acquiring the necessary knowledge and skills needs to be on the Developers’ minds and one of their goals, not the Product Owner’s or Scrum Master’s, as it is at the heart of the Developers' domain.
This means Developers need to request the time to grow into those new topics from the Product Owner. Once there is the necessary basis, recurrent adaptation and improvement remain necessary. Identifying and bringing forward these potential improvements is the responsibility of the Developers. Afterall improvements in this area heavily impact their daily work.

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 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.

The article considers a Scrum team, as it is the smallest unit of cross-functional organisation with well-established terminology, yet the general concepts also apply elsewhere:

Agile transformation shifts some responsibility away from the previous leaders towards others. These new persons responsible need a changed mindset and new skills at least as much as the servant leaders to-be.

If you believe in your developers as an important part of your agile transformation, we as Tallence can accompany you on your journey.

Article by: Philip Wintersteiner

Artikel von: Philip Wintersteiner

^[1] Two exemplary articles on this subject:
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“ kann dies nicht beheben, da jedes Feature jedes Developers einfach betreibbar sein muss.

^[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.