Product Owner: Beyond the Scrum Guide

The Scrum Guide is like the google map to Scrum, but it’s not a detailed roles and responsibilities document.  If we want to “zoom in” on “What specifically does the Product Owner  do?”, we aren’t going to get many results.  There is purposefully no prescription on “how”  a developer works, how a tester works, or how the Product Owner (PO) works, etc.; however, the PO is critical to the success of the product and the business.  As organizations adopt Scrum, the PO role is often overlooked and can cause frustrations unless the whole Scrum team (including the PO) and the organization have a more in-depth understanding of Product Ownership.

Here are my top three  activities that Product Owners commonly do, and how, that can either shape the success or failure of a product:

Top 3 PO Activities

1. Grow the Vision.  Self-organizing Scrum teams will build high quality, working products.  The vision laid out by the PO determines whether or not they are building anything of value.  This involves many different tasks and can be done in many different ways.  To be successful at these vision-related tasks, a PO has to both “grow” it and “show” it:

  • Grow it:  The PO has to be comfortable starting a project with only the big picture.  Then work to iteratively define and grow the vision by adding more and more concrete concepts, artifacts, and details.  All the while knowing that feedback from stakeholders and the market will shape their understanding of the product over time.  This takes an incredible amount of foresight and market understanding to get started in the right general direction, as well as the courage to simply start product development knowing parts of the vision may turn out to be incorrect.
  • Show it:  The PO has to over-communicate what the Product Vision is. When you think you’ve communicated the vision, communicate more: to your team, to the stakeholders. Don’t underestimate the power of using all available tools to do this, such as big visible walls with notes and graphics – this is showing.  A wall cannot replace a conversation – taking the time to make sure everyone involved in the product – and that means everyone – is included in the conversation and understands the vision is critical to your success.  Use hallway conversations, formal meetings and happy hours (most teams’ preferred method).  The more all stakeholders and the project team knows WHY  they are building what they are building, the better the results.  This has been proven over and over.  Simply stated: Vision + Self-Organization = Value.

2. Manage the Backlog.  Beyond the basics of creating a backlog full of product desirements and iteratively clarifying them during grooming sessions, a PO is responsible for the more nuanced activity of ordering.  The PO orders the backlog with many different criteria in mind: value, risk, priority, necessity, learning objectives, ROI,  dependency and many others. It’s the method by which the PO optimizes the value of the product for the stakeholders.  This is not a trivial task, nor is it completely objective.  Knowledge of the market, the vision of the product and short/long term opportunities all need to be taken into account.  Owning the backlog is the only activity of these three I’m discussing that is touched on in the Scrum Guide (sans specifics of course).  It’s also probably the most common PO dysfunction: POs are NOT simply backlog secretaries, or backlog item creator/maintainers.  A PO can rely on their team to do much of this work.  An efficient, functional PO spends less than 25% of his time dealing with tactical things like managing the backlog and the majority of his or her time on strategic activities like #1 and #3.

3. Steer the Product.  I struggle on what to call this part of the job.  “Plan Releases” is what I started with, and an important part of Product Ownership is creating MVP’s and selecting the right content for each release, but this is only the first step.  The real job here is learning from each release, testing the hypothesis you’ve delivered to the market and validating your vision of the product in its natural habitat (the market).  If it turns out many of your assumptions and hypothesis are wrong, you have to Steer the Product.  Depending on the magnitude of steering needed, the PO makes big changes to the Product Vision (pivot), or just small changes to the Product Backlog (persevere).  A PO is responsible for the current state of the product and the direction it is headed – and they accomplish this by Steering the Product.

Can one person do this role?  Yes, absolutely.  Does this mean that the Product Owner role replaces all manner of  marketing, strategic sales, and business analysis roles in an organization?  Absolutely not.  If the product is big enough, there may be a need for a PO to work along side all types of professionals providing things like: market analysis, sizing, trends,  strategy, competitive analysis, business process analysis, relationship building, user personas, business cases, pricing strategies, legal work, vendor sourcing, contracts, etc.  The PO can have people on the team or outside the team that understand (and even do the work for) these other items.  The PO remains responsible for the overall state of the product and its future.

Take No Dependencies!

As a product owner and coach, one common question I often get is “how do you deal with cross team dependencies, like when Team A has to complete some work before Team B can begin theirs?”

If the room is silent after that question is asked, before too long somebody will likely suggest a “dependency matrix” or “tracker” or “gantt chart in MS Project” or the like.  Do not let the room be silent for too long.

There are many possible solutions to this problem, all of them more effective that inserting an antiquated project management tool like any of the above.

1) Team A and Team B work together to complete the work starting with the prerequisite work (originally ‘assigned’ to Team A) and then moving on the post-requisite work (originally ‘assigned’ to team B)

