Distribué Scrum

Il existe trois configurations d'équipes Scrum distribuées. Les équipes totalement intégrées peuvent obtenir les meilleurs résultats, mais n'importe laquelle des trois configurations peut être efficace si elle est mise en œuvre et maintenue avec rigueur. La variable commune pour décider de la configuration qui conviendra le mieux à votre organisation est la communication. Dans quelle mesure les membres de l'équipe, répartis géographiquement, doivent-ils se coordonner pour créer un produit livrable à chaque sprint ?

Équipe Scrum isolée: Like any Scrum Team, an isolated Team should be cross functional, self-organized, and self-managed. It should also have all the skill sets necessary for delivering product at the end of each Sprint. However, they are working from their own Product Backlog and don’t have any common rituals such as Sprint Planning meetings and Retrospectives with the larger organization. Google’s Ad Words functions this way. Each team serves a specific market very effectively but they don’t have a formal collaborative relationship with each other.

For Google’s purposes, this configuration works fine (they generate 90% of Google’s revenue) and depending upon your companies needs, it may work well for you too. However, there are some major drawbacks. Isolating teams in this way can exacerbate cross-cultural communication issues. Commonly, outsourced teams might not even be using Scrum, and their productivity and rhythm can be more akin to typical waterfall projects. This makes communication and transparency with the home organization extremely challenging and may make the business case for outsourcing a bit dubious. This configuration only works when there is little need for the Scrum Teams to collaborate.

Chevauchement d'équipes Scrum avec Scrum de Scrum partagé can help minimize cross-cultural and communication issues by linking the remote teams through a Scrum of Scrums.This allows the Teams to be in multiple-locations but work on a common project through the Chief Product Owner coordinating efforts between all Scrum Masters. These teams also share a common Product Backlog to coordinate their work. Jeff explains the Scrum of Scrums nicely in the video.

For example, if the Teams were designing a software suite that combines audio, video and text editing, perhaps one Scrum Team would be in charge of developing the video interface while another Team would be responsible for designing the text editor. Each Team would still be capable of delivering a feature set at the end of the Sprint but because the Product Owner is working from one Product Backlog and the Scrum Masters from each Team coordinate with each other as much as necessary, no Team is creating impediments for the others and the code integrates as the Team expects.

There is no formula for the Scrum of Scrums. Perhaps the graphic designers need to meet monthly, the testers weekly and the Product Owner talks daily with the Scrum Masters. The point is for the Teams to reach a certain level of communication saturation that allows them to efficiently coordinate their work.

Scrums intégrés work from the same Sprint and Product Backlog. This can be the most efficient, but also most challenging distribution model, where individual team members are at multiple locations. The best practice is to have roughly half the team in one location and the other half in another so each location has critical mass. Each part of the team should include cross-functional members to mitigate the risk that progress will be held up because someone with a critical skill is in another time zone or geography. Finally, it is important to allow distributed teams to form and gel like co-located teams. Bringing the two halves of the team together for the first few Sprints can facilitate this process.

Scrum Inc. has used this integrated configuration to deliver almost the same performance results as Teams located in the same place.