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.
So please consider trying to…
1. Listen to their ideas: Try to stay open minded to every idea from your team. Even if you’re initial inclination is that it will cost too much or you won’t have the time for it or it has no value. Listen first and sleep on the idea. Ask exploratory questions and seek first to understand it before skipping over it.
Your teams will sense your willingness to listen and become your partner in brainstorming ideas for your products.
2. Throw them a bone: I often find that mature agile or Scrum teams find ways to get more done in a sprint than they originally planned. When this happens, they often ask for more, which I often refer to as “stretching”. Product Owners often simply give the team the next story or two from the backlog to work on. But it is your option to give them something else to work on, for example bug fixes, refactoring out some technical debt, spiking a future story, or simply working on something that they’ve wanted to resolve for a few sprints. All of the latter fall into the category of “throwing the team a bone” when it comes to work that is outside the normal “feature focus”.
Mixing things up with teams and rewarding them by allowing them to “pick” some of their stretch items is a sure fire way to increase their motivation.
3. Allow them to refactor: Think of your car or your home. When they’re new, they need little in the way of maintenance. But as they age, they start to break down. You can either invest in preventative maintenance or wait until things explode – it’s up to you. Software is the same. So as your system ages, create space for your team to refactor it. In fact, encourage, ask about, and even demand refactoring as a part of your backlogs and work focus.
Crusty, old code is challenging and frustrating to extend. Try to give your teams as much refactoring space as possible. And of course, make sure it’s in high priority/value areas.
4. Allow them to fix bugs: Most teams really care about the defects associated with their work. If you allow the defect list to grow too large, you’re sending a message that you as a Product Owner and business leader do not care about product quality. That’s a terrible position for your customers and it sends a dangerous message to your teams. Foster an environment where you encourage team members to weigh in on and repair defects, both from a reactive and preventative perspective.
The more you weave bug fixes into the themes and goals of your sprints the happier your customers will be and the more quality focused your team will become.
5. Ask them about “done” – show them you care: I can’t tell you how often I see teams operating with no or very weak Definition of Done criteria. It just saddens me. Equally problematic are those teams that have it, but they don’t really pay attention to it. It’s just another checklist to them. Please don’t fall into these traps. As a Product Owner, I want you to understand, contribute to, support, and talk about Done-ness all of the time.
Remember, done-ness is your “contract” with your team. It assures that you are getting what you paid for in each user story. So treat it accordingly and insist on getting everything you paid for.
6. Give them a stage: I think the Sprint Demo or Review is incredibly important. It’s the culmination of the teams hard work every sprint. It’s an opportunity for each and every team member to get their moment “on stage” to demonstrate their work. To show off a bit. And to get feedback. That is, IF you give them the opportunity and set the stage for their success.
There is nothing more motivating than showing your work to your stakeholders and senior leaders and getting positive feedback on how you are contributing to the bottom line. But that means YOU have to get the right people in the demo for your team!
7. Trust them: I’m not saying you don’t trust your team, but, you probably don’t. What do you say when the team tells you that what you perceive to be a 5 points story will take 30 points? Or that 25 of those 30 points are intended for refactoring, because that’s just the responsible thing to do? And what if you have a technical background, and have an idea for a design that, while fragile, will get the feature out in 3 points? In all of these cases, you need to accept your role, listen to the team, and trust them. Period!
And remember that trust is a hard thing to fake or pretend. Your team will see right through you. You need to effectively fake it until you make it here. And never, ever say – I told you so.
8. Don’t push too hard: This is a hard one. Usually the Product Owner role is getting pressure from all sides. Pressure to do more with less. Pressure to hit some arbitrary date. And pressure to deliver as many features as possible. It’s an unfair situation and many pass that pressure “down” to their teams. Don’t do that. If you do, even unintentionally, then your teams will make compromises in quality. It also has a tendency to impact the morale of your team as they become slaves to the schedule and won’t bring up ideas to improve or innovate within your products.
As a team member you can “share” the situational pressure with your team. But then talk about the teams balanced response to it. Making sure that short-term compromises in quality are not being made.
9. Partner with your Scrum Master: I always try to emphasize to ScrumMasters and Product Owners that they have a “leadership” role within their Scrum teams. Since the two roles are so different, partnering around “your team” and “increasing their performance” should expose much different ideas and perspectives. Yet, your goals are the same. If you read the Scrum Guide, you see references to this partnership.
Alignment, collaboration, and mutual support across these two roles can be a difference maker for the team. And remember, it needs to be a Win-Win relationship.
10. Become an excellent Backlog Refiner: Many feel that “planning” isn’t a focus within agile teams. I disagree. It’s simply different. And it revolves around the Product Backlog. The backlog is so much more than a list of features. Backlog refinement encompasses: risk management, architecture, design, implementation strategy, work planning, story decomposition, story writing, estimation, and overall planning. Even if the team resists frequent refinement sessions, persevere through it. Why? Because it all focuses towards planning where you are going.
Treat your backlogs like the incredibly broad and important planning artifacts they are. Get your entire team engaged in them. And refine them (look ahead) on a committed and regular basis. In other words: Begin with the End in Mind.
11. Share your vision: There is so much being written today about how important knowing the WHY behind their work is to teams. One of the key voices in that movement is Simon Sinek. As your teams Product Owner, you owe them a vision and mission. You need to effectively communicate WHY you are asking them to do the work and WHY it makes a difference to your customers. And please invite others in as part of this vision-setting, if you need the help.
Teams are generally energized in the beginning of a project when someone explains to them the WHY behind asking them to deliver a set of features or a project. Don’t start sprinting until you explain…WHY?
12. Remember that YOU are part of the team! I like wrapping up the list this way. Not that long ago I overheard a Product Owner whining about how their team was letting them down and not delivering sufficient features to appease their customers. I remember thinking to myself that he was not only throwing his team under the bus, but he was throwing himself there too. Never forget that you serve your team and that you are a part of the team.
Your team is like your family. It may be hard at times, but they will always be your family and you need to “have each other’s backs”. Be loyal, be supportive, be truthful, simply be there for your teams.
Wrapping Up
Try to remember that your first loyalty should be towards your team. That only by collaborating with, guiding, and serving them do you deliver business value.
And everything should focus on the team, not you. Oh and, you’re a member of the team.
Stay agile my friends!
Bob.