Scrum of Scrums  … the Scrum Team working on a single product is getting bigger and needs to split into multiple teams. The development teams now need to keep track of progress between parts of the product and monitor dependencies and alignment issues. Issues that cannot be resolved within individual teams become a shared challenge of all teams. ✥ ✥ ✥ When more then one Scrum Team needs to work together to create a potentially releasable product Increment, inter-team coordination warrants explicit attention. Multiple Scrum Teams working on the same product need to coordinate their work and resolve inter-team dependency issues. But you often cannot know in advance all of the dependencies and how to resolve them. Even with extensive up-front planning, during the Sprint unforeseen dependencies may emerge that need to be handled by the teams. Preferably a Development Team should be able to completely develop a Product Backlog Item (PBI) in isolation. In that case you only need to worry about integrating multiple independent PBI’s into one product. In some cases however, it is not possible or desirable for a single team to develop a PBI on its own and we end up with PBI’s that span multiple Development Teams. Frequent collaboration and synchronization enables the Development Teams to produce a Regular Product Increment every Sprint. Each Development Team develops independently, but all Development Teams together should produce an integrated whole. No single team should be responsible for integrating the work of the various Scrum Teams, it is the responsibility of all Scrum Teams. If a separate team is responsible for integrating the work unnecessary hand-offs and delay on feedback is introduced. On the other hand, if no explicit team is accountable to produce an Increment, ownership and commitment suffers. Integration work is left undone. The Development Teams involved should therefore explicitly commit to perform the overlapping work. Therefore: Introduce a recurring Scrum of Scrums event where Scrum Team representatives create a shared plan to discover and resolve inter-team dependencies and impediments. You can identify Scrum Team dependencies during Sprint Planning. The Sprint Planning Meeting has two focus points that answer the following questions respectively
Answering the first question helps identify overlapping work and dependencies. The Development Teams choose which PBI’s to implement, therefore they also know with which other Development Team they need to work together the coming Sprint to perform overlapping work. In answering the second question, the involved Development Teams plan the work needed to develop and perform the overlapping work. The Scrum of Scrums event occurs regularly and as frequently as needed. In the Scrum of Scrum events the participants explain:
Development Team members, who are actually working the overlapping work, attend the Scrum of Scrums. The Scrum of Scrums can discover new overlapping work that is needed to solve inter-team impediments and dependencies. The attendees make the newly discovered work transparent to their Development Teams by bringing it back to their team's Sprint Backlog.Although the Scrum of Scrums is an event for resolving inter-team dependencies and impediments, their resolution should not be postponed until the Scrum of Scrums event. Impediments are worked on as soon as they emerge. Development Teams are empowered to organise themselves to get their work done and minimise dependency risk using Dependencies First. The Scrum Master helps to remove impediments to the Development Team's progress and can invoke the Emergency Procedure as a last resort. ✥ ✥ ✥ Multiple Scrum Teams organize themselves each Sprint to plan the overlapping work and deliver Regular Product Increment. The Scrum of Scrums enables the Scrum Team to extend their Definition of Done more easily. As a result there is fast feedback on dependency problems so these can be handled in the most effective way.
Author: Cesario Ramos |