In my last post we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
But as I finished that article, I realized that there might be something else going on that I wanted to explore here.
In that situation, the teams’ coach assured me that conversations and escalations had happened between herself, the team, and the Product Owner. She even said she’d escalated things to the PO’s boss. She made it sound like there was a huge amount of clear feedback over the course of two full years.
Given this, they seemed to be at an insurmountable obstacle—a poorly performing Product Owner and nobody willing to do anything to improve the situation. In other words, they were stuck.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.
Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.
About a year ago my podcasting partner Josh Anderson asked me this question. To be honest, I hadn’t even heard the term before he brought it up. It inspired me to write this brief blog post for Velocity Partners.
I was hoping to get some traction on the questions I posed in the post, but I don’t believe anyone responded. This was about a year ago and I recently attended a presentation that made me reflect back on it.
Here’s a link to the original podcast.
We just finished the 2014 Raleigh Scrum Coaching Retreat in Chapel Hill, NC and I was lucky enough to participate. The event sold out months ago and was capped at 75 attendees so we could immerse in some intense working groups and Open Space sessions.
I suggested an Open Space session entitled as this post is. My inspiration was Adam Weisbart’s famous video by the same name, but targeted towards Scrum Masters. In that video, Adam and his band of actors demonstrated all of the things a good Scrum Master should do by demonstrating the things a bad Scrum Master did. He packs a tremendous number of anti-patterns into 3 ½ minutes.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition[1]. In both books I took on the topic of Backlog Grooming.
As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.
Last week I attended the Agiles Conference in Medellin Colombia. Velocity Partner’s latest office is also in Medellin, so I had the chance to hang out with some colleagues as well.
First let me tell you that this was my first trip to Medellin and Colombia. So I didn’t know what to expect. I was surprised at the altitude, the lush greenery, the cosmopolitan nature of the city, and most pleasantly surprised by the people. They were warm, fun, bright, welcoming, energetic, and engaging.
The five Core Scrum Values have been defined as:
- Commitment
- Openness
- Focus
- Respect
- Courage
The reference I’m using for this include a blog post by Mike Vizdos here. And you can see them articulated on the Scrum Alliance site here.
Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all his own. Here’s what Tobias had to say:
In my last post I ranted a bit about hearing the phrase:
“But Bob, in the real world…”
too many times in my agile travels. That it seems to infer that the agile methods are a bleeding-edge approach with limited contexts and marginal results. But nothing could be further from the truth. The methods have been leveraged for 20 years and are, at this point, solidly in the mainstream of approaches to building software.
In this follow-up post I want to challenge folks with this view. But instead of simply ranting, I want to explore some constructive approaches to overcome this mindset…
Coming to you from MARS…
Everyone please. Hold onto your seats and possibly grab a relaxing drink. I have some grave news for you. And please, please sit down.
Ok, I’ve noticed a significant trend in my training sessions, coaching, and conference conversations. The frequency of:
“But Bob, in the real world…”
My friend Lee Copeland [i]asked me the following question:
Bob,
I'm putting together a keynote talk and need some examples --
projects that were successful in the sense that they implemented the requirements, within budget and time BUT didn't return any actual value to the business.
Got anything you can share?
Thanks,
Lee
