A Safe SAFe Journey

I have been very open about my views on SAFe.  I’m a supporter and, admittedly, cautious in my support.  I am cautious because I worry the emphasis on people and the necessary mindset isn’t prominent enough on the “Big Picture”.  In the wrong hands, the results of implementing SAFe could be….lacking (aka: horrendous) resulting in a horrible experience for all involved.  While, honestly, the same can be said of any framework used to implement Agile; SAFe is riskier because it’s BIG.  It can be HUGE even which, as we all know, isn’t the preferred way of operating.  Recently, I embarked on an opportunity to coach a a group with a BIG vision and they want to be as close to Agile as they can be.  Enter SAFe and the journey of making it safe for all those on board the train.  I’m going to do my best to share this experience with you.

I’ll start by explaining what I mean when I say “safe” or “safety”.  To me, a safe environment is one in which the values and principles of both lean and Agile can be put into practice without fear.  It is safe to raise issues, learn, make quick decisions, disagree, develop, release code into production, be honest, tell someone “no”, empower people, trust people, try something new and do what’s necessary to achieve the vision everyone (and I mean EVERYONE) is aligned to.  There’s more – lots more – but I’m sure you get the gist.  This kind of environment isn’t an easy one to create from the beginning and even harder to achieve when an organization is established and set in their ways.  So, where did I begin?  With the people who invited me to coach them and their leaders.

Do you know how hard it is to get “higher-ups” to spend a day with you for “training”?  Most of the time, it’s not even possible.  I can’t tell you the number of times I have watched perfectly good and valuable training which, typically, would be a full day get hacked down to 2 hours.  Funnily, it’s not the people receiving the training who require the cliff-notes version.  It’s those below them who insist a whole day isn’t possible and you’ll be lucky to get those 2 hours.  Then, you don’t get past slide 3 because slide 3 USED to be slide 30 and you’re training slides 2-29 off-the-cuff.  And, just when you really get going….times up!  Anyway, don’t get too excited because I didn’t get a whole day.  However, I was able to spend a solid six hours with them and I believe that time is one of the differentiating factors for this particular SAFe adoption.

The first clue I had to the possibilities of this group was they didn’t balk at spending time learning about Agile, lean, SAFe and what it means to be a leader in Agile.  The second clue I had was their laptops were down, phones were on silent and turned over and they were 100% present and engaged.  Granted, I did ask them for that but they didn’t complain!!  They just said OK and did it.  Third, the place where we spent the majority of time was on being a leader in Agile and working on how they would work together to make this effort special – not only in WHAT they were delivering but also HOW it would be delivered and how they, as a leadership team, would work together towards realizing BOTH objectives.  They immediately were applying what they learned to their team and their situation with completely open minds and genuine excitement. Finally, this group of leaders with open minds and genuine excitement realized and discussed how difficult this would be for those directly and indirectly involved and how, while they didn’t have the answers, would need to be supportive of each other through the journey of learning.

So far – and it’s only been a month or so – I have observed some pretty cool stuff that started during those 6 hours.  I have watched these guys engage with others in a different manner and subtly shifting the tone of conversations by sharing their vision and extending invitations to be involved.  I heard them asking other leaders (and each other) to “ask the team”.  I have seen them catch themselves and correct behaviors to model Agile principles.  Most of all, when they were up there in front of 150 team members, they all said (in a nutshell) they were there to support and enable the teams and their ability to achieve greatness personally and professionally.  They talked about empowering the individuals and the teams.  They stated they didn’t have a hard date and a backlog of non-negotiable scope.  Instead, they had release candidates and the teams were in control of what was brought in and what was left out.  They communicated their vision and invited everyone in the room to participate.  The response from the teams has been awesome.  From them I hear things like “These guys actually seem to believe in and want Agile so why don’t we try <insert experiment for team to get closer to Agility here>?

Here are the key learnings I have from this particular stop on this journey:

  1. Be very clear on what you want people to leave the room with following your time together and spend the majority of your time there.  The training isn’t what’s important.  What is important is what they do when they leave training.
  2. Ask people to set aside what their reality is – for a time – so they can learn without interference from it.  Then, ask them if it’s OK to hold them accountable to that (assuming they agree to).  This keeps the dialogue open without getting mired down in specifics from their reality.
  3. End your time with real-world application.  NOW they can bring their reality in.  This time is priceless. Minds are open.  Challenging their conventional wisdom is fluid and the knowledge goes from theoretical to practical.
  4. Start with the mind-shift and take it from the TOP.

The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books, Part Four


Eight Tips for Optimizing PO-to-PO Relationships

I’ve talked before about the inherent problem with enterprise Agile: having more than one Product Owner on a project. The fact that the problem is inherent, however, doesn’t mean that enterprise Agile is flawed, it simply means that we have to accept the incongruity of what amounts to mutual ownership, shared ownership, or no ownership at all (when no PO feels like a true “owner” of any part of the “product”).

In the archetypal Scrum team, there is but one Product Owner. So enterprise Agile, with its multiple POs represents a change from that model. Agile embraces the idea of harnessing change to increase value. So it makes sense to ask, “How do we harness the inherent ‘problem’ of multiple POs to increase value for our stakeholders and satisfaction for ourselves.”

Here are eight ideas. In my experience, pursuing all eight give me the opportunity to maximize my effectiveness. But pursuing any of these with transparency and diligence will improve your results—and because you’re a Product Owner, they’ll improve your product, too.

1. Pick a PO Partner

The most obvious thing we can take advantage of on an enterprise Agile project is that we are not alone. Specifically, I recommend identifying one other PO you can think of as a true partner. As a Product Owner, you face pressure from all sides of the project. The only people who truly understand this are your co-POs. Having one person you can go to—for advice, consolation, or just to vent—is a very useful thing.

If you set out with good intention to pick a partner, you’ll eventually gravitate toward the right person among the other POs on your project. In most cases, there will be several different people you can partner with successfully. Look for two things: (1) A person you can relate to easily and who can relate to you; and (2) A person who has skills that complement, rather than amplify, your own.

The PO role is simply too expansive and ill-defined for any single PO to have everything covered. Finding a PO partner who has knowledge and skills that you don’t, who is also someone you can come to in confidence, and come to depend on for support, is invaluable.

The value of a strong PO partnership is probably best seen when we are struggling. If I struggle alone, there’s a good chance I’ll get stuck. But if I struggle in the presence of a partner, there’s a good chance that person will help me get unstuck.

This can take many forms, but the most valuable thing that I have experienced is the benefit I’ve received from another PO in helping me understand and serve the needs of stakeholders. Often, in our attempt to collaborate with stakeholders, we end up negotiating instead—and all too often we negotiate badly because negotiating is not something most of us specialize in. While stakeholder collaboration is preferred over contract negotiation, we all seem to love to negotiate on the job, such is the competitive nature of most workplace cultures.

At times, I have had a very hard time communicating effectively with stakeholders. At times, I have not clearly understood their needs or faithfully represented their requirements. At times, stakeholders have seemed to me entirely unreasonable. But notice that these assessments are based on my own survey of my own perceptions, perceptions that could be highly flawed. After all, a survey where n=1 has a margin of error of infinity.

If, however, I can check off my perceptions about stakeholder interactions with someone who knows me well, someone I trust, and someone who has exactly the same relationship to the stakeholder that I do, I can get a much more accurate read on what’s happening and gain valuable insight into how to perform my role of stakeholder advocate more successfully.

