I stumbled on a blog by someone I hadn’t heard before. His name is Tanner Wortham and the blog is Spikes & Stories.
Here’s the link to the post: http://www.spikesandstories.com/qualities-of-great-agile-coaches/
In it Tanner explores qualities of great agile coaches with a theme of their biases:
- Bias towards learning
- Bias towards action
- Bias towards innocence
- Bias towards honesty
- Bias towards silence
- Bias towards the team
I loved the premise of the post and feel inspired to extend it a bit. So adding a few additional biases to the mix.
When I first started my agile journey, there was a small set of certifications. The Scrum Alliance was the “lead dog” in the effort. Around 2003-2004, there was only the CSM, CSPO, and CST certifications. Life was quite simple then.
Over the years, I believe folks started to get the sense that there was “money to be made” in this area. Lots of money. So certifications began to “pop up” more and more.
Much of this certification frenzy bothers me because it flies in the face of most of the agile principles. In fact, I’ve found that the money can corrupt even the best of agile trainers and coaches. But that’s not the point of this post.
My curiosity got the better of me and I wanted to see just how many certifications I could find. So here it goes...
Until they realize that:
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:
- Everyone in the class was clearly struggling with more basic skills and tactics;
- As I tried to convey more advanced topics, I realized that they really weren’t. Instead, they were based on doing the basics…well;
- And finally, the class was looking for silver bullets. That is, they wanted advanced topics that would solve all of their challenges.
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:
- Sprint #0’s
- Hardening Sprints
- Release Trains & Planning
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:
- When do you “task out” the story? Who provides estimates for the tasks? And in what units?
- How do you breakdown, estimate, and re-estimate user stories? When are you “done” estimating them?
- Story points are relative and high level – should we convert them to hours or time?
- At scale, let’s say 10-20 teams, the estimates are interconnected across some teams. How do we handle dependencies and integration?
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.
