Why software transitions often fail – and how to help them succeed with an agile approach

Despite the recent trend of using cross-functional teams to both develop and maintain software products, many such products will one day reach a point where a different team takes over their development or maintenance. This can particularly be seen in the mobility industry, where there is currently a huge demand for digitalisation. Transitioning a software product over from one team to another can be a feasible strategy for the following purposes:

1. Insourcing product development knowledge that has previously been outsourced
2. Freeing up development capacity for innovative products that is currently tied up in more mature products

The big question is, why do so many of these projects fail? What are the typical challenges encountered in a software transition and how can an agile approach help address them? In this article, we discuss the approach we took when transitioning two of our mobility products. It’s worth noting that these products are still in active development – if you plan to transition a sunsetting application you might consider applying other strategies.

Why do software transitions fail?

Let’s take a look at the most common issues that can create difficulties when transitioning a software product between teams.

No focus on ownership

All agile frameworks place a lot of emphasis on teams taking full ownership of their products. While this wish is also regularly verbalised in transitions, there are often systemic patterns that prevent teams from being able to take full ownership. A great example of this is the separation between “technical ownership” and “functional ownership” where one team is responsible for setting out requirements and the other for implementing them, and one of these responsibilities remains with the incumbent team. Another example is the existence of roles where individuals function as gatekeepers between the team and the users, such as the commonly seen Proxy Product Owner role. This role provides mediation between the product owner and the development team, reviewing product backlog items and later accepting them. While this might sound valuable in theory, the role is highly vulnerable to the customer-vendor antipattern and could prevent direct contact with end users, which is critical for teams to feel ownership over their product.

Making software transitions all about knowledge transfer

Transferring knowledge about the product and its development is an important aspect of any transition, but it's only one part of the story. Indeed, the term “knowledge transfer” is flawed in itself as it implies that you could simply copy-paste knowledge from one brain to another, just like copying files on a computer. Building up knowledge is a complex process that develops over time, so reaching the required level of understanding encompasses much more than simply turning up and listening to a presentation.

Building up the receiving team’s knowledge and ensuring transparency regarding progress is already fairly difficult – but even if this challenge can be overcome, the knowledge alone is not enough. To illustrate this point, think about cooking a meal. Having a good recipe and understanding how to follow it (knowledge) won’t automatically make you a good chef! You need to practice over time in order to gradually convert your knowledge into ability. Traditionally, the progress of a transition is measured by the “transferred” knowledge and not by the emerging ability of the receiving team.

It’s complex, stupid!

In product development it’s become extremely common to refer to the Stacey Matrix or the Cynefin Framework and to follow their suggestions for decision-making. However, software transitions are often approached as though they should be part of the simple domain: expecting clear cause-and-effect relationships, mechanically applying best practices, setting up a predefined plan and then simply executing it. Yet most software transitions exhibit many hallmarks of the complex domain, such as unknown factors and unforeseen events, which calls for the kind of “probe-sense-respond” approach that we tend to see in agile frameworks. This requires us to have a clear goal in mind while also remaining humble enough to accept that our assumptions might be incorrect and that our actions can have unintended consequences.

How to overcome software transition issues: the Product Ownership Transition Manifesto

Being unable to follow a predefined path or “recipe” during the transition processes for our two mobility products, we were faced with the question of what guidance we could follow to make good decisions. Rather than a cookbook, we needed principles! So, inspired by the Manifesto for Agile Software Development, we developed the “Product Ownership Transition Manifesto”. Two of the principles might already sound quite familiar, and as with the original manifesto, while we give due emphasis to the items on the right, we focus more on the items on the left:

• Team-driven osmosis over externally steered transfer
• Developing ability over transferring knowledge
• Close collaboration over comprehensive documentation
• Responding to change over following a plan

Below are some examples of how we applied these principles for our two mobility products.

Team-driven osmosis over externally steered transfer

To give the transition aim and direction, both teams, together with their stakeholders, started by clearly and openly defining a “why”. It’s pivotal that you know whether your primary goal is to follow an insourcing strategy or simply to lower costs. Continue to openly communicate your rationale, reminding your team and stakeholders of your “why”.

The next step in our transition was to build a mixed team consisting of members from both the incumbent group and the receiving party. This left us with a huge team of 20 members, so we immediately split this down into two mixed teams. This split was made between the two products that were developed by the original team, meaning we now had two cross-functional mixed teams that were each handling a single product. Carrying out the software transition was now the responsibility of these new teams, who decided on the next most valuable steps for a successful transition. This contrasts with seeing the transition as an externally steered transfer activity.