2. Practice Reciprocal Altruism

Evolutionary biologists are always working to make the case that one key element in the survival of the human race is our ability to execute acts of reciprocal altruism. In fact, the best explanation I know for the development of language in our species is that grammar is the easiest way to know “who did what for whom” so that we can remember to return the favor.

Think of this less like scorekeeping and more like investing. The altruistic things you do for other POs—the things you don’t have to do and take no immediate benefit from—are investments in your future success. The more you invest, the more likely others are to reciprocate.

I suggest the investment analogy over the scorekeeping analogy because the latter is competitive and the former is cooperative. Doing something I don’t have to do for another PO is a form of cooperation. The interesting thing about this is that it doesn’t take two of us to agree on the cooperative action. I can initiate it myself.

One of the biggest investments you can make in this regard is picking up the occasional story from another PO’s backlog when that PO’s sprint may be in jeopardy. Invariably, on a project with 5-10 teams, one or two will be doing just fine on their sprints, while several others struggle. Under normal circumstances we can’t barter our team’s resources because this amounts to reassigning work, something that is clearly in the Scrum Master’s domain. But I can always offer to do this if I say, “Let me take this to the team first.”

In fact, I have gotten into the habit whenever I receive a resource-related request of saying, “Let me take it to the team.” What I mean by this is that I am open to considering any and every way of contributing positively to the project but I can only do this through the unanimous consent of my team members.

Setting the high bar of unanimous consent may seem like saying, “I’ll never help anyone ever.” But, actually, it allows you to help everyone more often because it simultaneously displays respect to your fellow POs, to your team, and to the needs of the project as a whole.

If people know that you are always open to considering their needs, they will bring their needs to you more often. If you are transparent about the conditions under which you will be able to help, everyone will understand why you do some things at some times but not at others.

Even consideration is a form of reciprocation. This means it’s perfectly OK to come back with, “The team says we can’t do that right now.” Making the project safe for “No” is a huge achievement that will dramatically improve your organizational culture. It will also make your organization a place where others are more likely to say “Yes”.

3. Root for the Other Players

Multiple Product Owners is a recipe for competition. It’s so easy to get into the habit of zero sum thinking and “win-lose” propositions that we have to put forth a deliberate effort to build a culture where this is less likely to happen. The best way to do this is to actively root for other teams and their Product Owners.

No two teams will perform equally well across every sprint. Some will perform better, others worse. Over time, some teams may develop patterns that contribute to sustained high performance while other teams struggle, sometimes for no obvious reason. When I’m on the high performing team, it’s very easy for me to feel superior. When I’m on the other end of the scale, it’s even easier for me to feel like a failure. Neither of these positions is helpful.

My feelings of superiority, even if they are grounded in empirical evidence, set me apart from my co-POs. This is corrosive of cohesion and culture. It’s also a recipe for disaster if I get into a situation where my team hits a bump in the road. Perhaps worse is the situation where I begin to sense my own failure. Now I want to isolate myself, to pull away, to lay low hoping no one notices until I can figure out how to get things back on track. Ironically, this is the very time I need people around me.

If I’m always actively rooting for the success of other POs and their teams, we stay closer together as a community. My success is everyone’s success and, even better, the success of others is shared with me as well.

There are many ways to root for others, but two have worked well for me: (1) Publicly acknowledging the work of another team during a cross-team demo; and (2) Acknowledging the skill of another PO in private.

4. Exude Optimism

This is huge. Actually, it’s huger than huge. Seriously.

Whether it is fair that the role of eternal optimist should fall to you, a Product Owner, is irrelevant. You must play that role. If the Product Owner is not optimistic, why should the stakeholder be optimistic? Or the development team? Or management?

Optimism doesn’t mean glossing over challenges or misrepresenting hard realities and inconvenient truths. It means responding to these things with a “glass half full” attitude.

Even if you don’t know a way to solve a problem, assert that there is a solution and pledge your best effort to discover it. For every misstep that occurs, focus on the lessons learned and immediately show how you can apply that learning to the next iteration. Reframe problems as opportunities.

Enterprise projects are never a picnic in the park. They are more often a long, hard slog. At difficult points in a project lifecycle, times may be hard for everyone. It is at these crucial points where success is won or lost.

For the most part, perseverance is the key. And the energy for perseverance comes largely from optimism, from the mental calculus we all engage in about whether something is worth our effort based on our impression of its likelihood of success.

You, the Product Owner, are the public persona upon which many of these assessments are based. When things go wrong, nobody likes to move forward. Yet this is precisely the time when leadership is most required. As long as others believe that you believe there is a way, they will follow. You don’t have to have the answers, but you have to insist that the answers exist, that they will be found, and that when they are, effective action will be taking by everyone involved.

5. Know the Narrative

Large projects are like long novels. They have a narrative: a past, a present, and a projected future. As a Product Owner, you are likely to be the only person who knows the whole story.

Development teams are often protected from stakeholders and management for good reason: so they can get their work done with the fewest distractions. At the same time, stakeholders and management have a deep need to know how things are going because they bear the ultimate responsibility for success or failure.

Whether you like it or not, one of the requirements of being a PO is being a storyteller. Not a teller of tall tales, something more like a historian. You are the person who knows the most about where the project has been, where it is now, and where it is headed.

Why is it so important to know the narrative? Two reasons: (1) As I just mentioned, everyone naturally wants to know it and they know that you know it best; but more important than that is the fact that (2) When fortunes shift, people will naturally look to you for your interpretation of events.

I’ve never seen a project that didn’t have it’s low points. I’ve seen teams hit negative velocity because more time was spent in a sprint on tech debt and defects than on features. I’ve seen resources run low and executives run hot. It is at these times that many people feel like giving up or getting away.

And that’s the last thing a struggling project needs.

I have a talk I give called “Great Expectations”. It’s about how most of us start new projects with high hopes even though every project we’ve ever been on has hit rock bottom at one or more points in time. There’s always a moment in the talk where I ask the audience, “What do you do when you don’t know what to do?” Astoundingly, more than half the people say something like, “Start looking for another job.”

This is why we suffer so many colossal failures on enterprise projects: at the very time when we need to pull together, half of us have one foot out the door.

This is the crucial moment when the Product Owner must construct a new narrative for a new outcome. Again, this does not mean diminishing difficulties or spinning circumstances. It means honestly and transparently projecting a way out, a path, a possibility—better yet, two or three because one of them certainly won’t work.

On my last project, we hit the wall three or four times in 18 months. Each time, people thought the project might be cancelled, that we would lose headcount, that teams might be shuffled and responsibilities changed.

Time and again, people asked me about these things in private. They were right. Times were tough. And the easiest thing for me to do would have been to console them and send them to my favorite headhunter.

But that wouldn’t have been right or smart. It wouldn’t have been right because I wouldn’t have been advising my friends based on my belief that we would, indeed, find a way to be successful. And it wouldn’t be smart because encouraging people to jump ship when you really need all hands on deck is almost a form of self-sabotage. Think how you might feel if the most productive engineer on your team left for another job right at the worst time in your project.

Things were really bad at certain times on our project (though we ultimately delivered). Concerns were justified. But panic is never justified—and even if it is, it isn’t helpful. So what did I do?

