RE: [scrumdevelopment] How "present" should the ScrumMaster be?
- On Wed, 2003-11-12 at 22:29, Deb wrote:
> > Is the ScrumMaster to lead? Or is the "self
> > organising" team to find its own leader? Is it normal for one
> > development team member to have large portions of the Sprint
> > dedicated to coaching? (kind of like being a mother - eyes in the
> > back of the head, breaking up spats, catching bad habits in the bud,
> > reminding of good practices, encouraging, instilling Agile values,
> > etc.) Several of us who have played this role have commiserated on
> > the fact that it's foolhardy to plan any features for the team's
> > coach.
On Thu, 2003-11-13 at 04:01, Mike Beedle wrote:
> The right leadership answer depends on your team:
> If you team has a majority of newbies and/or not very
> self-directed individuals you will need more leadership;
> but if the majority are experienced developers with
> strong self-direction you will need much less leadership.
> Remember the Scrum Master is "insurance". He/she ensures that
> the team is doing the "right thing", this means that sometimes
> he/she should leave the team alone _unless_ they need some help.
> Then she/he can:
> * challenge the team
> * question the team (e.g. you said yesterday you would be done
> with task X, is there something we can do to help? or
> * facilitate or get things for the team
> * give advice
> * give direction/take direction
> > Is this a role that dimishes as the team's process emerges, and as
> > the team becomes a more collective entity?
> In my opinion, it should always be present. From beginning to the
> end of the Sprint -- there is always something important for the
> Scrum Master to do!
Sorry for hopping on this thread so late...
For what its worth, this (Mike's view) ties in with my experience too. I
introduced Extreme Programming to the s/w team where I was the tech
lead. I was doing what amounts to a Scrum Master & coach role. The
situation I had seems similar to yours, Deb - the developers were not
very experienced or cross-pollinated.
I did assign myself features to code, like the others had. I made it a
priority to spend time communicating the overall design of the system to
the others (doing documentation), and as they absorbed that they were
able to contribute to it better. As we started each sprint I had us all
meet to strategize how the new features would be worked into the
existing code. It was a great motivator - I never met a developer who
didn't enjoy doing design. It also gave everyone a perspective on the
parts of the system they didn't know personally. For the inexperienced,
it let them see what considerations get tossed around as people work out
True, I also spent some time "firewalling" - shielding the team from
silly interference, go-fering, breaking up squabbles, getting tool
issues solved, etc. Keeping up with the pulse of the team is a good way
of expressing it.
As time went on, the team members became much more knowledgeable
designers and troubleshooters. They worked very smoothly together.
Everyone was focused on the whole system - never a thought to finish
"their" task at the expense of helping another developer. I was able to
do more developing and firewalling, and less coaching.
Sometimes I thought I'd be more effective if I didn't code features
myself since that takes so much time. Now I'm convinced that was a wrong
idea. On several occasions it looked to me like people were having too
much hassle over simple tasks, and I might have snapped at them if I
hadn't been close enough to the work itself to appreciate the
difficulty. IMHO it's absolutely vital to identify 100% with the team if
you're to lead successfully in a Scrum or XP situation.
- Nancy V.
<< Ask me about Embedded XP >>