Viewing entries in
Product Ownership

Here we go again, picking on the poor Product Owner

Comment

Here we go again, picking on the poor Product Owner

Joshua Kerievsky recently wrote a post entitled Eliminating the Product Owner role. As of December 3, 2018, it had received 766 likes and 162 comments on LinkedIn.

https://www.linkedin.com/pulse/eliminating-product-owner-role-joshua-kerievsky/

The opening premise of Joshua’s article is here:

Before I get into who or what would replace the PO role, let me offer a bit of background on this group. Three coaches, including myself, had assessed this group prior to beginning work with them. Our findings were typical:

  • Too much technical debt was slowing development to a crawl

  • There was insufficient clarity on what needed to be built

  • The developers spent little time with their Product Owner

  • The team was scattered around a building, not co-located

  • etc.

When you perform numerous assessments of teams or departments in many industries, you tend to see patterns. The above issues are common. We've worked out solutions to these problems eons ago. The challenge is whether people want to embrace change and actually solve their problems. This group apparently was hungry enough to want change.

So, springing from this problem statement, Josh makes the point that if you: 

Comment

Let’s Eradicate Bad Product Ownership, part-2

1 Comment

Let’s Eradicate Bad Product Ownership, part-2

This is a continuation of Bad Product Ownership anti-patterns that I’ve seen all too often. And that I would encourage you and your organizations to avoid.

Without more context setting, let’s get onto the patterns –

You might be a BAD Product Owner IF you…

Too often revert to explore how and how long, over focusing on the what

It’s probably human nature.

When I ask a contractor to come over to my home to estimate fixing a problem. I usually focus on how long it will take them and how they will approach the repair.

1 Comment

Let’s Eradicate Bad Product Ownership, part-1

3 Comments

Let’s Eradicate Bad Product Ownership, part-1

Mike Cottmeyer has been one of my longer-term colleagues in the agile community. He’s built a nice coaching business in the Atlanta area and has been contributing his ideas for quite some time. He’s someone that, when he writes something, I usually read it.

I don’t always agree with Mike. But that’s ok. He always makes me think (or rethink) differently and that’s quite valuable to me. I like to be challenged.

He recently wrote a blog post entitled: Kanban Isn’t The Answer To Bad Product Ownership. In it, he made the case the title implies. And he made it quite convincingly. But the post also made me consider a couple of things:

  1. How fundamentally important the Product Owner role is. Specifically, in Scrum, but generally in agile teams. I’ve seen the difference that an excellent Product Owner can make to a team. And conversely, the damage “bad ones” can do.

  2. And lament the number of bad product owners (organizational, group, and individuals) that I’ve seen in my own coaching travels.

So, in this piece, I want to explore some of the You might be a bad product owner, IF… patterns that I’ve seen. In the hopes that we might be able to avoid some of them.

3 Comments

How does "Documentation" Fit into Agile?

Comment

How does "Documentation" Fit into Agile?

I've been teaching, coaching, and speaking about agile approaches for over 15 years in conferences all over the world. 

In that time, there are a set of questions that everyone seems to be concerned about. I think the top 5 might include the following:

  1. What tools do you recommend we use for tracking our teams?
  2. How do we estimate fixed scope / fixed time projects with agile?
  3. How do I fit my current metrics / KPI dashboard into our agile teams?
  4. Do you really need a ScrumMaster and/or Product Owner? And if so, what do they do?
  5. How does documentation work? We're in a regulated environment and agile doesn't support documentation.

And as time goes on, the frequency of the questions hasn't really declined. So, they're still relevant and indicative of things folks are grappling with in their understanding of agility.

A week or so ago I came across a blog post from Angela Wick entitled - Agile Requirements Documentation - What's Really Needed?

It's the most cogent and common sense answer to #5 above that I've ever seen. And if you know me, when I reference another blog, I usually have something to add or a point or two I disagree with. With Angela's piece, there wasn't a point I couldn't agree with.

It's now my "Go To" reference for folks who are struggling with the questions around -

  • What are agile requirements documents?
  • How much is enough?
  • What to write and what not to write?
  • What should be the focus? 
  • Who writes it?

and any other questions from my clients. Please read her entire blog. You'll find insights and value that will be helpful in your agile journey!

Stay agile my friends,

Bob.

 

 

Comment

Agile Software Capitalization...Boring!

Comment

Agile Software Capitalization...Boring!

One of the topics that I've typically avoided at agile conferences and in discussions with colleagues is software capitalization. Particularly in agile contexts.

The first reason is that it's usually used as an excuse to undermine agile principles and as a means of continuing old practices. 

The second is that I find it somewhat...boring. Yes, it's often necessary for many enterprise or larger-scale contexts. But I'd rather the teams focus on innovation, customer value, and deliver than on capitalization.