I offered plausible reassurance based on three things that were part of the project’s narrative: (1) Past history (Did anything bad happen the last time?); (2) Current circumstances (What value would the company see at this point in stopping the project?); and (3) Reasonable forecasts (If we can get through this, doesn’t it seem like there will be a big upside for the company down the road?”)

These were all legitimate and honest ways of responding based on facts and, in the case of future projections, reasonable assumptions that could easily be supported by facts.

It is especially important that you project optimism to your fellow Product Owners because they are keepers of the narrative, too. When times are tough, it’s important that we all stick together. When things seem unstable, people crave stability. Projecting optimism when times are tough is the best way to create the feeling of stability that people need to do their best work even if such stability doesn’t, or can’t, exist.

6. Bestow Respect

I was giving an all-day talk at a conference a while back and I discovered that some of the participants did not understand the circular nature of respect—and that this was getting in the way of their own success and the success of their teams.

One engineer said, “I don’t respect my manager. He makes too many bad decisions.” Another said, “I don’t respect my Scrum Master. His technical knowledge is insufficient.” And so on.

These are unfortunate situations. But they are also common ones. The reason they are so common is that disrespect (which is what these two people were expressing) is a vicious cycle. How likely was it, I asked, that either of the people they did not respect respected them?

Not very likely.

Here’s the vicious cycle part: If we have decided that each of us must earn the respect of the other, then what happens when our success depends on collaboration? Was it possible, I asked the people in the workshop, that the manager and the Scrum Master need your help in order to be successful?

Well, yes, they supposed  it might be.

And you certainly need to be respected in order to be as successful as you can be, right?

Yes, obviously.

So what happens when two parties who depend on each other’s success are waiting impatiently and judgmentally for that success to emerge—while withholding respect on the condition that it emerges?

In this situation, both parties likely fail, respect declines, failure escalates, respect bottoms out completely, and soon, the respect none of us can earn from the other becomes palpable friction that slows our progress to a crawl or halts it altogether because we’re both withholding based on a condition of mutual disrespect in which neither of us can deliver.

Many of us have this notion that respect must be earned. While understandable, and very human, this is a potentially disastrous attitude to take and a toxic culture to take part in.

Respect is bestowed, not earned. I’ll say that again in bigger letters this time: RESPECT IS BESTOWED, NOT EARNED.

Respect must be the default condition. And, in fact, if we truly want to be successful, respect must be a constant because without it, we lose much of the power we have to solve problems collaboratively. And on enterprise projects, most problems need to be solved collaboratively.

This idea about the bestowal of respect, its default nature, and its constancy, is particularly crucial among Product Owners. If POs don’t respect each other, how can they depend on each other to collectively deliver a product? And if they can’t depend on each other because they don’t respect each other, what is the likelihood that they will collaborate to solve hard problems?

And if they don’t collaborate to solve hard problems? You guessed it: ownership declines until, really, no one owns the product because the entire PO group has collectively abdicated its most basic responsibility.

As difficult as it can be at times, maintaining respect for others (and for ourselves, too) is critical to our success. Every member of the PO group on an enterprise project must respect every other member because every other person on the project is looking for leadership from the PO group.

7. Learn From Your Peers

There really is no standard playbook for POs on enterprise projects. There are books, courses, coaches, certifications, etc. And these are helpful. But they tend to focus on the tasks and competencies of Product Ownership as a generic functional role. You need to understand the specifics of your job as it exists within your specific project.

This why it’s so important to learn from each other.

Unlike engineering, which is a relatively mature concept, Product Ownership came into being only in the last decade as Scrum became popular. That means that most POs don’t have a lifetime of experience and wisdom to fall back on.

What became obvious to me on my last project was that there was something I could learn from each of the other Product Owners. One was particularly good with the stakeholder. One was very technical. One was extremely conscientious and always very well prepared. One had a very interesting talent of being able to identify a team problem and express it succinctly in a single sentence.

At this point in time, I know there are master engineers, wise architects, well-tested QA people, and so forth. There are also many standard references for the technical aspects of software development. But nothing like this exist for Product Owners. We are probably still a decade away from having the definitive PO playbook in front of us.

In some sense, we’re all still trying to figure out how best to do our jobs. And the Product Owner’s job changes more with each new project than almost anyone else’s. So even those who have served on several projects over several years may not know everything they need to know on their current project.

Agile software development is all about learning. And in many ways, POs have the most to learn. It’s not that POs lack skill or experience, it’s just the nature of the work that each product a person owns will likely be a new and different experience.

Because the Product Owner role is, by definition, a singular role, Product Owners tend to be individualists. On behalf of stakeholders, they are responsible for holding the vision of the project. But this doesn’t mean they always have a vision of how to be successful in delivering it.

Acknowledge this with your co-POs. Maintain a collective vision of success and muster the courage to achieve it. But move forward together in a spirit of inquiry. Nobody has all the answers. And in many cases, the answers are unknowable until very late in a project. While having more than one Product Owner has its challenges, it also has the big advantage that several heads are usually smarter than one.

8. Leverage Collective Domain Expertise

As the Product Owner, you are required to have or to develop deep expertise in the problem domain of your project. If you’re lucky to enter a project with years of domain experience, that’s great. But it’s hard to have both years of domain experience and years of Product Ownership experience because Product Owners typically don’t spend years working within a single domain.

This means that you must leverage the domain experience of others.

Your first source for domain experience should be the other Product Owners on the team. Instead of competing to see who knows the most about what, cooperate to first discover and then act upon the domain experience distributed across the group. But don’t count on the PO group entirely to know everything that needs to be known.

Stakeholders are, in some sense, experts in their own domain. But here again, different Product Owners will have different experiences of their stakeholders. And in many situations, stakeholders won’t actually know their domain as well as you might hope. Often, people needing something need it for a very simple reason: they’ve never had it because they’ve never been able to define what it is.

Don’t disrespect the domain. Don’t trivialize it. And absolutely do not take for granted that every PO sees the domain the same way you do. Remember that an enterprise project with eight teams has eight POs. Ideally, those eight minds must in some sense function as one. The only way that’s going to happen is if you leverage the collective domain expertise of all POs on the project.

Harmonizing Chaos

With 100 to 150 people working on a project, and eight to twelve people “owning” it, there’s bound to be some chaos in the machine. The best thing a group of Product Owners can do is strive to continually harmonize the different voices on the project, to refine and synthesize all the ideas floating about, to distill the essence of what it is the teams are producing, to find order in chaos, and to communicate all of this clearly and concisely to everyone else on the rest of the project.

Only through carefully considered collective coordination (yes, that’s a quadruple alliteration for a reason: it’s really important) can a group of POs serve their teams, their project, and their stakeholder well.

Team Behaviors

good_teamsI found myself looking over the shoulder of a 10 year old who was watching YouTube videos.  Teams challenging each other in competitively created Minecraft worlds.  I get curious about what other people see.  Maybe an even better word is ‘perceive’. By being so, I also get to learn.  As this particular video series unfolds, the same competition is recorded by each of the two teams involved.  A perspective from each side.  After the winning team series was viewed, he continued to watch the same contest from the losing team’s perspective.  ‘Why’ resounded in my mind.  “What did you learn? What did the team, that won, – do better?” This elicited such a thoughtful look that I then asked if he could write down just exactly what made the winning team a good team.  I share this list with you, not only because I believe that it was good, but it is also how we spend a majority of our lives.  From kindergarten and even after retirement – we interact in groups.  Teams if you will.  Esther Derby noted the good characteristics of a thriving team.  As well as struggling teams exhibiting something different. What do you and your teams strive for?  I am going to go over this young professor’s list.

