This pattern is about an approach I used quite a couple of times to deal with inter team dependencies.
In cooperation with Kate Terlecka for review and feedback.
A project consisting of multiple Scrum teams must produce a potentially shippable increment every sprint. Each Scrum team develops features independently. All Scrum teams together develop multiple integrated features at the system level.
Scrum team 1 develops a feature for ordering a new product through a web shop. A second Scrum team 2 develops a feature for billing and administrating the new product in the financial systems. The overall feature value is in the two features working together correctly.
Projects consisting of multiple Scrum teams must provide a mechanism for organizing the development and execution of system level tests in each sprint. Many of the technical problems in the development life cycle are addressed by continuous integration practices. The remaining problem is organizing who is developing and executing the system level tests and how to deal with defects.
• Postponing system level testing increases risk about project progress and feature correctness. If a separate team is responsible for system level testing unnecessary hand-offs, delay and upfront planning is needed.
• Developing and executing system level tests requires effort from the Scrum teams involved. The Scrum teams should therefore be able to plan for system level test activities in their sprint-planning meetings.
• No explicit Scrum team is in charge for developing and executing the system level tests and as a result ownership and commitment may suffer. The Scrum teams involved should therefore explicitly commit for delivering it.
• The Scrum teams needed to provide features at the system level can differ from sprint to sprint. For example, feature 1 & 2 needs Scrum team 1 & 2 while feature 2 & 3 needs Scrum team 2 & 3. It should be possible therefore for Integration Scrum composition to change each sprint.
Introduce an Integration Scrum event where Scrum teams representatives collaborate on getting the tasks done and create a shared plan for system level testing activities for the involved Scrum Teams.
Introduce an Integration Scrum event where representatives of the Scrum teams collaborate as frequently as needed for getting the tasks done related to system level testing. The Integration Scrum is responsible for defining system level test tasks and making them transparent to their Scrum Teams on their Scrum boards. The people who are actually working on a Scrum Integration task take place in the Integration Scrum events.
Identify system level testing Scrum Team dependencies during Sprint Planning I. The Scrum Teams choose which features to implement and therefore also know with which Scrum teams they need to work together the coming sprint. In Sprint Planning II the Scrum Teams together plan the work needed to develop and perform system level testing and commit to it. A result could be a shared task list for system level testing activities.
This pattern enables Scrum teams to extend their Definition Of Done more easily with integration and system testing.
The intent of the Integration Scrum is similar to the Scrum of Scrums. The Integration Scrum specializes the Scrum of Scrums, which is a generic form of synchronizing multiple Scrum teams. If the Integration Scrum hampers lateral communication use Scrum of Scrums and Daily Scrum to find a solution.