In this setup, knowledge – and even more importantly, ability – were now continually emerging among the members of the receiving party. This has more similarities with the biological process of osmosis, where a substance gradually flows from one region to another naturally, without any external push or pull. And rather than “steering” the transfer, leadership was responsible for creating a favourable environment for this osmosis process to unfold.

We made sure that each team had a team coach (in our case a Scrum Master), who was also aware of the intercultural aspects of the collaboration. Especially in the beginning, it’s important to be aware of cultural aspects, however the longer and more closely a team works together the more they develop their own team culture that begins to supersede existing national and other cultures. At this stage, you need to be careful not to “over-culturalise”.

Over time, this enabled the receiving party to take over end-to-end ownership of elements of the product. These end-to-end elements were rather small to begin with – we called it “story ownership” at this stage, but this gradually expanded to “epic ownership” and finally “product goal ownership”. We put a lot of emphasis on developing real end-to-end ownership, in contrast to the team only being responsible for certain phases of product development (like discovery or implementation). Splitting ownership according to development phase results in common problems such as significantly increased lead times and the “telephone game effect”. By not doing this we really helped the receiving party to quickly develop a real “skin in the game”.

Developing ability over transferring knowledge

We started the transition with a short, intense series of knowledge transfer sessions, afterwards switching to a more hands-on approach where team members from the receiving party quickly started to work on product backlog items in sprints. To support the emergence of abilities, we applied best practices from agile software development like pair programming and mob programming. Getting people from the incumbent and receiving parties to collaborate actively in sprints helped tremendously.

To track the progress of the transition, we worked with an “ability map” – we intentionally chose not to call this a knowledge map. We started by defining the relevant product development ability areas and developed a scale that included examples of observable behaviour (e.g., “The person does easier tasks by themself and works together with the team.” and “The person adds value to the project, but still needs help with harder topics.”). We then ran reflection sessions at monthly intervals, where team members assessed their own product development abilities. All self-assessments were made fully transparent within the team so that individuals could easily assess their own abilities in relation to others’. While this approach is clearly not an accurate scientific process, it did create valuable insights into our progress.

Close collaboration over comprehensive documentation

As with the Agile Manifesto, documentation can refer to documents written before or after implementing code. Classical software transition approaches try to create lots of documentation even before a single line of code is written. This can go as far as writing low-level design documents in a futile effort to make sure that the receiving party knows exactly what to implement. On the other hand, extensive system documentation is also often created and seen as the main medium for transferring knowledge.

In contrast, we worked with a product backlog that was co-created by the mixed team and the product owner. Running product goal setting and story mapping workshops together with the whole team served us well in this context. Of course, we made sure that the results of these workshops were properly documented, which is not too difficult if you’re working with virtual whiteboards like Miro or MURAL.

In addition, we put a reasonable amount of effort into maintaining system and user documentation. We saw this as being the collective responsibility of the whole team, making it part of our “Definition of Done” to have the necessary transparency over what’s expected in terms of documentation.

Responding to change rather than following a plan

Instead of coming up with a predefined strict deadline, we decided to measure our initial progress and then, based on this, forecast the point when the receiving party should take over full responsibility for the product. This forecast was constantly updated based on our latest learning. We didn’t use the number of knowledge-sharing sessions we were running as an indicator of progress, instead we looked at the emergent abilities within the receiving party. Our ability map helped us to visualise this progress and communicate it towards our stakeholders.

In order to increase focus on our transition and have clear goals to work towards, we decided to define quarterly transition goals alongside our product goals. These transition goals included things like reaching a certain level on the ability map and reaching the next ownership level.

We also regularly ran so-called “checkpoint sprints” in which the incumbent party was only operating in the background, or even not supporting the receiving party at all. These checkpoint sprints served as experiments where we could simulate the phase when the incumbent party would have finally left the product team. We also used the insights from the checkpoint sprints to plan further software transition activities.

Our key takeaways on software transitions

Our transition process is not yet fully completed, so it’s too early to draw any final conclusions. However, there are already three important lessons that I’ve learned from the experience so far:

• Creating end-to-end ownership for a product takes longer than many classical transition approaches. However, it’s already visible that this approach is more sustainable as it creates teams with real skin in the game.
• As this approach appears to be slower, it’s essential that you have management buy-in right from the start. Without this, you’ll find yourself dealing with constant backlashes and attempts to drag you back into traditional transition approaches.
• It’s important to communicate your progress transparently and be honest about the state of the transition at all times. This will increase your credibility and allow you to retain the trust of your stakeholders.

Transitioning software products is a complex endeavour, with many surprises along the way. Working with the principle-based approach outlined in this article helped everyone involved in our transition to respond to these surprises competently.

Curious to learn more about this topic? Check our mobility page to dive deeper and learn more about our approach to the industry.