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...
They have to sometimes say NO to some stakeholders;
They have to make decisions; short term vs. long term; tactical vs. strategic; now vs. later;
They have to peer into the future and anticipate customer needs;
They have to aggregate opinions from multiple, sometimes very powerful and unique, voices;
They have to trust their teams;
I was in a Backlog Refinement meeting the other day and you would have thought I was in divorce court where the parties were negotiating (fighting for) everything.
Each time the team asked clarifying questions around a user story, the Product Owner would begrudgingly answer. It felt like they thought they were wasting time trying to explore the story.
It was clear that what he really wanted was…an estimate.
So the team felt the pressure and stopped asking question. Instead they went immediately into Planning Poker for each story. And as you might expect, the estimates were sort of…all over the place.
Last year I scheduled a Product Ownership class that was entitled: Scrum Product Ownership 2.0. The description alluded to more advanced topics and I worked hard to weave them into the course materials and my plans.
Folks seemed to be interested in more advanced topics and I was trying to fill that need in the agile market – beyond the pervasive basic certification courses.
But something interesting happened when I delivered the class. I had three primary discoveries:
Often agile organizations take the position that the Managers, Leaders, or the Scrum Masters are responsible for keeping the team focused and energized towards their work. And yes, these roles can play a part in keeping the teams passion and energy focused towards doing great work.
But I’ve found that another role can really make a difference here as well. One that is rarely suggested for this sort of nuance. That role is the Product Owner.
To make my point, I’d like to share a dozen “opportunities” for a Scrum Product Owner to make a difference within their teams. Is the list exhaustive? Probably not. But that’s not the intent. The intent is to get Product Owners thinking outside the role of backlogs, user stories, and delivery. And instead thinking about ways where they can play a key role in the engagement, joy, energy, passion, focus, and results of their teams.
Yes, I just added another large responsibility to an already overwhelming role. Sorry about that.
I read a wonderful article the other day that surrounded some specific techniques for portfolio management.
Here’s a link to the article: http://www.infoq.com/articles/visual-portfolio-management
I immediately thought of the SAFe guidance for portfolios and just really enjoyed the simplicity and practicality of the approaches in the article.
For example, the article diagram illustrates visually how an organization is moving portfolio items from Idea…to Live or “Cash”. Clearly it’s a Kanban approach, but I don’t believe there is exhaustive analysis (business cases, etc.) for each idea. The board simply radiates the portfolio and each item moves forward based on (1) it’s on merit and (2) the organization determining that it has value.
Jason Tanner is a colleague of mine here in the Cary, NC area. He’s a Certified Scrum Trainer (CST) with the Scrum Alliance, which means he can teach certified ScrumMaster and Product Owner classes.
With that title and role comes a responsibility to stay pure to the “rules” of Scrum and its defined practices.
So, Jason will often argue with me about specific agile practices such as:
As (1) not being part of Core Scrum, and he’s certainly right about that, and (2) just being plane old bad practices. It’s here that I sometimes push back a bit on Jason, thinking that he might be a bit too purist in his approach and thinking.
But it’s all done in good humor and with respect. Or at least I think it is. But that’s beside the point.
I was reading a post from Rich Mironov that I simply had to share. Here’s a link to the post: http://www.mironov.com/8mistakes/
The title was: Eight Mistakes You’ll (Probably) Make in Your First Product Management Job.
My favorite of his eight items was #6 - Tell engineers how to solve technical problems and #8 – Confuse process steps with market steps.
You’ll want to share this with your Product Managers and Product Owners independent of their experience and role.
Rich is one of the leading voices in the “product community” and well worth listening to.
Stay agile my friends,
Bob.
As an agile coach, it seems one of the areas that teams struggle with the most is in estimation. And by estimation I’m implying some of the following:
Mishkin Berteig has published a nice overview of 9 estimation techniques. As part of this article, I will review each one from my own perspective. Some I’ve used and others I’ve not. I’ll share my own stories to compliment the techniques.
Every year I try to spend time on my own training. I usually start thinking about two things the year before:
Then I review the available courses and I’ll try to come up with 2-3 things that I’ll focus on for improvement.
This year, I’ve planned on the following:
I subscribe to Mike Cohn’s newsletter. As you would expect the value is always high and his posts usually make me think a bit about my own coaching experience and ongoing advice.
In a recent newsletter Mike adopted a position on a manager serving as a ScrumMaster that goes contrary to my experience. Here’s what he had to say:
When I first started doing Scrum, I was what we'd call today the team's ScrumMaster and product owner. But we didn't have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both.
I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.
I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP -- but I should not have been both at the same time to the same team.