2) Team B goes and works on something else, and Team A communicates to Team B when the dependency has been met.  No need to “track” anything – Team A is full of smart people who will communicate their status to Team B.

3) Team B waits patiently  for Team A to finish.   They paint the office.   Stock the beer fridge.  Help on sales calls, research a new technology, put together a presentation, read a book, go to a conference, etc.   And all the managers GASP at the underutilized capacity, but you as a smart agile manager know that you may indeed be optimizing the system by not trying to optimize individual teams.

Scaling Scrum – Team Ownership

I’ve been practicing the Product Owner role at a large fortune 100 company, on a program that has massive potential.  One effect at a large fortune 100 company at least, is that bodies get thrown at it.  In the course of not even a year, we’ve gone from 3 Scrum teams to 11 Scrum teams, 5 Scrum teams not in the same building, plus a customer support team, a massive dev-ops team and an operations center.  Wheh.  Plenty to discuss here in future blog posts.  Let me know if scaling scrum issues are of interest to you.

Today I’ll keep it focused at the team level.  Take this situation: Team A works on a specific feature for a few sprints.  Something new pops to the top f the backlog which Team A is uniquely qualified for, and they suggest going for it next sprint.  They talk with Team B and product ownership and everyone agrees that Team B will pick up the remaining work on Team A’s feature and make a few enhancements and add a few new features. I would suspect this is a common occurrence in large programs.  Probably sometimes in command-and-control ways (listen up people, we’re going to re-org these teams to work on different things….)  But even in a good self organizing system, this can create issues.

What responsibilities does Team A have to Team B while Team B is working on the codebase Team A originally created?

The perfect world answer is that Team A is responsible for knowledge-share, a few Q&A sessions, and nothing more.  Team A has left their codebase in good shape, with low technical debt, and plenty of artifacts that explain what’s going on and how to get work to done in this particular codebase.  They’ve showed their working software every few weeks and been transparent about what’s done and what’s not.  Team B has all the necessary skills needed to turn backlog items related to this feature into done software.  Team B does all the design, coding, testing, etc, etc, etc needed to produce done increments.  They rely on Team A only for the occasional question and explanation.  In the perfect world, both Team A and Team B can make progress simultaneously.

In the real world, this probably isn’t the case.  There is likely going to be significant drag on both teams for quite a long time.  Mangers like to call this a “transition period.”  Developers and teams like to call this “hell.”  The teams will fight over the state of the codebase “you’re handing this crap over to me?!!?!” and quarrel over getting help “can’t you just spend a few days [doing our work for us]?!?”

Scrum will make this very, very apparent (this is a good thing!)  It will not fix this for you.  (what’d you expect?)

As a manager, you want the team to own their work, even if they didn’t create it from the get-go.  A team that is whole-owner of their work is a team that learns.  They are a team that is solely responsible for quality.  They are a team that has all the power to create great products.  You want this.  Don’t get sucked into the short-term tactic of having “all teams help each other” and having alot of cross-team dependencies and other teams to parts of features or parts of development, etc.  It’s a short term tactic that optimizes the struggling team at the expense of all teams.

It’s not an easy choice.  It takes courage and vision to wait while a team struggles for a bit to find its way.  But it will.  It will learn and organize and grow and come out the other side all the better for it.

The Software Weatherman, Part 2.

Many people would answer my questions in the software weatherman, part 1 with a “yes, go for it” and many people would say “nope, not worth the risk.”  I’m not sure there is a right answer on the surface.  Perhaps it will be OK to risk it and perhaps not.  But if you are at all concerned with wasting the extremely expensive paint by taking this risk, you probably don’t go for it.

Software is developed in a similarly risk environment.  Software is painted in the outdoors, if you will.  You have to be concerned with such inherently unpredictable things as the weather.

This is good news.

If you work with your business to understand how software is created and how features grow into a product, you will create a shared understanding of the complex, creative, and at times unpredictable process of creating software.

The more they understand this, the more they understand the environment in which you create software, the more honest you can be about forecasting the work.  The business / your Product Owner / your customer already knows that they have bought some extremely expensive paint, and you can bet they do not want to waste it, or risk having something not be done and done right.

With this context in place, you’ll find it orders of magnitude easier to have those tough schedule/budget/scope conversations with stakeholders.  Your job is software weatherman, forecasting the project in an environment of uncertainty, more sure about the next day’s weather than the next month’s,  and treating your estimates as nothing more than a forecast.

