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 need to take a more proactive role in product development by proposing valuable change
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.
Developers need to gain knowledge in the product owner's domain and the confidence to discuss with the product owner as equal partners
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.
Developers need the devops knowhow and culture to allow for frequent incremental releases
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.
The points above analogously apply to higher “ranks” of (previous) organisational hierarchy and less IT focused teams
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
[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.