One of the most
important aspects of a good scrum master is to be diligent, almost to the point
of stubbornness, in constantly trying to improve the team. A never give up attitude, and the ability to
always strive to make things better are essential to this role.
Have you ever played tug
of war with a dog and his chew toy? Ever
held the slobbery end of a stick, with the other end firmly planted in his
jaws, and looked into that completely focused and determined face? Yes, it’s a game, but that dog is not going
to back down until he gets the toy. If
you manage to wrest it away from him he’ll sit and stare at you for hours until
you start the game again, and then it’s back to that dogged (pun intended)
determination. That’s the look I like to
see in a scrum master (minus the slobbering and barred teeth).
And, so what does a
scrum master have to be so diligent about?
Continuous improvement. Never
giving up on trying to make the team more efficient. Constantly looking for ways to eliminate waste
in the process. A laser sharp focus on
the goal of the team, delivering product that the customer needs.
Without this
determination, it becomes far too easy for a scrum master to allow the team to
accept “the way things are” as, well, the way things are. We, as scrum masters, cannot allow our teams
to fall into this trap. Because the particular
segment of the industry I work in now is challenging to find the end customer value
in everything we do, we sometimes find ourselves falling victim to the mindset
of “lets’ just get this set of tasks done, and then we can start doing it right”.
Stories that have no clear
customer value are a common issue we face.
What is the difference between stating “Run performance testing” and “Ensure
performance meets customer needs”? It’s
a lot more than semantics. How do you
retain customer value focus when your goal is to run the performance tests you
already have? But, when you state your
goal is to meet customer performance needs, the goal opens up to all the
tangents that need to be explored. What
are the customer’s performance needs?
Have they changed since the last time we ran these? Are there ways to improve how we are gauging our
performance to meet these needs? (Admittedly, the above is not a good example
of a story title, but you get the picture).
Stories that have no definition
of done are the antithesis of agile development, but the inclusion of clearly
stated and well thought out acceptance criteria are the backbone of any good
user story. How can we ever succeed if
we don’t know what success looks like? Scrum
masters that allow a team to accept stories that do not have a good acceptance
criteria basis are allowing that team to lose focus of the goal. Scrum masters that protect their team by
guiding them to requesting (demanding) clear acceptance criteria are the
equivalent of the dog saying “that toy is mine, and I will have it”. Note that I am not saying that acceptance
criteria need to be complete before taking on a story, as these criteria should
be allowed to grow and clarify as more is learned through the ongoing
communication during a sprint, but there is a significant difference between
the PO stating “I will test to confirm it meets the story” and “Verify I can
log in using a valid username/password, verify I can …”
In our area we struggle
to find product owners that take ownership of the product backlog. This is generally due to two specific deficiencies;
lack of training and understanding of the role of a product owner, and lack of
time for the PO to participate and take on that ownership. But the dog that wants to keep playing finds
a way to keep the game going. Sinking
his teeth in my leg to get my attention will not keep the game going, but that slobbery
chew toy rubbed against my leg will get my attention. Done the right way, soon I’m up tossing the
toy for the dog, and not even caring that my beer is getting cold. As a scrum master, our job to keep that game
going, to show the value to the PO such that they realize what is important to
the project (building and maintaining the backlog, growing the product vision) and
what can be minimized (maybe all those product status meetings?)
In short, scrum masters
have to be the shining examples. We have to be above these issues and realities
of the here, we have to constantly hold the teams to a higher standard. The
people I work with are aware of my habit of talking about our process as it
should be, rather than how it is now. That is on purpose. I don't
want any of the very talented people I work with to get complacent, to accept
the way it works now as the way it has to be.
We need to keep our eyes
on this end goal and constantly ask "Is what I'm doing moving us
towards that goal?" Be the dog that never tires of the game.
