Re: Scrum vs "traditional spiral development"
- Tobias Mayer wrote:
> On the subject of control, I actually find the term 'ScrumMaster' aI think of a ScrumMaster as the "Master of Scrum" more than
> little misleading (potentially confusing), as the role is more of a
> trusted servant than a master. I guess 'master' refers here to
> 'mastery', but in a traditional control culture the term will be (and
> is) easily misunderstood. But that is another thread altogether...
the "Master of the Team," as you mention. They are the
facilitator, the coach and the process conscience of the
I agree it's easy for the role of ScrumMaster to become a
management role. Many of the organizations that I've helped
transition to Scrum assign a project manager or administrative
manager to the ScrumMaster role. Or a manager that is involved
with the adoption effort sees the ScrumMaster as a power role
and grabs it.
Unfortunately managers often take on the role of ScrumMaster
from a management perspective, without the understanding that
they need to be an active facilitator and really learn Scrum
to pull it off, and that it's more than a part-time thing. I
find that helping a team to have an effective ScrumMaster is
one of the bigger challenges of coaching an adoption effort.
While I'm at it, I wrote:
> From the larger organizations I've helped transition to Scrum,I didn't mean to imply here that each Scrum team has its own
> I've found that we need to create a structure that supports
> the Scrum teams. Each Scrum team has a manager (perhaps the
> ScrumMaster, although that can cause a conflict between the
> coaching and manager roles). If we have a bunch of Scrum
> teams, maybe we build a management hierarchy above that.
administrative manager. Manager is not a role in Scrum. Each
team needs a resource to go to when it needs those kinds of
organizational things that an administrative manager usually
handles, such as hiring a new team member, getting 21" LCD
monitors and Aeron chairs for their new pairing stations ;-),
dealing with health care plans, and so on.
In a perfect world, the ScrumMaster(s) have the resources
needed to facilitate all these kinds of things. But in most
cases, I find organizations want someone appointed with some
control over budgets and personnel and such, and it's usually
not the ScrumMaster (except when a manager jumps into the role
as I mention above). In my experiences, there is often an
administrative manager of some sorts that handles this stuff
for one or more Scrum teams.
It's also hard for an organization to move towards a shared
accountability model. Ideally, the entire Scrum team (and
the folks they directly rely on) are held mutually accountable
for delivering product with value. But it's a major shift
for many to deal with that, so they still ask "Well, *who* is
*the person* responsible for the Scrum team?" I think it's a
bad idea to put that on the ScrumMaster, although some do.
Some place a manager in there to be the accountability person
for the Scrum team. IMHO, both of these approaches can lead
to dysfunction, because then the ScrumMaster or manager feels
the need to exert control to mitigate the risk of their
individual accountability. A slippery slope...
Paul Hodgetts -- CEO, Principal Consultant
Agile Logic -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML