Reducing dependencies in multiple Scrum teams
When multiple Scrum teams depend upon each other, this creates dependencies. How can we identify and manage the dependencies between teams to reduce risk and improve our development efficiency? In this article, I will provide an overview of a number of techniques which can be used to manage dependencies.
According to the 2020 Scrum Guide, “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint”. However, in the real world, this may not be the case, and teams may have to depend upon other teams to carry out part of the development work. A simple example of this may be a team (Team A) that develops the back-end databases and other teams (Team B) which consumes or uses this data in their front-end web or mobile applications.
In these situations, we are faced with dependencies, which need to be identified, managed and aligned. Going with the previous example, Team B (front-end) depends on products that Team A (back-end) has to build, deploy and maintain.
Various techniques exist to manage these dependencies, starting with a BRP or Big Room Planning. Here, all teams get together in one big space (hence the term “Big Room”) to identify the dependencies and plan for the medium-term (usually quarterly). The output of this session is usually a Roadmap, and the session also aims to identify a shared understanding of the product vision and goal, as well as what I consider the most overlooked goal, to serve as a networking, team-building and personal growth space. This facet of BRP is also highlighted by Real Agile or BS in their “Are Quarterly Big Room Planning Meetings Real Agile?” video.
BRP also gives us the opportunity to implement techniques to visualise the dependencies, such as “Dependency Spiders” and “Oh By the Way Dependency Matrix”.
Another technique, the Scrum of Scrums, first implemented in 1996 by Jeff Sutherland and Ken Schwaber, also provides an opportunity to identify any risks that arise due to dependencies throughout the development process between each of the teams involved.
Let’s get down to development — the backend development team (Team A) starts developing by sourcing and creating a new database, tests it, then, when everything has passed the Definition of Done, hands it off to Team B, who have been waiting patiently, so that they can begin their front-end development work and access the database. Do you see any inefficiencies here?
That’s right. Team B is waiting for Team A to completely finish, before they can even start. A Finish-to-Start dependency exists between Team A and Team B (yes, we are returning to project management concepts). Once the database has been developed, tested and deployed, only then can the front-end team begin their work. Mike Cohn, one of the original contributors to the Scrum framework, recently spoke about a technique to reduce dependencies in his blog. By attempting to convert Finish-to-Start (FS) relationships to Finish-to-Finish (FF) relationships, this allows other team members or other scrum teams to begin working on an activity, without having to wait for the predecessor to have finished.
In this example, the database structure (interface) could be defined early on in the process by Team A and delivered to the front-end team, so that they can begin their work with the aim for both teams to finish at the same time. Or the database tables could be populated early with a few lines of sample data. If working with classes, the interfaces could be defined and communicated to the other teams, and the details of their implementation carried out later in the development process.
Another technique which aims to fulfill the Scrum Guide, is to develop T-shaped skills within a team, so that a team has all the resources and competencies and doesn’t depend upon other teams to complete the Scrum goal. A team with Cross and Deep Discipline Expertise would be able to develop and deploy a database as well as develop and deploy the front-end. Ken Ruben, author of the Amazon best seller, Essential Scrum, refers to this technique as the creation of Feature Teams.
Mike Cohn inferred that the Definition of Done (DoD), a checklist created by each team to determine when a story is complete, could also determine how agile a team is. When done wrong, it leads to sequential work thereby increasing dependencies upon team members and even multiple teams.
Finally, other techniques recently identified in Philip Roger’s medium article, also include improving the communication between teams. By sending representatives from Team A to the daily Scrum of Team B, and vice versa, or including a talk about “reducing dependencies” in the Scrum retrospectives, or simply encouraging ad-hoc conversations, dependencies can be better managed and communicated throughout development process.
Last updated: February, 2022.
