Following Scrum guidelines and principles to the letter isn't always easy. Perhaps it isn't even desirable. Often, circumstances dictate how Scrum is best used in dev teams and companies. Stefan Höhn describes an innovative approach to solving the problem of distributed Scrum teams, something which he calls the “Distant Scrum Master”, or, to emphasize the importance of the role, “Main Scrum Master.” In his post he discusses how teams can maximize efficiency and performance, both for themselves and their clients.
In the best of all possible worlds, a Scrum team (consisting of Dev Team, Product Owner and Scrum Master) is co-located in one space, allowing for optimal communications.
Reality, in many instances though, is quite different. In this real-life example, Höhn describes a situation where the Product Owners (PO) and Scrum Masters (SM) of the client are in one location, the development teams in another. In contrast to other situations, here, several dev teams are working for the same client.
What to do?
The proposed solution was to establish a local Scrum Master, a suggestion that was met by resistance on the part of the existing SMs. As an alternative it was suggested using an Agile coach at the location of the dev teams. This, too, created conflict, but the POs, SMs and dev teams decided to try this option.
The results exceeded all expectations. After the initial storming phase and rapid scaling of the teams the concept proved to be the right one for the situation.
After further refinement of the concept, including work processes and ceremonies (events) as well as strengthening mutual trust, the original idea of an internal Scrum Master was brought up again by the dev teams. And again, the results were extremely positive. The newly established role, the so-called “Proxy Scrum Master” helped the dev teams to further mature, while improving performance and communications among all stakeholders in the process.
The concept of a local “Proxy Scrum Master” might not work for everyone in similar situation. But solving problems in a flexible manner are one hallmark of an Agile philosophy. Thus Höhn's conclusion: “Agile is about trying out new ideas and doing experiments.”