Frequent integration is key to predictability and shorter cycle times

 

Frequent integration is key to predictability and shorter cycle times

As long as there is more than one person working on the same solution capability, there will be differences and inconsistencies in how they think and act. Simply because these are different individuals. The inconsistencies may have a pretty drastic impact on the development process. 

The problem of late integration 

Let’s say we have two people working on the same software feature. They both are highly qualified and because of that they assume that they each implement the right thing the right way. But their respective areas of code are supposed to interact with each other, to exchange data, to invoke action on each other’s side, to make this feature possible. And for every such interaction point in code our two developers have to decide how to implement their own part, so that the two parts would be compatible. In simpler cases they just independently decide how to proceed. In more complicated ones, they discuss the implementation and then go back and make it happen. The problem is that they don’t integrate until done with all their work in the release. But whether discussed or not, those interaction points within the code begin to accumulate inconsistencies. And then new code is built on top of something that is already inconsistent, making it an even more drastic disconnect. Finally, when the time comes to integrate, they are in a big trouble as the two parts of code refuse to work together. And fixing it takes a lot of time. 

Because of the complexity of software solutions, just planning or talking about the implementation is not enough to prevent from inconsistencies. It is required to actually integrate to find out if the separate parts are working together. And the sooner you do that, the better, because errors in software have a tendency to get exponentially more costly over time in terms of fixing. And when it’s not just two developers but a whole team or maybe even multiple teams working on the same functionality, it is going to be a serious problem unless frequent integration process is in place.

Establishing frequent integration

To establish frequent integration, here’s what you have to keep in mind. The reasons why teams do not routinely integrate their work are both psychological and technological in nature. 

On the psychological side, confirmation bias drives people to work on their part without integrating with others, firmly believing that “it will work out just fine”. And even when it doesn’t, it may not be perceived as evidence that the assumption was wrong. If this is the case, some intervention is required in the way the group operates. Ultimately, the team members have to understand the problem and connect the dots. 

On the technology side of the business, the current infrastructure may not be optimal for frequent integration. It may be very hard, for instance, to integrate the full solution even just a few times per iteration, because there’s no automated database deployment process, for instance, that would provide meaningful data. Also, additional activities are usually required, such as sustaining meaningful automated tests, as integration without testing is a very shallow way to validate if you are on the right track. So, technological infrastructure has to be ramped up to the challenge. But it’s also not as difficult as it may sound, and it is important that you, as a team, do not allow this to become an excuse to not integrate early and often. 

Establishing frequent integration gives the team an ability to reveal unknowns very early in the game, helping the process to be much more predictable and—because of significantly reduced rework—much faster. 

Taking action

If you are a team that does not integrate frequently within the team or even with other involved parties like other teams or vendors, or maybe you even integrate quite frequently, but the integration is rather shallow, it is time to take action. Plan the simplest first step in making your integration process more effective. 

Alex Yakyma

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.

Explore more content

Improving in the moment

Seeing the opportunity
Read more

Being an Agile developer

Knowledge workers are key to Agile <
Read more

Unit and Integration Testing Overview

The two important types of testing <
Read more
Contact Us