Splitting Resources

Effectiveness in being visible with what resources we have.  Many of the reality survival shows take a group that will depend upon the openness to share what they have.  Tools, knowledge, food, sources of inspiration.  Everything is fair game.  What if we consider the members of the group itself to be a resource.  We are sharing of ourselves… Pair programming for example. Teaching or helping to perform a task.  Load balancing the team itself and how it works with what it has. Even creating things that the team will need and help it to thrive.


There it is.  We need to plan… we start out with one.  Agile also tells us that this is the starting place, and we cherish our ability to adapt and alter that plan as the struggle ensues.  Some of the goals remain unchanged, but the little adjustments along the way point to our ability to absorb changes as reality proves itself to be divergent from our imagination and preconceptions. The plan helps our expectations converge.  It is something that we leverage to rally the team. Typically we even have multiple levels of planning. Our coordination begins somewhere.

Help Each Other

This is one of the main reasons we are in a team.  It is also why we emphasize self-organization.  What can we do to be a part of the solution and move the team towards success. Helping drives the interaction of the team.  Trust is integral.  I sometimes have to remind members to assume good intent and focus on the goals.  No matter how hectic and chaotic the circumstances are, watching a team calmly work through the tough situations with a focus and clarity allows them to analyze and critically process.  Better decisions and great solutions will result from a team like this.  The opposite end of the spectrum is a team in a defensive or reactive mode as a loose grouping of individuals that simply do what was heard to be the loudest.  It may get you through some short term fires, but there is usually a cost to the team and organization in the longer term. Team building is the best by-product I have ever witnessed as a result of any agile program.

Tell each other what they’re doing – so people can help and support them.  

This sounds exactly like a stand-up.  Even in a larger sense how the entire team is being visible and open with the work we are doing. Especially the problems or opportunities along the way. This is how our coordination continues.  We work on our communication daily.  Being face to face is still the widest broadband form of communication around… but it may not always be feasible.  An active team usually has a buzz or chatter as tasks are worked. There is little trepidation at relaying the information of what is happening and our progress towards our goals.  Everyone here is trying to get the team ahead, through the thought-work, through the software, hardware, processes,tools…  Many people are connected by a headset as part of a team and rely on this coordination to achieve work for the team.  For teams this is another line of sight – making our work visible.  Great teams make decisions based on information passed along quickly.  It is part of their reaction time.  Going off into a mine and being isolated for a very long time may not always be in the interest of the quick pace at which a team needs to be informed, move and react. Speak up, we need ideas from everyone.

Defend each other

Now hopefully, no one on the team is being attacked physically and directly to where we need to shield our mate from the slings and arrows of outrageous fortune.  Yet there are other things to defend against. From the perspective of the author of this original list – this would include bullying.  Software is hard problem-solving. Usually instead, we are probing for work being done on the wrong thing that might not be highest priority. Providing a solution might prove too fragile, or hold us for far too long.  Defending takes the support for someone just a bit further.  Defending is the type of behavior that promotes swarming. Not everyone may start out knowing when to ask for help.   Swarming on tasks the team knows to be critical should come naturally.  What about sustainable pace?  Defending each other against burnout, or helping to ensure the quality of the code is high. Perhaps even ensuring that the acceptance criteria is well understood or that a definition of done is met. What about improving or automating some repetitive task so that another team member can contribute more?

Thinks Creatively

Great teams have a gift for this.  Innovation by it’s nature takes some risk taking, vision, drive and creative tenacity.  Seeing what could be is far more powerful than why it can’t. I often think that this is the singular most powerful characteristic someone can possess as jobs change.  The speed or the rate of technological and scientific discovery will continue to quicken and broaden.  Without creativity, the possibilities, unorthodox connections and navigation of shifting paradigms should otherwise ever prove to be a challenge. Adventure time.

My profound thank you to a growing ‘coach’ that is understanding and looking at teams in a way, that I didn’t start exploring, until I was far older.
What would make your team’s list?

That Dang Project Manager Hat

I haven’t been a Project Manager in title for, well, ages.  As a coach or Scrum Master, I should have shed that hat long ago.  And, I did(ish).  The problem is it’s still around and, when things need to GET DONE,  somehow that hat just turns back up….on my head.  Now, the good news is, I realize it and can quickly yank it off and stuff it under my chair but, seriously, I wish it would go away.  It won’t ever go completely away though and I’m still learning how to keep it firmly on the shelf.

So, why did it find its way on my head?  The group I am coaching wants to GET STARTED!  It’s awesome the excitement they all have.  They are eager, after months and months of talking, to get to work.  And, they want to run it Agile and they are leveraging SAFe.  So, before the December productivity vortex hit, we all looked at the calendar and they identified dates for their Quickstart (3 day event for everyone on the release train).  This means, there is a LOT to do.  And, the month of December is pretty much shot so, there’s about 3.5 weeks to get everything accomplished so the train is ready to leave the station.  But, there’s also a Holiday in there AND, most awesome of all, snow storms.  WOOT!

The team of people I am lucky enough to work with right now are amazing.  A massive can-do attitude.  They have overcome illness, broken down cars, two snow storms, children’s illnesses, broken pipes (for 4 people!) and a host of other things way out of their control.  They have all come together, rolled their sleeves up, opened their minds and have focused on getting ready.  They have trained, collaborated, learned, been challenged, formed as a team and had fun.  Honestly, it has been amazing to see and be a part of.  There is absolutely NOTHING this group of people can’t accomplish.  As a coach, this is heaven.  As a PM, I cannot stop thinking about all of the logistics and coordination and organization that needs to happen.  It’s not that there aren’t people working on those things.  They are.  Will it all get done?  Probably.  If something doesn’t get done, will it matter (really matter)?  Probably not.

Coach me:  ALL the right ingredients are there.  The people and the experience are what matters.

PM me:  I need to make certain there are enough post-its, flip charts, sharpies and who is getting red yarn?

Coach me:  These people will adjust.  What matters is their mentality and how they come together through this first event.

PM me:  How can they possibly come together if there aren’t enough sharpies and flip chart markers?!  And, who is printing the hand-outs?  Wait – do we even HAVE a final head count yet?

Coach me:  These guys have it.

PM me:  They have everything except the awesome colored, smelly markers.  They NEED those.

Coach me:  Shut up, PM.

PM me:  Will do – as soon as I have every minute of the day plotted out and accounted for….and confirmation on the sharpies.

So, for all of you former PMs out there who are transitioning to Scrum Master, your PM hat is never really gone.  You just have to recognize when it’s there, on your head, and take it off.  I bet, over the next 8 days, I’ll be taking that sucker off multiple times daily and apologizing to people for continuously asking them if they are certain we will have enough sharpies.

Theory of Constraints

I attended a small workshop on the ‘Theory of Constraints‘.  It is a management perspective on work introduced by E. Goldratt.  There are five steps towards minimizing waste, work in progress (WIP) , and increasing efficiency.  There are some assumptions about the system, such as only having 3 levers of control – expense of operations, throughput of the system, and inventory or WIP.

  1. Find the constraint, where things start to get backed up. Some function, process, change, etc.
  2. Exploit or Focus on the constraint. Figure out how to get the most out of it.  This draws down the WIP, and smooths out the production flow.
  3. When the constraint is elevated – the rest of the process is subordinate.  The constraint is visible, and we subjugate the rest of the flow to it’s capacity.
  4. Elevate and start improving upon the constraint’s capacity
  5. Repeat these steps to continue increasing the flow through the system.  It may even be a new place where the constraint occurs.

