Viewing entries in
Product Ownership

Product Owners – can / should they weigh-in on story estimates?

2 Comments

Product Owners – can / should they weigh-in on story estimates?

I engaged a contractor to come over to my home the other day to give me an estimate for doing some external work on my house. I needed some carpentry repairs to my siding, a few windows replaced, and a few repairs to my screened-in porch. 

The weather has been challenging lately in NC so the house has taken on some damage. Not too much, but I like to stay ahead of things regarding maintenance.

He gave me an estimate for his time (hours) and costs to repair each item.

I was sort of taken aback by the estimates. They seemed much longer/larger than the ones I had done on my own so I shared them with him.

When I did, he gave me a sideways stare. He said that if I wanted to do the work, then my estimates were valid. But if I wanted him to do the work, then mine were irrelevant. He noted that this is what he did for a living, that he had glowing recommendations (he did!) and that he stood by his estimates as valid.

He also mentioned that, with all due respect, I was biased. I was the customer so I saw things in a different light (easier, quicker, lower cost) then he did. He also mentioned that I had little (recent) experience ;-)

In the end, he said that I either trusted him or not. And he asked – did I want him to do the job?

I quickly apologized for my presumptuousness, and wholeheartedly said YES.

2 Comments

4 Quadrants + 1

Comment

4 Quadrants + 1

One of the product owner models that I’ve been sharing for many years is the 4-Quadrants of Product Ownership. I write about it in my new Scrum Product Ownership book and I’ve also shared it in this blog post.

But it recently struck me that I missed an important aspect of Product Ownership when I explored the quadrants.  

I think there should also be a quadrant that focuses on:

  • Self-awareness

  • Self-care

  • Personal growth & learning

  • And personal happiness

I know and can read your mind.

How in the world could I have “left out” these personal attributes? To be honest, I’m embarrassed. But that being said, it’s not too late to correct this wrong ;-)

Comment

Scrum Product Ownership, 3'rd Edition

3 Comments

Scrum Product Ownership, 3'rd Edition

Hi everyone,

I just wanted to share some great news. I’ve just completed the 3’rd Edition of my Scrum Product Owner book.

It’s been a true labor of love that’s taken far longer to finish then I’d originally expected. (sounds like software products, right?) But, to quote a common agile phrase…I am now…

DONE.

Stick a fork in it, Baby!

E-copies (PDF, EPUB, and MOBI) are all available immediately on LeanPub. What’s nice about connecting via LeanPub is that I plan on continuing to evolve content & ideas in the PDF, so it will be a way to “stay in touch” with any future developments of the books’ themes.

Also not that I’ve published several short PDF, blog link books that make it easy to explore my blog posts on 3-specific topics:

  • Agile Coaching

  • Agile Leadership

  • Product Ownership

More information on ALL of the LeanPub copies can be found here: https://leanpub.com/bookstore?search=Robert%20Galen

Amazon

You can find the paper version here: https://www.amazon.com/dp/098850264X/

And the Kindle version here: https://www.amazon.com/Scrum-Product-Ownership-Navigating-Forest-ebook/dp/B07PBGN5NW/

And here’s a link to my Amazon author page: https://www.amazon.com/kindle-dbs/entity/author/B00287V534/

Previous Owners Offer

I’d like to make the following offer for ALL Edition 1 and Edition 2 book owners. If you’ve previously purchased a paper or e-copy of my two previous editions, I’ll give you a free e-copy of the 3’rd Edition. All you have to do is drop me a note and I’ll forward you a coupon for LeanPub to get your copy.

Wrapping Up

It’s been a long time in coming, but I’m incredibly pleased with the results. I hope you pick up a copy of the new book and hope even more so that it provides value to you.

And if you do read it, please consider leaving a review on Amazon. It means so much to me to gain feedback.

Stay agile my friends,

Bob.

3 Comments

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