Being the Bulldog

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.