Just having typed… I might only keep three.

  1. Identify the bottleneck.  We need situational awareness about what is happening.  Part of this is knowing if it is temporary or a usual suspect.
  2. (You are here) – Improve this. As it is now the most important thing in the process.
  3. After some stabilization, revisit and repeat by stepping back and looking at the process as a whole.

which kind of sounds like plan, do, check.

Great teams have a way of looking at these constraints as opportunities to improve.  The workshop had a small exercise for teams of 5 people that helped each team explore and improve upon what the ‘system’ constraint was.  Manufacturing a ‘product’ that was comprised of index cards, stickers, and marker lines.   Through 4 rounds our team changed and steadily improved how and even what we did.  All in order to assemble the specialized product faster, easier, with less mistakes and without accumulating excess WIP.

There were a few thoughts that occurred along the way.  The theory can equally apply to either a push or a pull system.  Lean has taught us that pull systems are usually the better model to emulate.  Using a rope held by people as an analogy – a rope generates slack (WIP) when it is pushed forward to another person’s hand.  The rope stays  smoothly even when everyone is gently pulled along.  Scrum and Kanban are PULL type systems.  Allowing for the capacity of the team, stage, etc.

A vertical slice explores the system for constraints as well.  When taking a very thin slice from the topmost  user interface to the depths of architecture, with something very small, -we are probing for the part that was most difficult to change.  It is a form of learning, and risk reduction.  Learning about the system, and precisely where it is appropriate to improve.  Since right now this part took us the longest to implement some change with.

Finally, I wonder what constraints we may have imposed upon ourselves,  – simply by not having noticed.

How Close Was The Customer Collaboration?

So I was near a conversation that kind of went like this;

A developer was asking the actual user of his team’s software for some feedback about the product.
I was heartened to see the invitation and he had a lean in to listen better.  He was taking mental notes (I could see the gears moving) on how to make this better. The developer also explained how rare an actual customer interaction had been over the past several years. The user didn’t have much in the way positive to say about the software and was matter-of-fact in conveying that it really wasn’t all that usable and we needed some extra fields and the training needed to be a lot better – to reflect how they were using it. I watched his wonderful continued calm as the developer wasn’t at all defensive, continuing to listen. Then a third person, who thought they knew the next step, interrupted to say that the customer needed to get project funding.

This is where my head leaps in and explores.

The customer really doesn’t care about someone else’s internal processes for funding.  And at time this is going to be some organizational telekinesis that is way too big for them to tackle. The customer may feel alone – like they were left to swim in the middle of the ocean. No Hope.

There are at least three things that need to be said here ….

1)      Good job for the developer – not just to invite, ask and listen. I have the distinct impression that this will continue.  I heavily encourage it.

2)      The ‘Future funding’ is simply a stall tactic to put off our being responsible today.   There is a current project that didn’t even include the customer. Why not open that up and start inviting them to the reviews, as a first step.  Get their feedback. Developing a trust and a responsiveness with the end-user will help in all sorts of ways.  Elicit their help in building and testing it.  Now I am not saying that funding isn’t needed.  Typically however funding never really gets at all the hidden costs within an organization to get the software out the door and into the customers hands. The definition of being done means that it is fit for use.  The requirements aren’t sitting down at some desk using the software to get a job done – a person is.  We should ever cherish and understand that.  Maybe over time – the software, the job, both change. Who knows.

3)      Why would anyone want to continue funding a ‘redo’ when it wasn’t done right the first time.

Now pullback a year or more, and there is a conversation that I had with a director about his organization.  We talked about involving the customer and he wanted to hold-off on doing exactly that.  The argument went something like… my customer is internal since we develop our own software.  My customers are not going to innovate, adopt change, and discover ways to do things better.  Just put it out in the field and they will use it as we leverage external sources for creativity and innovation.

My counter was that we required a balance.  No matter how creative we are, if software isn’t usable – then we have a great big point of failure once we’ve deployed.  The mix of this balance might be slim in the beginning as we learn to work together.  20/80 or even say 10/90 but if we just absolutely brick a Berlin wall and shut out or silo the left hand from the right – we are going to miss the inevitable handshake that is coming.  Over the course of the next year, took a while to grow that relationship.  As the new teams learned from the experienced field about the app, they also grew to trust the deliverable more.  Slowly the field also started not only accepting changes but also leveraged opportunities with more suggestions.  The field started getting used to the idea of being innovative just as they were able to share their experience.

Both sides were far richer for the interaction.  Expectant convergence about the end-results were also happening more often.

What also started to happen was that the teams were increasingly aware of Everything it took to move software through the organization and into the customers hands.  Processes started improving. Requests for infrastructure were aligned to support business objectives.

It is my experience it takes a while to move some big things like an entire organization.  You do it by being part of the culture and then changing it.  A little at a time.  Some things catch on and sometimes you even have a motivational brush fire within an organization that started from a just a few sparks.  The fire within us, helps us along whatever journey we have.

The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books, Part Three


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.

Story Time

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.

Problems Schmoblems

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,
But nicely,
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:

  1. Log into Jira.
  2. Have mild panic attack as I encounter 300+ user stories, most of which I don’t understand.
  3. 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.”

(Thank you Matt Damon and Edward Norton!)

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.

Why Bother?

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.

Listen with your eyes…

I find I take far more cues from what I see rather than what I hear.  Long ago, a coach asked me why my communication “style” would change mid-flight and I explained.  When I would see scrunchy faces, raised eyebrows, lip biting or any kind of facial cue I would immediately jump to “I’m doing or saying something wrong”.  The coach encouraged me to ask rather than assume.  I know…it’s a crazy idea.  Honestly, it did seem a little crazy though because the chance was someone would feel as though they were being called out.  It could result in a very uncomfortable situation for that person and for me.  All of that said, we talked about it some more and I said I would give it a try.  I did and have continued to experiment.  Here’s what I have learned to do (so far):

  • Ask for permission.  I let people know I have a tendency to read facial expressions.   Generally I do this by calling out the fact my own face reflects what I’m thinking and I may ask people questions based on what I’m seeing rather than what I’m hearing. I ask if it’s OK for me to do this as well as say it’s perfectly acceptable to tell me it’s not.
  • Determine if it’s appropriate.  When I do see something that makes me want to ask a question or learn more, I think (quickly) if it’s appropriate or not.  For example, if it looks like something isn’t jiving, asking a question is a good thing.  Same thing if it looks like someone doesn’t agree.  Both situations can benefit the larger group with learning or some good discussion and sharing different points of view.  Plus, more than once, I have learned something very, very valuable to apply to the future.  If, on the other hand, someone looks hurt or ticked, I wait and speak to the person individually.
  • Ask with an open mind, heart and sincerity.  It kind of goes like this:  “Bob, I’m seeing a scrunchy face.  I just want to check to see if there’s something you want dig into some more or if I’m not saying something very well.”
  • Allow for an escape route.  The reason I ask a close-ended question is so the person can easily say no and I can easily get back to it.   Also, I ask the question in such a way as whatever is happening is MINE.
  • Thank the person.  I try, really hard, to thank the person for letting me “pick” on them as well for helping make the conversation. training or whatever richer.

