Scrum Masters and Product Owners Together


The Scrum Team consists of a Product Owner, a Scrum Master, and the Development Team. It’s pretty obvious what the Development Team is doing. They’re mostly heads down analyzing, designing, building, testing, documenting and all the other related activities needed to make the product work. Simply, get the right people, communicate what you want, and get out of their way. It’s amazing what results you can get when you give a Development Team everything it needs to succeed! Exactly what the Product Owner and the Scrum Master are doing day after day while the Development Team is building stuff is often less clear.

The Scrum Guide™ tells us, “The Product Owner is responsible for maximizing the value of the product and the work of the Development Team…the sole person responsible for managing the Product Backlog.” That’s a great summary, but what exactly does that mean in action?

In addition, The Scrum Guide™ has a bulleted list of the Scrum Master’s service to the Product Owner”

The Scrum Master serves the Product Owner in several ways, including: 
* Finding techniques for effective Product Backlog management;
* Helping the Scrum Team understand the need for clear and concise Product Backlog items;
* Understanding product planning in an empirical environment;
* Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
* Understanding and practicing agility; and,
* Facilitating Scrum events as requested or needed.

This is a great list, but again, what does it mean in action? There is no simple answer for this question. Every situation is unique and requires a situationally appropriate response. The Product Owner and the Scrum Master need to figure it out for themselves. Luckily, they’re not in it alone. They are in it together — partners in solving this ever evolving problem.

Understanding this partnership, how it works as a multiplier, and avoiding the pitfalls of stepping outside the bounds of each role are critical to both Product Ownership and Scrum Mastery. We have found that this partnership gets off on the best footing when the Product Owner and the Scrum Master share the same experience in learning about Scrum. When a Scrum Team’s Product Owner and Scrum Master attend one of our classes together, they tend to have better traction and attain greater success in their use of Scrum to achieve their goals. This correlation is so significant that we’ve decided to introduce a new ticket type to enable them to attend the same class together at a special PARTNER price. No special code is required. Just choose ticket type “Scrum Master/Product Owner Partnership” when registering. 

Our current classes are listed here.

Organizational Change... Not!

organizational change not.jpg

What do you do if you happen to find yourself in a organization that is simply paying lip service to agile? First, don't despair. Organizations don't change overnight and it is highly unlikely that you as one person are going to change the organization. Don't feel bad about it. That's just the way it is. Second, don't lose faith. There are some things that you can do within your control to effect positive change:

  • Know your team's purpose. What value does your team create for your customer? What difference does this value creation make to your organizations bottom line? Don't know your team's purpose? Ask.
  • Be transparent. Let others know your team's goal and communicate what you're doing to help the team achieve the goal.
  • Ask for help when you need it. Your team is better when it works together.
  • Get real. If things aren't going according to your plan, fix your plan to deal with your current reality. The plan was built on what was, not what is. Whatever reality is, deal with it.
  • Be the change. We all have preferences, biases, and models of how we see the world. If any of these is not helping,  be willing to change yourself!

Who knows, with enough individuals making a positive difference, we might just get the organization to change as well.

Scrum Waves

The great wave off Kanagawa - Print at the Metropolitan Museum of Art

The great wave off Kanagawa - Print at the Metropolitan Museum of Art

I caught myself daydreaming about waves today.  What can I say, it's summertime and I have to admit that I've always been fascinated by waves, or more specifically, waves in water. It doesn't matter whether it's ripples on a pond, standing waves on a class 3 river, or rollers breaking in the surf at the beach — to me waves are mesmerizing, powerful, mysterious.

The next thing I knew, I was thinking about something Craig Larman said in a LeSS class that I attended earlier this year.

Most organizations rent Scrum rather than own it.
— Craig Larman

If you're wondering how I got from waves to Scrum and renting versus owning, it's a dream. Just stick with me. I'll explain.

Waves move through water, but are not made of water. When a wave passes, it is sort of like something happened to the water, but the water is not the wave. After the wave passes, the water hasn't changed. It's still the same water as it ever was. It is kind of like the water is renting the wave rather than owning it. It’s just a temporary thing that is just passing through.

Now if you happen to be at the beach bobbing up and down where the rollers begin their break and you decide to body surf a particularly big wave in to the shore, you might experience the thrill of the energy, speed, and dynamic nature of the wave. But after the wave has crashed on the beach and left you in its backwash, the wave is gone and the receding water is still just water. It is you, the body surfer, that is changed by the experience, not the water.

Now back to organizations renting Scrum rather than owning it. Organizations trying Scrum are often like water with Scrum simply a wave passing through. Waves come and they go. The people in the organization might get tossed and turned, but the organization stays the same. Scrum is seen as the fad that is the current wave. Soon, too, it will pass.

In my experience as a coach, Scrum works better when an organization acts like the body surfer, using Scrum as a never ending series of waves to effect positive change and having joy in the process.

Which would you rather your organization be — the water or the body surfer? Is your organization a renter or a buyer?

Magic Words, Jargon, and Gibberish

Does your Daily Scrum feel a bit like the movie Groundhog Day?

The idea for this post was sparked by a text this morning from one of my former students who I have anonymized below as Development Team Member (DTM):


Despite the subtext of humor, DTM is clearly frustrated. She has just endured an hour’s long ordeal of (mostly) gibberish. That much is clear. What is not so clear is whether the team has a plan for working together over the next 24 hours. Nor is it clear as to how the team is progressing in relation to their Sprint Goal and their forecasted increment.

Where was their Scrum Master? How did this happen?

Words lose their meaning

Agile, Scrum, Lean, Daily Scrum… these are just words. Good ideas lose their positive impact when the words we use to describe them and their underlying practices are not understood in the same way by all stakeholders. For example, while we may understand what we mean by “Daily Scrum”, it is unreasonable to expect someone unpracticed in the correct enactment of the Scrum framework to share this same understanding. Jargon is not a substitute for an effective conversation!

Unfortunately, there are probably more examples like the one above of “bad” Daily Scrums than there are of good ones. Attempts to become agile through “magic” meetings with “magic” incantations such as “What did you do yesterday…?” are ineffective without a keen understanding of the why behind the question and the expected outcome of the meeting. If we can’t get a Daily Scrum right, what hope do we have to change the way we engage with our customers?

On a positive note

In the text exchange above, DTM has an idea as to how to improve the meeting. The “ball” she suggests bringing next time will serve as a talking stick to support her team’s agreed upon “one speaker” team norm at the Daily Scrum. Another idea DTM’s team might consider is a visible timer to serve as a reminder that the Daily Scrum is only part of the day’s “work”. (Scrum reinforces this idea through its rule limiting the Daily Scrum to a 15 minute time-box).

Most important, DTM’s insight for a way to improve the team’s way of working together is in the spirit of Agile. The authors of the “Manifesto for Agile Software Development” had in mind a sense of adaptability grounded in learning. DTM’s frustrating experience in today’s Daily Scrum is learning that will lead to the type of adaptation that the authors intended — and that is an outcome that transcends magic words, jargon, and gibberish.

Lift Off: Start and Sustain Successful Agile Teams

The newly released second edition of Liftoff is bigger and better than ever! With a larger format and improved layout, Diana Larsen and Ainsley Nies' acclaimed book is chock full of great ideas on how to start your agile team on the road to success and how to sustain them on their journey. I may be biased as contributor to the book, but if you're looking to get a team going or need to get an existing team out of the ditch, this book is the one to read!