Scrum is all about rhythms. Teams that are successful with Scrum establish a sustainable cadence for collaborating with each other. Each of the sprint ceremonies help us move toward our goal, and remind us what’s coming next.
Scrum is pretty straightforward about how to establish the right rhythms for the team, but organizing your work as a product owner is a little murkier. You know that sprint planning happens every two weeks, but what do you need to do to prepare? Your team does backlog refinement for an hour every week, but how far in advance do you need to start working on stories to make that meeting worthwhile?
In this article, I’ll share the rhythms that have worked well for me as a product owner. The Scrum ceremonies act as a trigger – a reminder that there’s something I need to do. I’ll organize this article by those triggers, and we’ll work our way backward to see what we need to do to prepare.
I attended the Mile High Agile conference in April. One of the keynotes was Michael Feathers. He did something interesting in the opening moments of his presentation.
https://www.youtube.com/watch?v=3AMzRAjA0-o
First, he asked how many non-coders there were in the audience. And about 80% of the group raised their hands. MHA was very well attended with approximately 850 folks – so that manes about 600 folks raised their hands.
The second thing he did was show us some code on the screen. And he asked how many folks were comfortable with it. For example, showing it (code) in a sprint review. I think there were even more folks that raised their hands.
For years and years, I’ve been talking about the importance of Sprint Goals in the fabric of Scrum team execution. They:
- Help to guide the focus and conversations at the daily standup and the team’s daily activity;
- Help to focus the team’s sprint planning towards an outcome;
- Help to identify the purpose and focus of the sprint demo;
- Help the Product Owner and the team in making sprint content trade-offs if the run into difficulties;
- Ultimately help the team define what “success looks like” for each and every sprint.
Given that definition, my clients usually start looking at Sprint Goals in a different way. I see them as being very powerful mechanisms for focusing the team’s efforts and I hope you start to as well.
I stumbled on a blog by someone I hadn’t heard before. His name is Tanner Wortham and the blog is Spikes & Stories.
Here’s the link to the post: http://www.spikesandstories.com/qualities-of-great-agile-coaches/
In it Tanner explores qualities of great agile coaches with a theme of their biases:
- Bias towards learning
- Bias towards action
- Bias towards innocence
- Bias towards honesty
- Bias towards silence
- Bias towards the team
I loved the premise of the post and feel inspired to extend it a bit. So adding a few additional biases to the mix.
When I first started my agile journey, there was a small set of certifications. The Scrum Alliance was the “lead dog” in the effort. Around 2003-2004, there was only the CSM, CSPO, and CST certifications. Life was quite simple then.
Over the years, I believe folks started to get the sense that there was “money to be made” in this area. Lots of money. So certifications began to “pop up” more and more.
Much of this certification frenzy bothers me because it flies in the face of most of the agile principles. In fact, I’ve found that the money can corrupt even the best of agile trainers and coaches. But that’s not the point of this post.
My curiosity got the better of me and I wanted to see just how many certifications I could find. So here it goes...
Until they realize that:
They have to sometimes say NO to some stakeholders;
They have to make decisions; short term vs. long term; tactical vs. strategic; now vs. later;
They have to peer into the future and anticipate customer needs;
They have to aggregate opinions from multiple, sometimes very powerful and unique, voices;
They have to trust their teams;
I was in a Backlog Refinement meeting the other day and you would have thought I was in divorce court where the parties were negotiating (fighting for) everything.
Each time the team asked clarifying questions around a user story, the Product Owner would begrudgingly answer. It felt like they thought they were wasting time trying to explore the story.
It was clear that what he really wanted was…an estimate.
So the team felt the pressure and stopped asking question. Instead they went immediately into Planning Poker for each story. And as you might expect, the estimates were sort of…all over the place.
Last year I scheduled a Product Ownership class that was entitled: Scrum Product Ownership 2.0. The description alluded to more advanced topics and I worked hard to weave them into the course materials and my plans.
Folks seemed to be interested in more advanced topics and I was trying to fill that need in the agile market – beyond the pervasive basic certification courses.
But something interesting happened when I delivered the class. I had three primary discoveries:
- Everyone in the class was clearly struggling with more basic skills and tactics;
- As I tried to convey more advanced topics, I realized that they really weren’t. Instead, they were based on doing the basics…well;
- And finally, the class was looking for silver bullets. That is, they wanted advanced topics that would solve all of their challenges.
Often agile organizations take the position that the Managers, Leaders, or the Scrum Masters are responsible for keeping the team focused and energized towards their work. And yes, these roles can play a part in keeping the teams passion and energy focused towards doing great work.
But I’ve found that another role can really make a difference here as well. One that is rarely suggested for this sort of nuance. That role is the Product Owner.
To make my point, I’d like to share a dozen “opportunities” for a Scrum Product Owner to make a difference within their teams. Is the list exhaustive? Probably not. But that’s not the intent. The intent is to get Product Owners thinking outside the role of backlogs, user stories, and delivery. And instead thinking about ways where they can play a key role in the engagement, joy, energy, passion, focus, and results of their teams.
Yes, I just added another large responsibility to an already overwhelming role. Sorry about that.
I read a wonderful article the other day that surrounded some specific techniques for portfolio management.
Here’s a link to the article: http://www.infoq.com/articles/visual-portfolio-management
I immediately thought of the SAFe guidance for portfolios and just really enjoyed the simplicity and practicality of the approaches in the article.
For example, the article diagram illustrates visually how an organization is moving portfolio items from Idea…to Live or “Cash”. Clearly it’s a Kanban approach, but I don’t believe there is exhaustive analysis (business cases, etc.) for each idea. The board simply radiates the portfolio and each item moves forward based on (1) it’s on merit and (2) the organization determining that it has value.