This “tool” has been great to get training classes of people who don’t know each other well to open up some more and generate some energy.  It’s also good with teams who  are forming or teams who are having trouble communicating.  I’ve also noticed people in classes and teams will start to do this with each other.  And, they will do it right back to me.  Like I said, what I think is on my face and people will call me out when I have a scrunchy face too.

I’m so grateful to the coach who picked up on this tendency of mine and guided me on how to leverage it over ignoring it.  So much communication happens that can’t be heard.  I mean, how often do we have to filter what we say out of fear of some unintended ramification?  Granted it’s a pretty vulnerable place to be and, if you try this, remember you are putting them there.  Also, if you read this and realize you don’t pay much attention to what you see and rely much more on what you hear, try to observe the team when you’re not in front of them by sticking your headphones in, listening to some music and just watching them.  Jot down what you’re thinking, pull the headphones out and validate with your ears what you heard with your eyes.

Scrum and Kanban

We run across informative books that tell us just a bit more.  Henrik Kniberg and his coauthor Mattias Skarin  have just such a publication with Kanban and Scrum – Making the Most of Both.  It is a great reference with many examples.  When I started having individuals and teams and ask for the differences between Scrum and Kanban, I wanted to help them by explaining the impact of choosing either. Once I was sure that a team didn’t just want to adopt kanban in order to hide from a scrum master, we were ready to explore the impact of going with one, the other or a mixture of both (Scrumban).  The 3 columns below were a reminder for making a good comparison.  The choice however also included some consideration for the organization and where we ultimately wanted to grow. Hopefully it serves to help the conversation you may have with that team along their agile journey.




Start with Retrospectives

Never stop experimenting

  • Fear vs. empowered
  • Mistakes vs. failures
  • Continuous Improvement

Feedback +/- Long vs. Short

  • Too Long may make it hard to find a root cause
  • Too Short may cause thrashing with no process stabilization

A Short History of Kanban:

1950’s Edward Deming a quality focused statistical process control person form the US is in Japan doing work for the Government.  Taichi Ohno who creates the Toyota Production System (TPS) is similarly working on Just In Time (JIT) and Lean Manufacturing methods.    Kanban results from this crucible of ideas in time.  Both Edward and Taichi die in the 1990’s when Lean Manufacturing is gaining popularity in the US.  Kanban means ‘signal board’ in Japanese.  It is a tool to help drive out waste.  A pull of inventory and work is preferred over a push.  The signal board helps to communicate work in progress and the state of this work.

Muda    – ‘waste’

7 kinds of waste are identified [They still hold relevance from a manufacturing world to an IT world – Read the book “The Phoenix Project” for more comparisons between the two]

T – Transportation [Today I put this in terms of COMMUNICATION TRANSPORTAION – how many emails, tools notes and days have passed rather than just stopping over or pairing up and getting it straight]
I – Inventory [maybe this is license usage, capacity, ]
M – Motion [meetings that weren’t useful]
W – Waiting [Time, feedback lags, process completion]
O – Over processing [duplication of effort in code, replication in different tools or the organization]
O – Overproduction [producing things the customer didn’t want and didn’t align with expectation]
D – Defects [!!!]

Mura     – ‘unevenness’ – [making the peaks and valleys a bit more level with shared resources or load balancing]
Muri      – ‘overburden’ – [still speaks to sustainable pace today]

A Short History of Scrum:

In 1986 Ikujiro Nonaka and Hirotaka Takeuchi write a reactionary paper called the “New NEW Product Development”.  In it, they note that the team behavior that works best is very scrum-like.  This is in reference to the sport of Rugby.  In the 1990’s in the US, Jeff Sutherland and then Ken Schwaber, start experimenting with software development teams and keep this inspirational terminology.

The New Product Owner’s Survival Guide: Stuff We Don’t Get From Coaches, Courses, and Books, Part Two


Welcome to Grand Central Station

I began making products way back in the Pre-Agile-ite Era in the History of Software Development—roughly the mid-1980s to the mid-1990s. I realized early on that what I enjoyed most was being in the middle of it all, working with developers, designers, marketing, management, end users—the list never ended and I liked that a lot.

In the bright shiny world of contemporary Agile software development, being a Product Owner is even better in this regard because “the middle of it all” is more precisely defined. There are fewer turf wars to fight; everyone knows (or should know) why you’re in a particular meeting asking particular questions.

My last project was the biggest I have ever been on (100+ people, $75 million budget, 18 months to v1.0). I had what I now think of as “the full-on enterprise Agile experience”. I was in the middle of it all and there was a lot more “all” than I had ever been in the middle of before. I felt like I was going to work every day at Grand Central Station.

A Metaphor

Grand Central Station is where everybody goes to get from where they are to where they need to be. The Product Owner is the person everyone goes to to get the product from where it is to where it needs to be. Waves of humanity flow constantly through the Product Owner just as they might flow through a person standing in the middle of Grand Central Station at rush hour. The trick is not to control the flow but to know the flow and direct the flow with as little friction as possible so that everything ends up at its appointed destination.

Product ownership is a game of expectations: When will it ship? What resources are required? How do we know that our idea of MVP will be our users’ idea of MVP?. But it’s not about expectations management. It’s not “under promise and over deliver”. It’s “answer questions and tell the truth.” Why is truth-telling better than expectations management? Because expectations management is dishonest by definition.

At some point your dishonesty will be exposed and you will lose the trust and support you need to be successful. The worst thing that can happen if you tell the truth is that some people may not like the truth when you tell it to them. But telling people that their train has been delayed and will arrive an hour late is far better than allowing them to believe it is arriving on time and dealing with every story they make up about you when it doesn’t.

Another Metaphor?

There’s a view of Product Ownership as “running the show”: You are not conducting trains, you are the conductor of The Software Development Symphony Orchestra. Your backlog is the score. Your stories cue the players. You face the music when it comes to stakeholder and management interactions.

This is a valid take on the PO role. But it’s not one I like because the POs I’ve seen who work this way tend to be more competitive than collaborative. The “PO as Conductor” metaphor smells to me of ego and eccentricity, of command and control. It tends to set the PO above and apart from the project, just as the conductor of an orchestra stands on a platform above and apart from the players.

Any time you think you’re in charge of anything, think again. You’re the Product Owner, not the Product President, Commander and Chief of the Armed Product Forces, or master of the Bully Product Pulpit. To me, this “commanding” or “conducting” way of thinking is bad for relationships. And relationships are the currency of successful Product Ownership.

Relationships or Transactions?

It’s tempting to view your work as a huge series of transactions: taking stories to the team, getting requirements from the stakeholder, accepting stories from engineers, giving sprint demos, and so on—each has a built-in quid pro quo, simple trade of services from provider to provider: you do your job, everyone does theirs, we all go home happy. This is the fantasyland view of Product Ownership that you’ll often find in books and courses.

Real life, as we all know, is a bit more complicated. It’s tempting to see the work of Product Ownership as simply trading quid for quo all the time and not worrying too much about who you’re trading with. Everything’s a transaction, nothing’s personal; it’s cut and dried, black and white, professional, reasonable, rational—no emotional labor required.

Sounds perfect, right? But it’s not. The truth of transactional product ownership is that all transactions are not created equal; some are harder than others, and others are simply impossible.

