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...
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.
In a previous post, I tried to create a “Call to Arms” for Scrum Coaches and Trainers to do much more than simple, team-based training. While that seems to be a great deal of our focus, I don’t think it’s creating the environment and landscape for agile methods and Scrum in particular to “Transform the world of work”.
In early May 2014, I was at the Scrum Gathering in New Orleans and hanging out with a significant part of the CST and CSC community. A great deal of the discussion on how to “Transform the world of work” is focused on training and certifications. To be honest, I’m quite disappointed on the lip service that is largely given to the world of agile coaching. And coaching “downward”, toward the team, is most of that coaching focus.
If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a book about Product Ownership and I spend a great deal of my time up to my eyeballs in stories and backlogs at various clients.
One of the things that frustrates those clients is that there are very few “prescriptive rules or firm guidance” when it comes writing stories and crafting Product Backlogs; in many ways, it’s more art than science. It’s also a practiced skill that gets better the more you actually do it—of course as a team, which is also true of agile estimation.
No is a very tricky word. I often talk about agile teams needing to “just say No” to various things. For example:
Then I’m looking for the team to say No. Whenever I bring this up in classes or presentations, I always get pushback. Always. Usually its not based on the situation, but to the word. It seems No is a word that nobody likes using in the workplace.
There’s a wonderful video by Henrik Kniberg where he explores the role of the Scrum Product Owner. In it he makes the point that the most important word that a Product Owner can use is No. That it’s incredibly easy to say – Yes to every request. To pretend that things are always feasible or easy. But that No is important. No implies that trade-off decisions need to be made on the part of the customer or the organizations leadership. That the word leads to thinking, discussion, and decision-making.
It’s sort of a chicken and egg problem in many agile teams—that is the notion of trust.
I want to explore trust in this article. I’ve done it before, but an interview by Jeff Nielsen inspired me to revisit it.
