The loss of the product

When I come into contact with companies that are about to enter or are already in the process of an agile transformation, I like to ask what benefits the company's customers can expect from the change.

Surprisingly often, this appears to my contacts as a perspective they have given little or no thought to. The reason for this is obvious: I usually speak with IT managers who are more responsible for the "how" of product mapping and less for the "what, why and why".

This is because agile transformation mostly finds its starting point in the company through the following two drivers:

• There has been a management change and a new leader (usually in IT or IT-related) comes in with the basic idea of agile in tow.
• The organisation has become bogged down and realises that it cannot free itself from this rigidity with the existing process models. The starting point for this is usually in IT because, on the one hand, there is a considerable delivery expectation there due to the vision of digitalising the business model and, on the other hand, the high, technological development speed must be withstood.

The effects of the latter point are in particular a low speed of innovation and long product development cycles. Those responsible for product definition, however, usually do not see their own part in the cause of the organisational state. After all, it is IT that does not deliver, the product-defining specialist side has many ideas that pay into the digitalisation vision. If only IT were faster and delivered better quality, customers would also be more satisfied. Thus, the problem is localised and there is an expectation that it should also be solved locally.

The IT manager, on the other hand, with the pure focus of transformation on his own organisation, is possibly acting against better knowledge, but within the scope of the possibilities that remain for him in the existing power structure. He must first prove himself and his approach in IT before he can face the business side with strength and self-confidence.

The irony of this situation is that the business side often has its share in the IT infrastructure. Marty Cagan 2008 analyses the cause of deadlocked IT organisations as follows [8]:

“When a company does get into this situation, the company typically blames engineering. But in my experience, the harsh truth is that it’s usually the fault of product management. The reason is that when it comes up, it’s usually because for several years, product managers have been pounding the engineering organization to deliver as many features as the engineering team possibly can produce. The result is that at some point, if you neglect the infrastructure, all software will reach the point where it can no longer support the functionality it needs to.”

The birth defect

The agile transformation begins with a basic attitude that does not fit agility at all. Thinking in categories of "them", IT, who have a problem and the blameless business side, which is only failing because of IT's incompetence, is at the beginning of the process. This significantly increases the pressure on IT, which is already on the verge of dysfunctionality anyway.

The first step of the transformation is typically taken with the implementation of agile methods at team level and the assignment of the necessary roles to people. Since every team needs a product owner, this is of course also determined. But who should take on this role? Obviously, the choice falls on the project manager, since in the past he was the interface to the business side.

This person is now faced with a dilemma. The freshly learned expectations of him are as follows:

"The product owner is accountable for results in maximising the value of the product resulting from the work of the Scrum team. How this is done can vary widely depending on the organisation, Scrum Team and individual. " [1]

And further:

"For the Product Owner to succeed, the entire organisation must respect his decisions. ... The product owner can consider the needs of many stakeholders in the product backlog. Those who want to change the product backlog can do so by trying to persuade the product owner. " [1].

The struggle to truly embrace this role is typically not taken up by the newly minted Product Owner. Deeply rooted in the organisation and knowing the challenges of working with the business side - which does not know and would never recognise this form of role definition - he retreats into his shell and reduces himself to a technical and methodological translator of the product requirements by the business side.

Even an enlightened IT management has little influence in this phase and on this issue, since on the one hand it is still struggling with its own role finding in the transformed organisation and on the other hand the weakness of the sub-organisation at the beginning of the transformation has not yet been resolved.

Crippled agility

The subsequent transformation steps widen the gap that already existed between the business side and IT in the classic organisational form. This is because the quality of the deliveries and the speed of development often decreases even further. Causes for this can be, for example, IT's attempt to build up a CI/CD pipeline in order to shorten release cycles. This ties up capacity and initially reduces the speed of progress in feature development. Cumbersome, but still traditional processes and relationships between departments are strained by new process approaches and a slowly occurring cultural change in IT.

Since, from the perspective of the business side, the performance of IT is not improving, the latter cannot free itself from its defensive role. An upgrading of the position of the product owner as part of this system does not occur; it remains crippled in relation to the actual tasks defined according to methodology.

As a result, the customer is just as distant from the actual, product-manufacturing organisation as he was before. The idea that a product owner or even the development team gets to know a customer and is allowed to discuss product features that are not of a purely technical nature at eye level with the business side is almost illusory.

With the business side as a non-agile, shock- and fireproof buffer between the customer and the increasingly agile manufacturing organisation, the customer can thus not feel the advantages of agile working at all or only in a muted way. In maintaining the interface between the business side and IT, the agile transformation remains incomplete.

The problematic promise of salvation

Ultimately, this situation is about extending agile thinking and working beyond the pure engineering organisation to create an integration of ways of working, with the aim of unleashing the full potential for the customer.

If we recognise the problem, we can seek help. This is offered here, for example, by the most popular scaling framework of agile working, SAFe, which in its latest incarnation also quite clearly proclaims the goal of "business agility" - holistic, agile transformation.

At this point, however, caution is warranted. Even though the framework recognises that the team should be close to the customer and ideally find direct exchange, it outlines an organisational structure that is deeply staggered and makes precisely this direct exchange very unlikely. Thus, in addition to the team [2], the product owner [3], the product manager [4] and the solution manager [5] are supposed to maintain contact with the customer in a scaling relationship with each other. Interestingly, at the top of product development in the largest expansion stage is the Epic Owner, who is supposed to collaborate with everyone to define the MVP - but has no customer contact himself [6].

