Owner to Owner
Enterprise Agile presents many fascinating challenges. One of the most fascinating is the notion of multiple Product Owners on a single project. If you think about it, this is a recipe for disaster. “Collective Code Ownership” is something engineers have worked out very well over the last two decades or so. But the idea of collective product ownership, and its successful execution, has not been thoroughly addressed as far as I know.
The Product Owner role is a classic Scrum role. In the official Scrum Guide, Jeff Sutherland and Ken Schwaber make clear and unambiguous statements from which one could easily infer that projects with multiple Product Owners have inherent challenges:
“The Product Owner is the sole person responsible for managing the Product Backlog.”
“The Product Owner is one person, not a committee.”
“For the Product Owner to succeed, the entire organization must respect his or her decisions.”
Finally, Sutherland and Schwaber assert the immutable nature of Scrum itself which strongly suggests that the very framework in which the Product Owner role is defined only makes sense when there is but one.
“Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”
So with multiple teams and multiple Product Owners working together on a large enterprise project, we are likely to find ourselves with too many chiefs, too many chefs, too many egos and, as a result, often behind 8-balls, up creeks without paddles, between rocks and hard places, and continually searching for metaphors, idioms, and aphorisms to describe our challenges—because we don’t have clear language with which to describe them directly.
How do we know when we’ve got a serious problem? When we know there’s something wrong and we can’t even describe it very well.
And Then It Really Gets Complicated
While there are relationships you will have that are more important than your relationship with other Product Owners, PO-to-PO relationships are potentially the most complicated. The first complication is a classic one: How does shared ownership of a product work? The second complication is more specific to enterprise Agile projects: How do a set of co-equal “owners” each take full ownership of something when each only has a part, when so many dependencies are likely to arise across teams, and when there are shifts in workload, variance in team performance, and differences in team expertise with regard to specific parts of a large system?
There are many little Do’s and Don’ts that I will talk about in subsequent posts regarding PO-to-PO relationships, but I want to start here with a story about a situation I was in—one that I imagine is fairly common and for which there is no standardized “process” or “structural” solution that I’m aware of. It’s a distinctly human problem, one that I think is best addressed through human interaction.
Product Owner A has been working with her team on part of Project X for eight sprints. Meanwhile, Product Owner B (yours truly) has just finished up working with his team on a different project. Management would like to put a little more horsepower behind the work that Product Owner A’s team has been doing, and now there’s a free team available. How lovely.
For Scrum Masters, engineers, architects, and QA’s this is not such a big deal. But for Product Owner B there’s a problem: What’s my status relative to Product Owner A? Do I work for her? If so, what do I really “own”? If not, how do we deal with co-ownership, especially when she’s eight sprints ahead of me on understanding the nature of the product over which she has already established sole ownership?
This has all the makings of a turf war. Does she have to share her product somehow? Or did I just get demoted to work under her leadership? I don’t even understand the work her team has been doing. Technically, we occupy the same level on the org chart, but she’s ahead of me on this part of the work. Having finished something up with my team, I thought I was moving on to bigger and better things. Now it seems I’ve moved on to a whole set of bigger and not better problems.
It’s true what they say: the solution to every problem in life can be found in a Broadway musical. But I’ll get to that shortly.
The key to making this somewhat awkward situation work out for everyone is for me to create a good relationship with my new PO partner. There will be no clean technical or procedural solutions here, only personal ones. The fundamental challenge we face in developing good relationships is that we don’t feel safe to develop them.
Relationships seem inherently risky. How do we introduce ourselves? What do we say to each other beyond the obligatory small talk required of our roles? How are we supposed to interact with each other? We don’t exactly know. And not knowing feels unsafe, especially if we are new to a group, in a junior role, or from a different culture.
Things are even harder than that when there are no guideline for us to rely on as is the case with the multi-PO problem. What boundary conditions exist in this specific context to keep us from making huge mistakes? How are we supposed to know how to interact at all, let alone optimally?
Gradually, over a long period of time, we may get used to each other, we may establish weak but workable norms for our interactions, but we probably won’t really get to know each other—at least not well enough to support high-performance work relationships. The longer this not-knowing of each other goes on, the more likely we are to maintain walls between us until an unproductive privacy becomes the default culture of our project.
This is even more critical in the multi-PO situation I describe. There has been little written or researched about how Product Owners might ideally interact, especially when one of them is a lot farther along on a given project. Even the small talk of our required roles isn’t something we can fall back on because co-Product Owners don’t have clear roles and “junior” Product Owners aren’t truly Product Owners at all.
Give My Regards to Broadway
So what’s the solution? Catch a performance of Rodgers and Hammerstein’s The King and I. (Even if it doesn’t fix my problem, it’s an excuse to see a show, right?)
As the story goes, in the mid-19th century, the King of Siam hired British school teacher, Anna Leonowens to educate his royal princes and princesses—all 67 of them. In a classic scene, a naturally nervous Anna meets her students for the first time and wins them over with a now-famous song:
Getting to know you,
Getting to know all about you.
Getting to like you,
Getting to hope you like me.
Getting to know you,
Putting it my way,
You are precisely,
My cup of tea.
Anna’s message endears her to the children. Similarly, their happy reaction endears them to her. What’s the takeaway? The key to feeling safe with people is helping them get to know you, and you them—ideally with a lovely song, but in most workplaces this is not a requirement.
Getting to know each other, however, is a requirement if we want to create a culture that supports high performance.
This is not about participating in contrived team building exercises or pro forma introductions. It’s about making a conscious effort to discover who your co-workers are, and to make sure they discover who you are, too.
In this case—ripped from the drama of real life—I was the “new” Product Owner bringing my team onto the established Product Owner’s project. My team was, of course, looking to me for stories so they could get working. The first move, therefore, was mine: I had to get to know my co-PO and I had to figure out what our respective roles were going to be.
Getting to Know You
I had just wrapped up 16 months as a Product Owner on a large, tense, and often tedious enterprise effort when I was assigned to PO a completely different project, one that would require close coordination with a pre-existing team at my company’s headquarters, 500 miles to the north. I knew my own team members well but I didn’t know the PO at the home office at all—and it seemed pretty clear to me that she “owned” the project because she was, in fact, the original owner, and she was so far into it with her team.
Miranda had been PO-ing the effort already for eight sprints. My immediate task was to derive requirements and produce stories based on her backlog so that my team could code the plumbing for her vision of a system that would support applications and the storage of user data. I was also told that she was ambitious and that she liked to work fast.
Already intimidated, I thought my safest strategy might be to avoid personal contact altogether by working entirely off the project backlog without actually ever communicating directly. (Look at me! Taking the cowardly low road right from the start. But that’s what we often choose to do when we don’t feel safe.)
And so I began:
- Log into Jira.
- Have mild panic attack as I encounter 300+ user stories, most of which I don’t understand.
- See who wants to go out for lunch so I can forget about this for a while.
There was no getting around it. Not only would I have to talk to Miranda, I would have to talk to her immediately just to plan my first sprint because I desperately needed her help to get up to speed on the project. (So much for that escapist lunch I wanted.)
Who Ya Gonna Call?
Calling an ambitious and potentially impatient person you’ve never met and saying “Hi, I need about six hours of your time between now and tomorrow afternoon to figure out my job.” is not a getting-to-know-you-strategy I recommend.
It then occurred to me that I knew absolutely nothing of any personal substance about this person. No one in our office had worked closely with her. Everything I’d been told about her was really second-hand information.
So I threw up a Hail Mary. I went to the employee directory praying for a miracle tidbit of useful personal information. Lo and behold, at the bottom of her profile in a text box labeled “Hobbies and Interests,” I read the following: “I play NLHE. Sometimes at WSOP tourneys. Hoping to make it to The Main Event some day.”
A Winning Bet!
A few minutes on the Google revealed that she was a professional gambler. Her game of choice was No Limit [Texas] Hold’Em. She was a serious player, good enough to play in official World Series of Poker events. She hoped to qualify for the world championship some year.
By chance, I had stumbled onto one of her affinities.
I love the word “affinities” not only for what it means (“a natural liking for something”) but also for its last four letters which spell the word “ties”. I think of affinities as things that are a part of who we are to such an extent that we are literally tied to them.
I also now realized that what some people may have interpreted as her ambitious and impatient nature might just be the kind of gutsy competitiveness one would expect of a serious poker player.
You Never Get a Second Chance to Make a First Impression
I knew my first interaction with Miranda would set the tone for many interactions to come. I also knew that I needed her help. But before I asked for the help, I tried to make a connection.
I sent her a short e-mail introducing myself and at the end I asked her a question about poker. I made no reference whatsoever to the project, what I needed to do, what our roles might be, etc. I didn’t suggest a Skype call to begin talking about these things. This was purely a social call.
What’s the idea here? Whenever possible put relationships first and transactions second.
She responded right away and asked me if I was a poker player. (Notice again that we’re not talking about our shared project.) Even though I’m not a poker player, I continued the thread by asking her a few more questions about it, relying on Google and Wikipedia to shore up what little I knew about competition card play so I could stay in the game. This kicked off a thread of brief messages back and forth throughout the day.
I still didn’t even mention the challenges I had in getting up to speed on the project. But this time, it wasn’t avoidance that was driving me, it was the opportunity I felt to establish a good relationship. By talking to the person, and not about the project, I was building something far more valuable in the long run than whatever technical or procedural knowledge I might need.
Toward the end of the day I got lucky and found something we had in common with regard to the game of poker. The poker I have played wouldn’t even qualify as real gambling. It’s mostly just nickel and dime stuff from my high school and college years. But I had seen some great poker movies over the years, so I took a shot and sent her something like this: “My favorite poker movies are Cincinnati Kid, Rounders, and California Split. You?” She writes back five minutes later and says, “Oh, Rounders, definitely.”
Now I knew I was in. I had made a connection. We had some very, very small bit of shared history now (one movie that we both liked) but that’s a lot compared to what I started with.
At the end of the day, she sent me a message, this time not about poker but about the project. (OK, here we go. Deep breath. What’s the worst that can happen? Keep rationalizing away your fears. Yeah, that’s the ticket!)
In part, her message read: “You’ve probably seen the backlog. Sorry it’s such a mess. Do you have time on Monday for a Skype call so I can catch you up? I’ll work a little over the weekend to get things more organized.”
Rodgers and Hammerstein Were Right
Who isn’t at least a little nervous about interacting with a co-worker for the very first time? The unknown is inherently unsafe. When it comes to people, getting to know them and letting them get to know you often feels un-safest of all, but it is almost always the best thing to do.
Getting to know people, especially through their affinities, is often the easiest root. Most people love talking about their affinities. All we have to do to get things started is ask them a question or two. As the discussion expands, we often find commonalities, even if one person’s affinity is merely another’s curiosity.
But affinities are just the beginning. The first line of the famous song is, “Getting to know you”; the second is “Getting to know all about you.” This takes more time and a lot more effort. But our investment here pays rich dividends when it comes to creating highly productive work relationships.
How well do we need to know someone we work with? And what does it take to know a person that well? Those are important questions but one question is even more important: Why bother?
Well, in my case, and in most PO-to-PO situations, there’s plenty of reason to bother. The project I had just come off of suffered from two common and devastating problems with multiple PO’s: we didn’t agree on the product we were making together and eventually there emerged a two-tiered PO hierarchy with more experienced PO’s treating less senior PO’s as though the latter group really did work for the former.
Far from ideal, I think now in retrospect that the dysfunction of our PO group was a key factor in the disappointment of our work together. We finished the project, released the software, and nobody got in any big fights. But the work we did was far from spectacular, and at times the friction was high and the tension was tedious.
In retrospect, it’s very easy for me to see now that the PO’s I took the time to develop good relationships with were the ones with whom I worked best. Had I put forth the same effort with all of my PO pals, I know that I would have been more effective and happier. Had we all worked hard to build and maintain good relationships with each other, I think the project would have turned out dramatically differently—much better for us and, especially, for the stakeholder.
There are Teams and Then There are Teams of Teams
We work in teams because the task before us is greater than that which can be completed by one person alone. If we could complete a task by ourselves, being part of a team wouldn’t have much value, at least as far as productivity was concerned. We might even be less productive because of time and energy spent on team interactions.
The systems we build today are huge. Rarely does a truly valuable project exist that can be completed by a single person in a reasonable timeframe—or even a single team. Scrum masters seem to have this figured out. Even if you’re not a fan of “Scrum of Scrums” at least it exists.
But what do groups of Product Owners have? Only the quality of the relationships between them.
Because we can’t solve problems by ourselves, we need help from others. Highly accomplished individualists that we are, we tend to think of ourselves as self-sufficient. But on most projects that’s an illusion. The reality is that we need to help each other a lot to get most things done. This is especially true if we are one among many Product Owners on the same project.
This is why it makes sense to know our PO partners well. The better we know each other, the more likely we are to cooperate well together. And because the PO role is prototypically a singular function of ownership, multiple PO’s on the same project have to figure out ways to cooperate especially well in order to be sure we’re all making the same product and, to the best extent possible, speaking to stakeholders with one voice. Problems are going to come up, systems are going to break down. The quality of our relationships is what gets us through the low periods and supports the potential for high performance.