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.

Engaging the reluctant Product Owner

Product Owners are what drives a team.  They are the motivation and the catalyst behind any successful agile team.  For many struggling agile teams the biggest bang for the buck in improvement is an engaged product owner.  But how do you take a reluctant, absent product expert and convert them into a successful product owner?  You train them.  And how do you motivate these Product Owners In Training to engage?  You make it worth their while.


Product Owners, like all people, only repeat behavior that works for them.  Therefore, our job as agile team members and scrum masters is to provide that value to keep the PO coming back for more.  We provide that value through early and repetitive visibiltiy into what we are building, and the ability to easily change course when what we are building does not match their ever growing insight into what should be built.

A core requirement of a good product owner is to have the industry domain experience and the ability to fashion a vision of solving buisness needs within that domain.  However, PO's cannot be expected to nail this vision right out of the box; they need input to help aid with constant course correction to make that initial vision into a usable solution.  Think of the old artillery capabilities where an initial shot was fired, response was fed back to the artillery captain regarding adjustments, another shot was fired, and the process repeated until they were on target.  Modern systems rely on specific coordinates and GPS aids to directly target the first time, but PO's don't have a built in SatNav receiver.  They need this fire and learn feedback to adjust their vision.  Providing this feedback, and teaching them how to use it, is part of the value return for a PO.

And this feedback comes from working software.  We couldn't with honest confidence tell the artillery captain before the shot is fired "Your shot will land right at these coordinates, so you need to adjust accordingly".  In the same mode we cannot provide the needed feedback on product direction without those early shots given in the form of product demo's.  Invest in making those demo sessions provide that needed insight, and with a little encouragement your product owner will become an eager fan and no longer find reasons to skip your demo's.  Continue this process throughout the sprint and you are well on the way to building your own super PO.

Inspect and Adapt

Think about one of our most useful inventions of all time; the wheel.  Do you think that first caveman sat down and thought through all of the facets of building a wheel, and got it right the first time?  No, he most likely had a need, and set about to fill that need through trial and error.  His first attempt was almost certainly very crude and didn’t work well, but he kept iterating through it until he had something that worked.  If he had sat down and scratched out his design in the sand and said “Ugg, that’s what I need” and built exactly that, we would still be using our feet to get around.  Instead, he started building with what he knew at the time, and used that knowledge to improve the next version, and the next, until he had something that worked.

In the same way, we need to be willing to start with what we know, and understand that we will learn along the way.  Hanging on to the need to understand exactly what will happen in the future just doesn’t work.  Customers change their mind, product owners learn more and adapt (at least, the good ones do), and designs need to change along with them.  Also, if we really could just write TDD”s and know that’s what we want, why have developers?  We could just plug our designs into code generators and push a button. 

As developers of software, we need to be able to do a little work, inspect that work, learn from it, and then do a little more.  That’s how our friend the caveman did it.

‘Estimating Session’ is a misnomer

I think the agile community might do itself a favor by renaming these to ‘Understanding Sessions’.

People new to Agile, especially coming from the waterfall/traditional PM role, struggle with the concept of agile estimation sessions.  How can slotting stories into piles of like size be of any benefit?  I need real numbers, not these Fibonacci things!  And then, inevitably, comes the dreaded question; “how many hours is a 5 point story?”.

Let’s think about the advantages of an estimation session.  Sure, we get story points associated to a story, which helps with release and sprint planning, but what’s the real benefit?  Think about how you get to a consensus on a story estimation, it requires discussion on the story sufficient to gain a group understanding, it requires compromise on what the story scope is (which helps further define the story), and it requires all aspects of the completion of the story to be involved (dev, BA’s, QA, deployment, etc).  A successful estimation session ends with the participants gaining further understanding of what is needed.

However, estimation sessions are not planning sessions, and this is where a lot of PM/Waterfall folks get frustrated.  Do we know exactly how we are going to implement this?  Do we have a detailed task list that needs completing?  Do we even have a clear picture yet on how we are going to test this?  No to all.  What we do have is an early agreement on our short term direction based on a ‘slotting’ of these stories into like piles.  It also presents an opportunity for a new team to start to gel around the work they are about to undertake.

I know there are many in the agile community that are starting to question the need for estimations as agile practices continue to mature.  I think they still have an invaluable place as Understanding Sessions, and will remain on my list of preferred practices for the foreseeable future.