Even in the smallest stage of development, there is a separation of product management and product owner. Recognising the difficulties the team may have in directly contacting the customer, "Leveraging the Product Owners' skills, knowledge, and responsibilities " [2] is recommended.

The danger with this staggered system is that in the transformation, in the best case scenario, the business side will take on the role of product management and the product owner will still be filled by former project managers. The familiar pecking order will remain the same. In the worst case - I have also seen this in organisations - the implementation of SAFe only takes place in IT and the role of product management is amputated just like that of the product owner. Parallel to this, the old business side exists in unchallenged supremacy and the accustomed attitude of entitlement.

Realisation vs. inner attitude

Agile transformation should actually have the fundamental goal of being able to serve customer needs in the best possible way in the future. As shown, however, this consideration is neither a trigger nor a compelling consequence of the transformation efforts.

But even without the ideas of agile development, it was already clear in the past that the product manager must accompany the creation chain of a product in close feedback with the customer all the way to engineering - and not in the requesting role vis-à-vis service providers, but as part of a cross-sectional team. This realisation did not require agility at all.

On the separation of roles in product design, Marty Cagan writes in 2008:

"The problem is that neither person truly owns the product and more importantly, neither person feels nor behaves like they are ultimately responsible for the product. Further this model is based on a flawed view of software that holds that you can define high-level requirements independent of detailed requirements and especially the user experience. " [9].

At the same time, he thinks method-agnostically in the project management of the manufacturing process. For him, agility is only one of many procedural models for building a software product.

For him, the relationship between the production of the products (in our case IT) and the product manager should be at eye level:

"One key to this relationship is for each of you [product manager and developer] to understand that you are peers - neither position is subordinate to the other. " [10].

Agility now offers the chance, qua basic attitude and method sets, to meet all these requirements free of charge. Why does the product-forming sub-organisation in the transformation process have such connection difficulties or even defensive reflexes?

In addition to the misguided cause-and-effect analyses already described, which place the sole blame for shortcomings on IT, another effect is at work here: the belief in the individual excellence of the product manager. Successful products are attributed to individual, ingenious minds and far too rarely to team success. This mindset also permeates the more modern literature on product management. It is understandable that this makes access to agile thinking, which is more collectivist than individualistic, more difficult. It is all the more absurd that it is precisely this way of thinking that could create the organisational conditions for the product manager to become truly successful ...

Another beginning

Fortunately, we are not talking about natural laws here, but about behavioural patterns in social systems. These can be changed, even if it is sometimes laborious ...

In the past, we have already succeeded in finding approaches to transformation that met the challenges, especially with regard to product management. One possibility is to consciously make sure that when the first agile teams are formed, the product owner role is not filled by IT, but by the business side. It is important to make it clear that this task is not a part-time job, and work should be done to ensure that the new identification space becomes the development team (and not the team of product managers).

At the same time, the business side leadership needs to be aware of the fact that they are affected by agile transformation in the same way that IT leadership is [7]. I.e. in recognition of the fact that their employees - the former product managers and now product owners - are to operate with a large degree of freedom in the long term, their working environment is also reshaping itself. Aspects such as the longer-term strategy and the overarching portfolio vision are moving into focus. Until this really takes shape, it is worthwhile to enter into a transformation coalition with the IT executives and consciously put yourself in the same boat.

It can also be put much more simply: The business side must be part of the agile transformation from the very beginning. If this basic idea is followed, the only thing left to do is to make sure that no cargo cult is practised with regard to product formation and agility - but this risk is inherent in all aspects of agile transformations.

I wish that the agile transformation would also be initiated by a specialist side for once. Ultimately, modern product development methods (such as product discovery) require cross-functional, iteratively working, self-organised teams - the path to cross-organisational, agile thinking is then not far away. And in the end, the one for whom we do all this will certainly benefit: the customer.

Sources

[1] Schwaber, Ken; Sutherland, Jeff, “Scrum Guide”, scrum.org , 11/2020, p. 6

[2] Scaled Agile, “Agile Teams”, viewed on 7/3/2023 11:52 CET, https://scaledagileframework.com/agile-teams/

[3] Scaled Agile, “Product Owner”, viewed on 7/3/2023 11:43 CET, https://scaledagileframework.com/product-owner/

[4] Scaled Agile, “Product Management”, viewed on 7/3/2023 11:43 CET, https://scaledagileframework.com/product-management/

[5] Scaled Agile, “Solution Management”, viewed on 7/3/2023 11:45 CET, https://scaledagileframework.com/solution-management/

[6] Scaled Agile, “Epic Owner”, viewed on 7/3/2023 11:45 CET, https://scaledagileframework.com/epic-owner/

[7] Barth, Stefan, “Opferreduktion in der agilen Transformation”, 04/2023 https://www.dhirubhai.net/pulse/opferreduktion-der-agilen-transformation-dr-stefan-barth/

[8] Cagan, Marty, “Inspired - how to create products customers love”, SVPG Press, 2008, p. 27 f.

[9] Cagan, Marty, “Inspired - how to create products customers love”, SVPG Press, 2008, p. 9

[10] Cagan, Marty, “Inspired - how to create products customers love”, SVPG Press, 2008, p. 21