Get in touch
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.”
Agility & Organisation
In software development projects it is often assumed that quality assurance is taken care of by software testers. But it is a team task!
Agility & Organisation
In the agile context, working with requirements poses major challenges for everyone involved. To avoid errors that arise from ambiguous requirements, there are methods that the team can use to identify and prevent them more quickly.