|
This is a Agile coaching case study example
depicted with Scrum Authority Mapping. This is Part 3 in the
introduction
to Scrum Authority Maps. In this situation, the PO and the SM
are engaging is some very clear over-stepping of authority. Each
of them is taking up authorized tasks that belong the the team.
As a result the Team has no sense of control and is demoralized.
NOTE: If you are new to Scrum
Authority Maps, please see Part1
of Scrum Authority mapping.
Getting Oriented
Use these links if you are new to the concept
of Scrum Authority Mapping:
Scrum Authority Mapping Introduction
Scrum Authority Mapping Part 2
Red: depicts authority that
belongs to the Team, that the Team has ceded to others, or others
have taken
up. With Authority Maps, you want to 'get the red out'.
Yellow: depicts authority the team has ye
to to take up, that actually belongs to them
Green: depicts the authority
the team is granted per Scrum, and has actually taken up so far.
A healthy map has lots of green, very little yellow, and no red.
Labels depict who is doing
what. Labels are typically places over the red regions.
Abbreviations
This essay uses these abbreviations:
PB: Product Backlog
SB: Sprint backlog
SM: Scrum Master
PO: Product Owner
SP:Sprint Planning
DS:Daily Scrum
SD:Sprint Demo
SR: Sprint Retro
Analysis
Without knowing anything at all about the
deatils , you can derive the following immediately from this
map:
1. The PO is meddling with the SB, pulling
work from the PB into the SB using the SP meeting.
2. the PO is meddling in the Teams's job
of carving the user stories in the SB into tasks.
3. The SM is updating the BDC.
4. The Team is not blocked on the tasks depicted
in yellow, but for some reason they are slow to take up these
tasks fully. These tasks include supplying estimates, participating
the retro, doing the demo, delivering the increment, and executing
the Daily Scrum
The Story on this Team
This is an actualcase study from my Agile
coaching work in 2010. When I stepped in, the PO was literally
pulling the work from the PB to the SB during the SP meeting.
Also during this meeting, the PO would ask the Team for estimates.
There were no estimates on the PB in advance of the SP meeting.
The Team would be asked in public during the SP meeting to supply
estimates.
After the SP meeting was over, the Team would
convene to break up the user stories in the SB into tasks. These
tasks would be placed on index cards and taped to the wall beneath
the user story. A sticker indicating "not done" would be placed
on the task-card. When
this
was all set, the Team started working.
When a task was "done", it was not quite done-in-fact.
For most "done" tasks, the Team had to wait for the PO to check
it out during the Sprint. If
the
PO
thought
the task was done, she would place a 'done' sticker on the card.
There was an "Agile coach" who was helping
with this Team. The coach was there in an "embedded"
mode, literally functioning as the SM. One other fact is interesting
to note: as SM, this "Coach" would update the Burn-Down chart.
Primary Problems
Only the Team has authority to populate the
SB in Scrum, during the SP meeting. (Define the "WHAT"). Here
the PO is doing it "for" the Team.
Only the Team has authority to carve up the
stories into tasks. (Define the "HOW"). Here the PO is "helping"
with that. Further, the definition of done is subjective and
based on how the PO feels, as indicated by examining each task
and
declaring it done item-by-item in side the Sprint.
Only the Team is authorized to update the
BD chart. Here the SM is doing that "for" them. Add to this the
fact the person is SM mode is a "Coach". No one is learning the
SM role by watching and by doing; the 'Coach" owns the SM role.
That in itself is a HUGE problem, do you see why?
Add to this
the fact that the SM is doing a taks that ONLY the Team is
authorized to do, and you can see the level of distortion in
this Scrum
situation.
Secondary Problems
The BD chart for this Team was often a straight
diaginal line, like this:
Figure 1. Burn Down Chart Diagonal Shape.
This makes total sense when the Team is being
asked for estimates on demand at the Sprint Planning meeting.
They offer estimates that they are sure to be able to deliver
on, and then manage the BD chart throughout the Sprint. Normal
BD
charts are seldom in the shape of idealized diagonal lines. The
diagonal BD chart is a tip-off that somthing is up.
The Team is not doing all the tasks to the
full extent they are authorized. This is depicted in yellow and
the tasks that have this status are: supplying estimates, participating
the retro, doing the demo, delivering the increment, and executing
the Daily Scrum. These tasks are weakly taken up because the
Team has a very low level of perceived control. They are in fact
dominated by the SM and PO. The Daily Scrum for this Team was
also interesting since the PO attended it, and often interjected
with questions as Team members recited. As you might expect,
the individual team members often recited to the PO, rather than
to each other.In addition the PO often prompted teh next person
in sequence to recite, using non-verbals (eye contact) to signal
who was next.
Moral of the Story
Scrum authorizes specific tasks for the Team,
PO and SM. There is purposely almost no overlap for authorized
tasks by Role in Scrum. Sticking within these authority boundaries
is the hallmark of great Scrum. Here we have the SM and the PO
doing essential tasks that only the Team is authorized to do.
The result is a Team dominated by the PO and SM. This Team
is not strong in the aspects of their role. This makes total
sense since they have a very low level sense of control over
their work.
Moral of story: There are many ways to screw
up a good opportunity to do great Scrum. A competent Scrum Master
is a necessity, both for calling out problems and making sure
the Team is protected as they move to fully take up their tasks.
The Authority mapping technique provides a
powerful Agile information radiator that conveys the essentials
of authority dynamics by role, in a compact, information-rich
diagram.
Authority Map Diagrams are Available Now
You can download blank authority maps for
the Product Owner, Team and Scrum Master roles below, for use
in your own coaching and Scrum Mastering work.
Download: PDF
document containing Scrum Authority Maps for PO, SM, Team
Previous and Next Parts in this Series
Click here for the FIRST PART in this series
Links:
Reference: Boundary,
Authority, Role and Task: BART Analysis of Complex Systems
Download: PDF document
containing Scrum Authority Maps for PO, SM, Team
***
Date of note: 1/9/2011
Click here to examine MORE
AGILE NOTES like this
Click here to return to the Agile
Boston home page
Click here to return to the Agile
CT home page
About the Author
Dan Mezick: An expert on
teams and a trusted adviser to CxO-level executives worldwide,
Dan consults on enterprise-wide culture change, implementing
Scrum, and the often difficult adoption of authentic Lean principles. Learn
more about Dan Mezick here.
He creates and teaches specific, useful tools
and techniques for facilitating successful enterprise-wide adoption
of agile and Scrum. Dan’s articles on teams and organizational
dynamics appear on InfoQ.com, ScrumAlliance.org, and AgileJournal.com. Learn
more about Dan Mezick's agile writing here.
He's the organizer of the Agile
Boston user group and a 3-time presenter at Agile2007,
2008 and 2009, an invited speaker to the Scrum Gathering (Orlando)
in 2010 and a news
reporter for InfoQ.com
Reach Dan Mezick at:
dan.mezick [at] newtechusa [dotcom]
You can learn much more detail about
Dan via his Agile Coaching page here.
Click here to examine MORE
AGILE NOTES like this
|
Agile
Boston