And the third reason, which is somewhat embarrassing, is that I never had a succinct recommendation for folks on how to handle it in agile contexts. I always felt that I said "it depends" too often.

Excuses

But all of those reactions were excuses. And I do realize that it's a serious topic for many folks. So, imagine my delight when I came across a real-world blog post from Stephanie Davis of Valpak in Tampa Florida that explained how they've been handling it. 

And not only that, the post contains some reference post that nicely provides additional capitalization examples and advice.

Wrapping Up

I've shared this post to be my "Go To" reference for capitalization. Thank you, Stephanie, for sharing!

Stay agile my friends,

Bob.

Comment

Value – Revisited

Comment

Value – Revisited

In the Agile Product space there are a few figures who are leading the way.

Jeff Patton – leads the way from an innovation and creativity perspective. Jeff’s storymapping technique is being used nearly everywhere to gain additional perspectives of backlogs beyond a simple list of requirements.

Ellen Gottesdiener – leads the way from a traditional requirements mapping perspective. Ellen has a strong Business Analysis background. As agile matured, she joined that approach and has added much in the way of mapping traditional analysis to agile analysis.

David Hussman – has partnered with Jeff Patton on many an occasion in his storymapping workshops. David has the uncanny ability to “see beyond” our current approaches and to keep us ground in “what matters”, while reminding us to ever challenge our staid approaches.

Roman Pichler – leads the way from a Product Ownership perspective. He focuses on valuation, forecasting, and roadmapping. I’ve always felt that my product ownership book focuses more towards the tactical role and Roman’s on the strategic. It doesn’t that that he’s a prolific contributor to the space.

And finally, Marty Cohen – leads the way helping us understand the nuance of Product Management as it related to agile products and Scrum Product Ownership. This is often an underexplored area in agile and Marty brings deep experience in Product Management, with an “agile slant”.

Comment

Chartering, Lift-off, Setting the Stage, From the Beginning…

1 Comment

Chartering, Lift-off, Setting the Stage, From the Beginning…

One of my favorite, old-time rock groups is Emerson Lake and Palmer. And their song From the Beginning seemed appropriate for this article.

One of my new favorite voices in our agile community is Sandy Mamoli out of New Zealand. I’ve read oodles and oodles of her work, but I have yet to see her in person. Fingers crossed, I get that chance soon.

One of the more interesting things that Sandy is focusing on is team self-selection when it comes to how to organize around projects and work. Recently Sandy wrote a piece entitled: Giving Teams the Best Start.

In it she emphasizes the work that Ainsley Nies and Diana Larson have done in their book Liftoff, which just released its second edition.

1 Comment

Product Owners – Are you “Happy”?

Comment

Product Owners – Are you “Happy”?

In his latest newsletter, Len Lagestee wrote about Even Happier Product Owners. The piece shared 9 conditions of happiness for the Product Owner. Here’s a link to the blog post.

And here’s the list:

  1. They are immersed with their customers;
  2. They have the time and space to be visionary and creative;
  3. They have true ownership over their product;
  4. They are receiving meaningful feedback about the performance of their products;
  5. They have a positive working relationship with their Scrum Master;
  6. They have an even better relationship with technical leads and designers;
  7. They are proud of what the team is delivering;
  8. They have embraced their constraints;
  9. And, they are keeping themselves healthy.

I really like Len’s list as a baseline for the happiness and performance of the Product Owner role. I’d like to compare the list against my 4-Quadrants of the Product Owner role model.

Comment

Definition of Ready as an Anti-pattern

2 Comments

Definition of Ready as an Anti-pattern

Mike Cohn in a recent newsletter entitled: The Dangers of Definition of Ready made some solid points that have had me “thinking” ever since I read it.

You see, I’ve been a proponent of DoR for at least the past five years or longer in my coaching. I often “couple” the discussion with two areas:

  • Definition of Done
  • And as an “exit criteria” for Backlog Refinement

I actually consider DoR to be one of the healthier agile practices and I often recommend it to my clients. So I read Mike’s cautionary article with some trepidation. Hoping that I haven’t been misleading my clients in some way.

I’ve captured Mike’s exception to DoR in the below snippet from his post:

2 Comments

Innovation: “Management” vs. “Team” Responsibility

Comment

Innovation: “Management” vs. “Team” Responsibility

I just read a truly interesting HBR article that focused on the role of management versus team members themselves in fostering an environment of creativity and innovation.

Most of the discussions today in this space, at least in my experience, are focused towards leadership or management being responsible for innovation. That is – in setting up the environment

Very little of the focus is team ward. In that, the team bears some responsibility for its own behavior, energy, and focus towards innovation.

The HBR article had some survey data that puts “the blame” squarely on both shoulders – that of “management” and the “team” in establishing the right climate.

In my view, that’s the right focus since we all play a part in creating an environment of experimentation, innovation, and creativity.

Comment