Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
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:
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
Whew! There, I said it, and now I feel a little bit better.
For years I’ve been coaching agile teams and one of the themes I’ve been emphasizing is:
Have all been terms that I’ve emphasized during this time. I’ve pushed and tried to inspire teams to break down the walls and tooling and to sit together to build great products.
Have you ever entered a Sprint taking on a User Story that you later regretted? For example:
I’m guessing, of course you have. I encounter these scenes in teams I’m coaching all the time. And truth be told, it’s not a terrible event. Teams make mistakes…all the time. And they usually learn from them.
