I periodically do a coaching circle as a service to our agile community. I invite anyone to it and it’s free. Think of it as a Lean Coffee format discussion with folks looking for coaching advice.
This question came up the other day:
I'd like to hear how your teams handle spikes - do spikes have acceptance criteria - yes/no? Do spikes have story points yes/no?
And it generated quite a nice discussion around the idea of spikes. And it made me think about whether I’ve ever written about them before. I was shocked to realize that I really hadn’t done a deep dive into my thoughts on spiking. Well, here goes nothing…
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.
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:
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 ;-)
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:
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.
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.
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”.