Now, this doesn’t mean you are off the hook.  Even a rookie weatherman can predict the weather with some certainty.  They know it’s cold in winter and hot in summer.  You as a software weatherman have the responsibility to forecast in at least the same way.  It’s not acceptable to your stakeholders to hear things like “there’s no way to know” or “we all used the infinity card in planning poker” or “it’s so complex and there are too many unknowns.”  Even a rookie software developer can tell if something is a week or year worth of work.  Step up, and in the context of giving forecasts, give one!  You will modify it later as you learn more, do a little work, and re-evaluate.

If you’re business understands the environment in which you create software, they will behave more wisely.  You will see commitments and must-haves and multiple #1 priorities shift into ordered backlogs and agile roadmapping.  Give it a try.  Go explain to your business partners how you create software.

Hang around with people who get sh*t done.

I freely admit that in a past job I was a loser.  You know the guy in the office who gets stuff done?  Yeah, I was the other guy.  And it wasn’t that I didn’t produce anything, I did.  It wasn’t that I didn’t fulfill my job description, I did.  But that’s all I did.  For some reason it seemed OK to me to just be average.

That’s a fair picture.  But so is this:

I was a smart kid fresh out of college, surrounded by people with 20 years of experience but no more skills/knowledge/abilities than I.  My average was at least equal to the group’s performance, maybe a bit better due to nothing to my character’s credit but to my more recent education.  I was promoted and given raises and begged to stay when I finally quit.

That’s a fair picture too.  Both pictures were simutaneously true.

Why?  How can this be?

I stumbled across this post that I think describes what was happening fairly well:

“hanging around people who are doing amazing things makes me try harder to do amazing things”

The people I was surrounded with, in retrospect, weren’t exactly doing cool stuff.  The team wasn’t thought of as an innovative team.  The work we were doing was thought of as a necessary evil in the organization (you’re not people, you’re a cost center!).  Compared with other jobs I’ve had, it’s easy to see this truth in retrospect.  When surrounded with A players, I tend to perform better.   So that brings up two questions for me:

Q1) Why is this true?  Why do we tend to perform better when surrounded with top talent people?
Q2) Can we identify this in-the-moment or only in retrospect?  How can we evaluate our current situation and work towards bettering ourselves?

A1:  Peer Pressure?  Probably.  Intrinsic Motivation?  Probably.  Suggestive Energy?  Probably.  Behavioral Psychology?  Probably.  Regardless the means of this drive to perform better when surround with better performers, it all goes back to classic systems thinking.  That is, a person’s performance is more a product of the system in which they exist; and less a function of individual aptitude.  Sure you have to have all the requisite skills and abilities to do the job, but creating really great performers (or really poor ones) is a function of the system.  From Ackoff:

“An important aspect of a part’s performance is how it interacts with other parts to affect the performance of the whole.”

There are even been studies that show the simply thinking about smart people may make you smarter.  While that claim is  dubious at best, it’s interesting and lends itself towards the same conclusion: surround yourself with people who are smarter than you are, better performers, and doing cool things, and you will likely perform better – because the system you are part of is a better system.

A2: If we work on becoming more aware, surely we can see these truths in-the-moment.  You might need some reference, something to compare your current situation to, but maybe not.  I think a large part of this can be self-known and is as much a gut-feel-in-the-moment thing as it is a comparing-in-retrospect thing.  If you sit down and think about it – really feel – you can answer the question for yourself.  Am I doing my best work here?  Is the system I’m in helping or hurting me long term?  Is it time for a change?  Surely beware of “grass is always greener” or other pessimistic frames of reference.  But for the most part I think these answers are self evident.

Agile and Bow ties

The software and agile worlds are full of analogies.  Some good, some funny, some dangerously misleading.  I suppose I’ll add one of my own to get this blog kicked off:  

Scrum is like a bow tie; waterfall is like a straight tie.

When I first decided to sport the bow tie on a regular basis,  I spent a good amount of time learning how to tie it in the first place.  I couldn’t just coast through some simple sketch of a half-windsor like I did with a straight tie in 6th grade.  Bow ties take some training.  I watched youtube videos for about an hour.  But a funny thing happens once you get it the first time – you get it.  After you get it once, every knot comes out perfect after that.  It becomes second nature very quickly.  Unlike the straight tie where we might need multiple attempts trying to get that knot to look just right (and there are so many variations in knots that you never can quite tell ahead of time which one will look best), the bow tie is repeatable.   Plus it’s just more fun than boring old straight ties.

Just like Scrum.  You have to know the basics, you have to get some training.  You can’t just coast along like you can on a waterfall project.   But once you get it, it quickly becomes habit.  I couldn’t imagine being on a innovative project and not working in sprints.  With scrum, there is less variation – the sprint timebox is repetitive and reduces all those bad [waterfall] knots that just don’t turn out correctly.  Every step of the way you get to monitor and sample your product.

And the most important part:  Scrum is more fun.