Effective practices for a successful software transition

In software development, we often want a stable team that works on a product from start to finish. In reality, however, it often happens that a software system is handed over to a new team, whether due to changes in responsibilities or the introduction of new suppliers. This transition is called a transition. The question now is how to optimise this transition. Fortunately, we can fall back on various agile software development practices. Agile software development emphasises well-functioning teams and promotes effective knowledge and skill building throughout the team.

In the following, I will present five practices that can be particularly effective in the context of transitions. To apply these practices effectively, I recommend forming a joint team of old and new team members during the transition. Over time, the old team members can then gradually leave the team to enable a smooth transition.

Pair programming – a practice for two people

In pair programming, two developers work together at one workstation to develop code. They follow a defined interaction pattern, such as the driver-navigator pattern. One person programmes (driver) while the other person checks the design and provides feedback (navigator). The roles change at short intervals, often several times an hour.

In the context of transitions, the principle of shadowing and reverse shadowing has been known for many years. Compared to traditional shadowing, however, pair programming offers a significant advantage:

• In shadowing, one person takes on a passive role, which in practice often leads to hours of watching with occasional queries. However, real ability is only built up through concrete action. In pair programming, this is ensured by regularly changing the driver and navigator roles. The navigator also actively intervenes in the development process by providing continuous feedback.

In the context of a software transition, the new team member should start in the driver role and get involved right from the start instead of just passively watching. As there are often major differences in knowledge and experience between the tandem, it is important that the navigator repeatedly provides context. In some cases, it may also be worth starting the pairing session on a whiteboard or with a joint look at the system documentation.

Mob programming is also an interesting alternative to pair programming. In this practice, other people and sometimes even the entire team work at one workstation. One person is the driver, everyone else is the navigator. Mob programming can ensure an initial transfer of knowledge, especially at the start of a software transition.

Test-driven development – really practical

In test-driven development (TDD), tests are used to control software development. The process is cyclical:

• A unit test is written for a piece of functionality, which initially fails because the implementation of the functionality does not yet exist.
• Enough code is implemented for the unit test to run successfully.
• If necessary, the test and code are reviewed and refactored.

However, test-driven development is not just about achieving high test coverage with unit tests; the unit tests are more of a very valuable side benefit. By writing a test before the actual implementation, new team members understand the task better, as the intention of the implementation becomes clear. In addition, working in small steps makes the complexity more manageable for everyone involved.

In practice, the consistent application of TDD in conjunction with pair programming proves to be extremely useful. Ideally, one member of the old team writes the unit tests, while one person from the new team implements the code. An additional advantage is the greater security when adapting existing code, as the existing unit tests provide quick feedback for the implementation. Test-driven development as part of a transition is therefore really practical.

The exchange in retrospectives

Are you familiar with the situation where transitions are carried out according to the “eyes closed and through” principle? In practice, I have observed several times how a schedule was fixed and worked through, regardless of how well or badly the transition actually progressed.

Retrospectives can be a valuable tool for pausing and reflecting together with the team on how the transition is actually proceeding. If a team is already using the retrospective as a tool to improve collaboration, then it makes sense to actively talk about the transition. It is important to focus explicitly on the transition so that the discussion does not become too broad in terms of topics.

For teams that do not yet work with retrospectives as part of their methodology, this can be a good starting point for a regular dialogue. In such cases, the first retrospectives will focus thematically on the transition, with the hope that the team will continue this fundamentally valuable practice after the transition.

Done Done – the agreed quality

Done Done means that a team makes a clear, explicit agreement about what work is needed to finalise a new functionality. The Definition of Done (DoD) is such an agreement that helps in two ways:

1. It assists members of the new team to understand crystal clear what activities are required to complete a functionality. This prevents activities of the old team, such as the creation of system documentation or the use of unit tests, from simply being omitted by the new team.
2. It makes it easier to recognise where the transition really stands. Delivering productive software that fulfils all the quality criteria of the Definition of Done is a hard currency that, unlike many other methods, cannot be faked so easily.

Experience shows that a new team that is already actively using a Definition of Done in the course of software development often provides reason for optimism. As the DoD is also a “living” document, it is advisable in practice to scrutinise the criteria cyclically and adjust them if necessary, for example if the new team identifies points that it is unable to achieve.

Ubiquitous language – the practice of everyday use of language

Numerous transitions take place in an international environment. Unfortunately, Babylonian language confusion often prevails not only with natural languages, but also with the expressions that team members use among themselves.

Ubiquitous Language, a technique from Domain Driven Design, provides a remedy here. It suggests that all team members agree on common expressions to be used consistently within a certain context. Ideally, the expressions are derived from the functional domain, e.g. a domain model.

Let’s assume a team has the task of generating sheet music in XML from a description of music. The team’s ubiquitous language should not revolve around XML terms such as entities, elements or attributes, but should use terms such as score, voice, staff, clef, notation, etc.¹

The practice of transitions shows time and again that at the beginning of a project, nobody should assume that everyone has the same understanding of certain terms. It is important to communicate a common language to the members of the new team, as this facilitates communication both with each other and with stakeholders. It is the responsibility of the members of the old team to point out to new people that their use of terms may be unclear or incorrect.

Without the use of a ubiquitous language, confusion is inevitable. New team members know little about the old team’s terminology or – even more seriously – they interpret the terms differently. This repeatedly leads to misunderstandings and can result in incorrect implementations.

Conclusion

The application of the five practices

• pair programming,
• test-driven development,
• retrospectives,
• done done and
• ubiquitous language

have provided me with valuable services in several transitions. Each individual practice offers numerous advantages on its own, but when combined they also develop a very special dynamic.

Of course, the practices do not only prove their worth in transitions: They make a fundamental contribution to the development of good software. And good software is in turn easier to hand over to new teams. So you benefit from the practices in two ways. Simply try them out at the next opportunity.

Notes:

Would you like to talk to Jonathan Frankenberger about agile working methods, machine learning or software development? You can easily get in touch with him via LinkedIn.

[1] The example comes from “The Art of Agile Development”, 2nd edition 2021, pages 329-331

If you like the article or would like to discuss it, please feel free to share it in your network.

Jonathan Frankenberger has published another post on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.