Many organizations strive to go through an "Agile Transformation". In fact there is a great debate on the word "transformation" in our community. Let's just really call it what it is, an adoption and journey. The first stage is usually embracing the agile values and principles and then selecting a process-framework that helps you live-out those values. Scrum is one of the most widely used process-frameworks for this purpose.
Scrum calls for the 3 Scrum Roles (Product Owner, ScrumMaster, and Development Team). It also calls for 4 ceremonies (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective). It will even provide a little guidance on time the team will need to spend refining their product backlog for the next level of planning. Oh, one last rule is that your sprint (iteration) can't be longer than 1 month. I like to think of it as 4 weeks to keep the cadence consistent. This is about all Scrum will prescribe to a team. Typically, pretty easy to understand, but as Ken Schwaber outlines; difficult to master.
The reason that it is difficult to master is that it takes discipline and rigor to stick to the new routine. Think about any lifestyle change you have decided to make. Eating healthy, working out, reading a book a month, etc... These are hard to implement because they take discipline and rigor to sustain the change. Sticking to the routine is all about embracing the "why" and the values of the change to get you through the times when everyone else is pulling you in different directions.
With Scrum, many issues will be high-lighted and exposed. Scrum is doing its job. Too often however, the organization will make a decisions that might actually slow down the exposure of these problems or worse, enhance the problems.
Sharing of Scrum roles is typically one of the first compromises the organization makes. The organization must work through who fits the roles the best or even deciding to fund the roles. Typically you will see a ScrumMaster also be the Product Owner or perhaps someone on the actual Development Team take on the ScrumMaster role in addition to their delivery duties. As we lead organizations through an agile journey, we must instill the importance of the roles to the organization (not just to the Scrum Team themselves).
My motto is that you have to have people working ON the organization, not IN it. Scrum prescribes that a ScrumMaster is a fully dedicated role in coaching the team and the organization. If we start splitting that capacity out to other roles, then the organization runs the risk of progressing very slowly (or worse, not at all). ScrumMasters tend to help the teams mature in the first stages, but should be setting their sites on the organization as well. Once our teams mature to a state when they are "professional", the ScrumMaster can spend more time on the organization and cultivating a culture of learning and innovation for the team to thrive.
Take a look at your Scrum implementation. Do you have people working ON the organization or simply IN it. The more and more we dilute the ScrumMaster role, the less we will achieve true agility within the organization. There will be problems, our organization must be strong enough to endure and sustain the changes that occur over time. This is about building and incubating a culture for the teams to thrive.
