Continuously integrate during development

Once development teams have created their sprint backlogs they are ready to begin development.

During a multi-team development effort, it’s important to integrate code continuously. This is one of the main differences between an agile and waterfall approach to development.

First of all teams must be cross-functional feature teams. This essentially means that each team must have the ability to plan, build, test, and deploy complete features as a team. This is important because in practice you may be working in an complex environment with many different interests. For example, you may have a situation where you are working with multiple third party systems integrators who are specialist in their specific technologies. What you will need to do is ensure that they do not end up working as a component team. For example Salesforce team, Mulesoft team, Oracle team, KPMG team, Marketing team etc. You will need to coach them to self-organise into truly cross-functional feature teams. This will require a mindset shift from simply working as a representative of one’s company to being amalgamated into teams with people from different companies so that the teams can be truly focused on product areas like Shopping Cart team, My Account team, Order Management team etc. This way each team is grouped around a set of features related to a product area, as opposed to being grouped around a technology that their company has expertise in.

Truly cross-functional feature teams must be encouraged to integrate continuously. They should split large changes into small micro ones so that changes can be coded and released quickly.

They should write automated acceptance tests before beginning to code and integrate the micro changes. If every item that is coded and integrated has automated acceptance tests written and run it will also mean the test effort is integrated such that you are testing integrated solutions rather than individual items.

If a change breaks the build then we must stop and fix broken builds immediately. This shouldn’t be a daunting task however if you practice continuous integration of micro changes. The smaller your changes are, the easier it is to identify and remedy code that breaks the system.