In the quid pro quo approach, there are going to be times when you don’t have the quid to trade for the quo. There are times when there are no consumers for what you are trying to sell (a new stakeholder-demanded feature, a new goal from management) and no providers of what you would like to buy (a little more time, budget, or even just an extra dev server). In these situations, transactions cannot go through.

This is when projects—and sometimes careers—grind to a halt. Need a favor from someone? Can’t get it. Need the stakeholder to see reason? Not gonna happen. Need management to back off? Fuhgedaboutit.

In a transactional approach, when stakeholders want functionality that could drastically change scope, there’s no easy way to give it to them. When management seeks to impose unworkable time and budget constraints, knee-jerk capitulation will make your team think you’re a jerk. When your engineers are running on empty, and you need them to go the extra mile, no quid pro quo buying a few pizzas and some Mountain Dew isn’t going to cut it; the only reason they’ll go the distance is because you ask them to and because they know you’d never ask if it didn’t matter.

In these kinds of situations—and you’ll be in them all the time—the only sustainable strategy is to leverage relationships. But you can do this only to the extent that such leverage exists. And it doesn’t exist unless you create it—early and often.

Stakeholders have a right to demand anything they want. So does management. And you won’t make your team do anything they don’t really want to do because, among other things, you don’t control the actions of your teams; Agile organizations are much flatter than traditional organizations. It may seem like you are “in charge” of your team but you’re not; the team is in charge of itself.

Handling Product Ownership as a series of transactions puts you in the position of endless negotiating, promise-making, cajoling, coercing, and capitulating. Things like excellence, engagement, collaboration, contribution, meaning, satisfaction, aspiration—all the things that really matter to people—will not be found, at least not easily.

Instead of working for everyone else, or trying to get everyone else to work for you, it’s better to work with everyone one else. The success of this approach is predicated almost entirely on the quality of the relationships you establish with people. But if true success is what you seek, this is the work you’ll undertake to achieve it.

Back to the Station

Getting thousands of people and hundreds of trains where they want to go seems like a challenge that cries out for processes and tools. But shift happens. Dates change. Budgets don’t balance. Stuff breaks down. Things fall apart. The center does not hold. The world tilts off its axis. And then you have to go to a person and work with them to right it—with no tricks, tools, or trades, just a strong relationship you will desperately need in order to get things back on track.

Living at your laptop, running Rally like a rockstar, is great. But even the best laid plans of the best POs often go awry. This is when your key relationships become the key to your success. Everything comes and goes through Grand Central Station. At virtually every moment, you will find yourself in between one or more parties and one or more other parties. It’s better to be between good relationships than between rocks and hard places.

Roles and Relationships

As Agile scales up to the up to the enterprise, we begin to see it formalize. And as it becomes more formalized, it becomes less Agile. There is nothing wrong with this; it’s just what happens. When we’re one happy little scrum team working in our happy little startup garage, we have more flexibility. But when we are 100 or 1000, we pay a cost for working at scale, and that cost is usually some degree of agility.

That being said, this loss of agility is compensated for by tremendous gains in capacity. We may not do things as nimbly as we could if we were small but we can do things we would never be able to do at all because they are just so big that one team of eight or ten people simply can’t get everything done.

Agile at enterprise scale, therefore, is heavily role-based. As such, people can seem like interchangeable parts. For the organization itself, this has obvious appeal. But it doesn’t produce optimal results in the long run because strict role-based formalisms are antithetical to the Agile mindset. When Agile becomes formalized, it ceases to be agile.

In highly formalized systems, we have to look harder for ways to improve outcomes beyond the point of formalization. Processes and tools, systems and structures tend to play themselves out over time. In the worst cases, they ossify and are rendered useless because new and badly needed changes can’t be operationalized quickly enough to meet the demands of a highly competitive marketplace and a rapidly changing world.

So how do we deal with this? Where do we find the Deus ex Machina, (the “soul of a new machine” as Tracy Kidder coined it) from where comes the magical, mystical agent of intervention that restarts the engine of change, rejuvenates a geriatric system, and restores lost agility?


The difference is in the quality of the human relationships we have. Better relationships equals better results through agreements kept, friction reduced, and increased workplace satisfaction that is the catalyst of greater productivity. Strong working relationships make up for the loss of agility as we take Agile to scale because relationships transcend roles. Strong relationships bring out the best in each of us by increasing our personal agility. And it is this increase in personal agility at the micro level that replaces and even exceeds organizational agility lost at the macro level.

What follows are brief thoughts about the common roles you’ll encounter and the uncommon relationships you will build. We will explore each of these roles in more depth in future installments of this series.

PO to Scrum Master

Requirements come through you to the engineers on your team via your Scrum Master.

Your relationship with your Scrum Master should be your closest relationship. Reach agreement early about how to work well together. Talk about the kind of team you want to grow and how your combined and well-coordinated actions might best serve that end. The Scrum Master provides technical leadership and management expertise but this is not the totality of leadership expertise required for success.

Seek to complement each other for the good of the team and the success of the project. Work closely but respect the “What/How Line”, that often blurry demarcation between WHAT you ask your team to build and HOW they go about building it.

Always stay on your side. But always seek to understand their side to the extent that they know you appreciate the incredibly intense, ridiculously demanding, and supremely stressful situations in which they find themselves almost every sprint.These are the people who do the work. These are the people who always have skin in the game, reputation on the line, and fat in the fryer.

How do you achieve this high degree of synergy with your Scrum Master? By cultivating a co-equal relationship grounded in respect: for your Scrum Master, respect for what needs to get done; for you, transparency for what can get done. This is where your personal agility will be tested most often. Be flexible, open, and always working toward agreement.

Pay close attention to how your Scrum Master excels at consistently moving your team forward and continually optimizing its efficiency and effectiveness. This is the essence of what great Scrum Masters do and it is often what they take the greatest pride in. Look for it. Notice it. Inquire about it. Make sure your Scrum Master knows how much you appreciate it.

PO to Engineer

Code comes to the project through you via engineers and the ritual of story acceptance.

To accept stories with confidence, you need to be able to ask many questions of an engineer without casting aspersions, causing offense, or creating some kind of warped accountability process or compliance task.

In most cases, you won’t be able to see what’s going on under the hood. So how will you really know if the story is done? You’ll go through Definition of Done, of course. But even here, there are ways for stories not to be done and for you not to know this.

The relationship you need with your engineers is one that is characterized by safety and clarity of intention, a relationship where any question you ask is phrased as sincere interest on your part regarding their contribution and skill so that it is perceived as inquiry not indictment. To be truly successful, create relationships where you have made it clear that it is always safe for engineers to disclose things to you about code quality, tech debt, or risk and never have that information used against them.

Many engineers pride themselves on mastery. They write clean code. They are precise. They sweat the details.That means you don’t have to. Thank them for it. Treat them as trustworthy by default. Frequently express your appreciation of the knowledge and conscientiousness they bring to their work.

PO to QA

Validated functionality comes to the product through you from QA.

If you have embedded QA on your team, you have an extraordinary opportunity to have good acceptance criteria translated into great testing. It is well worth an hour or two listening to a thoughtful QA person talk about his or her approach to testing a story. But you won’t get that much of that this person’s attention unless he or she knows how much it matters to you and how much you appreciate the time your QA person is giving up to give you greater assurance in the validity of the work you own and represent to stakeholders, management, and the organization as a whole.

