The debate as to whether a ScrumMaster is a full-time or part-time role in an Agile teams has created a lot of discussion in the community in recent months.
At the Scrum Alliance Global Gathering: London 2011, Paul Goddard led a session entitled "ScrumMaster - role or job?" where he shared his research:
75% of ScrumMasters dedicate less than half of their time to being a ScrumMaster for their current team.
45% of ScrumMasters support 2 or more different Scrum teams.
88% of ScrumMasters take on additional responsibilities beyond that of a ScrumMaster.
This session resulted in the creation of a ScrumMaster Manifesto. The opening statement makes a clear statement where the authors stand on the role:
We believe the ScrumMaster is a full-time position for one person on one Scrum team
The manifesto continues to list twelve ScrumMaster pocket principles:
1. Dedicated Delivery Improver
2. Foster Continuous Improvement
3. Help Continuous Improvement
4. Empower Coach Deliver
5. Nurtures The Team
6. Transparent Team Helper
7. Commitment To Excellence
8. Empathetic Evangelistic Guide
9. Resistant Persistent Dedicated
10. Help The Team
11. Awareness Then Improvement
12. Agile Driving Force
Paul Goddard explained on his Agilify blog the reasons behind drafting the manifesto:
...I noticed a trend in the training classes I was running and when I was coaching new ScrumMasters. When I asked the question, “Is the ScrumMaster a full-time position on the Scrum team?” the vast majority of people would answer “No.” My concern was that those ScrumMasters could already be compromising their teams (and organizations) chances of truly embracing Scrum, by not seeing the ScrumMaster as a dedicated person on the Scrum team. This is a trend that continued to grow over time and encouraged me to submit a session on this topic...
Jeff Sutherland, co-creator of Scrum stated the following in relation to ScrumMaster in his Scrum Handbook written in 2010:
Since Scrum makes visible many impediments and threats to the team’s and Product Owner’s effectiveness, it is important to have an engaged ScrumMaster working energetically to help resolve those
issues... Scrum teams should have a dedicated full-time ScrumMaster, although a smaller team might have a team member play this role (carrying a lighter load of regular work when they do so).
ln a recent discussion on the scrumdevelopment Yahoo! group, Jeff went on to confirm that the ScrumMaster should be a full-time role, however they can pull tasks from the backlog:
The ScrumMaster (or any other team member) does not commit to specific backlog items. The team as a whole forecasts that they will get it done. When the ScrumMaster has time he pulls from the sprint backlog. For the first ScrumMaster, John Scumniotales, this was 80% of the time by design. As his manager and Chief Engineer I was offloading all his impediments. In my last company the rule was that in any daily meeting if the team sees the ScrumMaster is not spending enough time on impediments, the team takes the ScrumMaster's work away from him or her.
John Piekos on his Agile Making Progress blog shared his learnings on the transition from waterfall to Scrum in his organization:
Though we “took the training” and “read the literature” which repeatedly said the roles of ScrumMaster and Product Owner were full time jobs, we weren’t true believers. Our “muscle memory” way of working had everyone juggling multiple roles and responsibilities, it was the way we were used to working. During the course of our Agile Pilot projects, however, we got convinced pretty quickly that Scrum roles could not be part-time. Scrum is more intensive than waterfall development.
Marcel Baumann in a recent blog post has an slightly alternate view on the role when dealing with teams that are more experienced.
I agree with the Manifesto authors that Scrum Master role is a fulltime job when working with a new Scrum team and team members new to the Agile and Scrum way of working. But I am convinced that a Scrum Master can support multiple experienced Scrum teams.
Wayne Grant has a differering viewpoint from a software developer perspective:
Ideally I think that the Scrum Master should spend most of their time being a Scrum Master. However, my own experience shows me that I am a more efficient Scrum Master if I do the same work as the team so that I share the same experiences as them. This doesn’t need to be a large amount of development work and may even take the form of the Scrum Master pairing with team members.
Lasse Koskela concisely sums up the options:
We need to have full-time Scrum Masters because we need them to be good at what they do and good Scrum Masters help increase our productivity. At the same time, we need to have part-time Scrum Masters because their technical contribution increases our productivity.
It is clear that there are misunderstandings about the ScrumMaster role from those new to Agile and Scrum and division amongst the existing commmunity. Should a ScrumMaster be a full-time role or should it depend on the experience of the team?
Community comments
I'm having trouble seeing what the disagreement is...
by Mark Levison,
Re: I'm having trouble seeing what the disagreement is...
by Elliot Holar,
Re: I'm having trouble seeing what the disagreement is...
by Mark Levison,
Re: I'm having trouble seeing what the disagreement is...
by Fredrik Vestin,
It is a half bell curve
by Renee Troughton,
Re: It is a half bell curve
by Shane Hastie,
Re: It is a half bell curve
by Jim vanEttinger,
ScrumMaster Manifesto
by Badri N Srinivasan,
Re: ScrumMaster Manifesto
by Craig Smith,
I'm having trouble seeing what the disagreement is...
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
...The consensus is that the ScrumMaster is a full time role. Some ScrumMasters like to keep a hand in the game and continue coding. As long as they focus first and foremost on the needs of their team this seems to a be non-issue. The real impediment is when an organization declares it will create a one ScrumMaster to handle 2,3 and even 4 teams. They tend to become a Scrum Administrator not a ScrumMaster. Even after taking a some form of training there are so many misconceptions about the role of the ScrumMaster. I think we need to do a better job remind graduates of our courses that 2 days is starting point and that they need to keep learning.
My recommended reading list: agilepainrelief.com/notesfromatooluser/2011/08/...
In addition to solve just this sort of problem recently I've started writing a series of posts, Scrum Master Tales: agilepainrelief.com/notesfromatooluser/category... - a series of Stories about the playing the role of a ScrumMaster.
Cheers
Mark Levison
Agile Pain Relief Consulting
Re: I'm having trouble seeing what the disagreement is...
by Elliot Holar,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, but...
How many talented and aspiring engineers want to see their skills atrophy in order to become full-time scrum-masters?
And if it's not the engineers taking these roles, then what talent pool should we be recruiting from? And how do they stay on top of the latest engineering practices and techniques if they can't be at least partially hands-on?
Are we really trying to create a dedicated career path for scrum-masters?
Moreover, are there truly one-size-fits-all answers to issues like these? When it comes to process, I've always found that the right answer is situational, i.e. it depends on the nature of the teams, the projects, and the organization.
What happened to scrum and agile being a loose set of guidelines tailored on adoption to best meet the needs of the adopters?
Cheers,
Elliot Holar
Senior Director of Engineering, SoftwareAG USA
Re: I'm having trouble seeing what the disagreement is...
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Eliot - it took me a while to place your name. Its good to hear from you again (I taught an intro Agile for SoftwareAG a few years ago). I will attempt a quick reply:
It boils down to one simple point: Those of us who spend a lot of time in the field with organizations that want to adopt Scrum find they're more successful if they have a full time ScrumMaster. You may not choose to adopt that practice and that's your choice, but we find someone focused on the role helps their team move faster.
Cheers
Mark Levison
Agile Pain Relief Consulting
Re: I'm having trouble seeing what the disagreement is...
by Fredrik Vestin,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree Elliot. People, organizations and projects are vastly different and I can't see how there could ever be a one-size-fits-all solution for all. If you were to take 10 organizations that have transformed to Scrum for I think you wold find that they all have 10 different ways of implementing it and all may be successful. For one, I believe the level of maturity in the Scrum team is a factor to consider. A new team will likely need a lot more guidance to the process compared to an experienced team that may be able to identify and remove impediments themselves and find and adopt new skills. etc.
/Fredrik
It is a half bell curve
by Renee Troughton,
Your message is awaiting moderation. Thank you for participating in the discussion.
As a general rule of thumb (because everything these days boils down to 'it depends') I agree with Marcel's perspective but would refine it further. In most instances the time taken for a SM on a single team, assuming that the team has >50% of individuals unfamiliar with Agile, is like a half bell curve. It is heavy at 100% for the first few iterations until the team has stabilized into a rhythm of basic practice understanding (over induced change chaos). At that point in time it slowly begins to decrease and then the pace of time spent rapidly reduces down to a threshold of a certain percent. This percent is not 0, but somewhere in the range of 30-50%, dependent on the environment of the project.
What I think is interesting is that there was a lack of clarification in the SM manifesto about what a SM should not do. "Transparent team helper" and "help the team" are so broad in their definition that it could mean the SM is left doing monotonous, boring administration activities that the team otherwise does not want to do.
Re: It is a half bell curve
by Shane Hastie,
Your message is awaiting moderation. Thank you for participating in the discussion.
Maybe not a full-time role, but definitely a full-time team member.
As Renee says the level of engagement of the scrummaster activities varies as the team matures, but it is important that whoever takes the scrummaster role is a full-time member of the team so they are constantly present and able to see first-hand what's happening.
Allocation of tasks within the team should take into account the demands on the scrummaster, so in early iterations they will probably have very little time for other work and as the team settles into a rhythm they will be able to take on other tasks as well.
Re: It is a half bell curve
by Jim vanEttinger,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with Renee's point on lack of clarification on the SM manifesto. We need principles that support the manifesto like we have in the Agile manifesto. The SM Manifesto as stated is ambiguous and does not communicate the essentials to enable practitioners to adapt while still complying.
Jim vanEttinger
ProKarma Inc.
ScrumMaster Manifesto
by Badri N Srinivasan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Craig,
The manifesto could re-look at its principles which does not list Servant Leadership which I feel is an important attribute of a Scrum Master. Principle No. 5 or No. 8 could indirectly link to this attribute. However, the usage of the term "Servant Leadership" connotes a deeper focus on team facilitation and which could further strengthen the ScrumMaster Manifesto.....
Cheers,
Badri N Srinivasan
Agile Coach
Valtech India
Re: ScrumMaster Manifesto
by Craig Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree, and would hope that this document gets updated rather than becoming a static artefact.