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.
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:
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.
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.
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.
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.
I've shared this post to be my "Go To" reference for capitalization. Thank you, Stephanie, for sharing!
Stay agile my friends,
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”.
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.
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:
- They are immersed with their customers;
- They have the time and space to be visionary and creative;
- They have true ownership over their product;
- They are receiving meaningful feedback about the performance of their products;
- They have a positive working relationship with their Scrum Master;
- They have an even better relationship with technical leads and designers;
- They are proud of what the team is delivering;
- They have embraced their constraints;
- 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.
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:
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.
In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.
I thought I’d share another story that illustrates an aspect of these ideas.
Not that long ago I was working with a client helping them understand and practice release-level planning across their Scrum teams. Some of the challenges they were having revolved around incorporating UX design work and cross-team dependencies in their projects.