Think about it this way: when you go to do your sprint demo, you vouch for the fact that new functionality exists. For the PO to say, “We completed our sprint!” is, in a sense, to give your word that the work has not only been completed but validated as well.
This implies the delivery of defect-free functionality. Even though we know there are always defects, we don’t stand up in front of stakeholders and management and present completed stories that might have big holes in them. How do you know the holes are plugged? Your QA tells you they’re plugged and you trust your QA implicitly because you have the kind of relationship where that level of trust is possible.

The point of pride for many QA people is rigor. Rigorous testing catches defects early. Thorough and rigorous testing catches more defects even earlier. Take the time to understand how your QA person thinks about rigor and breadth of coverage. For Product Owners, life is always about the Happy Path. For QA folks it’s always about the bumpy road. Show them how much you appreciate their willingness to live that rocky ride so you don’t have to.

PO to Stakeholder

Work comes to the team through you from the stakeholder.

This is the classic Agile relationship. In theory, the PO is the stakeholder’s advocate on the project. While technically true, and often the best stance for making sure stakeholders get what they want. It’s an incomplete perspective for making sure stakeholders get what they need.

What stakeholders say they want isn’t always what they need because they don’t just want functionality, they also want certainty. You are their advocate, yes. But you act responsibly in that advocacy by advocating for things because they are right and because they are possible, not just because your stakeholder wants them.

While your stakeholder may certainly know more about their own challenges and goals than you do, no stakeholder knows enough about the range of possible solutions to solve their problems optimally. If they did, they wouldn’t need a Product Owner to help them render their requirements. The mere fact of your existence is proof that the stakeholder alone is not fully prepared to dictate every aspect of the product.

Instead of an advocate, think of yourself as a mediator. You want all parties to come together in agreement that the right thing has been made the right way. Insulate your team from stakeholder concerns; insulate your stakeholder from team operation. You want the stakeholder to consider your team a very capable and reliable “black box”. Stakeholders have enough anxiety; they don’t need to be wondering if your team can execute, and they certainly should never be tempted to wonder about how well your team is executing.

Stakeholders care about getting what they want, the way they want it, when they want it. The key to dealing with this type of uncompromising demand is clarity. You want your stakeholders to be very, very clear. So notice when they are and thank them for it. Encourage clarity at all times. Look for patterns in your interactions where clarity emerges by default and seek to repeat those patterns. Take responsibility for situations where stakeholders might not be clear by guiding them to clarity. Take the lead by being clear yourself, not as a way of diminishing or manipulating your stakeholders, but as a way of ensuring that your stakeholders really do get what they want.

PO to Architect

Great risks are mitigated, and great rewards are won through you via clear communication with your architect.

If you are very fortunate, you will have an embedded architect. This person can help you understand the past, clarify the present, and predict the future better than anyone else. Or your architect can render inscrutable all that your team has done, is doing, and will ever do.

This person can be your greatest teacher and most valued advisor. Or he or she can be an aloof genius who doesn’t have the time or the interest to tell you anything about what’s really going on.

How this plays out is entirely up to you and how hard you want to work to create and sustain a strong personal relationship that encourages your architect to share his or her thinking even when it is well beyond the limits of your expertise and the scope of your role.

Where many of us like to be appreciated for what we do, many architects like to be appreciated for how they think. Take a sincere interest in the intellectual elegance that many architects prize so highly. Ask them how they solve the problems they face, how they resolve and wrestle with the myriad tradeoffs that always exist between one way of doing things and all the other ways.

PO to Management

Organizational goals are achieved through you via directives from management.

Can management tell you what to do? Of course it can. It told you to be a Product Owner, right? So what happens when management puts on the pressure? You have to absorb it so it doesn’t hinder your team or trouble your stakeholder. (If management is your stakeholder, you have double duty here.)

Management pressure is serious pressure. So the only sustainable strategy is to have ways of alleviating it. And all of those ways will come from the quality of the relationship you build and maintain.

Regardless of how formally and at arm’s length your manager may want to treat you, you need to have a close relationship with this person because there will be many times when you will have to say, “No” and have “No” be an acceptable answer.

Respecting the “No” from a subordinate occurs only if both parties respect each other—as human beings on a planet not as slots in an org chart. You can’t own your product if someone owns you. The only way to beat the tyranny of the org chart is to develop peer relationships with people who are, technically, not your peers.

This requires getting to know people, and letting yourself be known to them, in ways that extend beyond the the structures and strictures of the organization. This is not breaking the rules; it’s making the rules. It’s changing the game from its zero-sum default to a more promising win-win reality.

Management’s reward comes from results. But along the way, management usually wants to be appreciated for the qualIty of its stewardship. Keep that in mind as you form the foundation of your relationship.

PO to PO

Unexpected work comes through you to your team from other POs.

In a large project, with many teams and many POs, this is your most interesting and often your most valuable relationship.

There will come times when one team cannot complete its work, or when one part of a system to which a particular team has been assigned generates more than one team’s worth of requirements.

The over-burdened team is just as likely to be yours as someone else’s. When that happens, you will need to be able to go to one of your PO peers and ask them to take a story or two from your backlog. The only way that people will do this for you is if you demonstrate at the earliest possible opportunity that you are willing to do it for them.

You cannot arbitrarily pledge the technical resources of your team toward new and different areas, but PO-to-PO you can always offer your consideration by saying, “I’ll take it to the team and get right back to you.” If it’s not possible, it’s not possible. But it’s always possible to see if it’s possible, to show that you were open and sincere in your effort to assist.

If your relationship with your team is based on cooperation, and not coercion, you will find them more sympathetic to the needs of other teams and other Product Owners—and ultimately to the needs of the organization as a whole.

You know what motivates you as a PO so look for that and reinforce it in your PO peers. You will also find POs who are much better than you are. Study them, express your admiration for their abilities, ask them to mentor you to the extent that they are willing. For those POs who are perhaps not quite as comfortable in their role as you are, pay it forward and do the same for them.

In the the PO-to-PO relationship, think of apprenticing yourself to your practice. That is, instead of taking the reductionist view of “Product Ownership as required functional role”, take the expansive view of Product Ownership as an evolving art, something always to be practiced, never to be mastered. And then appreciate the mastery you encounter in others.

How Product Owners Get By

As a Product Owner, you go to work every day at Grand Central Station. Things can come at you, things can go around you, or things can go through you. Things that don’t go through you will come back to bite you—unless other people have your back. The only way that will happen is if you cultivate good relationships.

In modern enterprise Agile projects, Product Owners have a dizzying array of disparate responsibilities. No degree of domain knowledge, technical expertise, 24/7 work ethic, or even sheer bravado will ensure that every responsibility is met. You must have help. And you must know you have help in order to make the tough calls that you, and you alone, will have to make.

Being in “the middle of it all” is exciting. But at certain times in a project lifecycle, it’s overwhelming. At some point in almost every project, your work life will become complicated beyond chaos. Nothing will be clear or easy.There may be no good choices, no correct answers, not even half-solutions to the monstrous problems you face.

And you own the product, right? So how do you get by?

If you’re as old as I am, and you started making software in the Pre-Agile-ite Era in the History of Software Development, you probably grew up listening to The Beatles. They were, arguably, the most agile band of all time. How did they do it? They got by with a little help from their friends.