Let’s Eradicate Bad Product Ownership, part-1

3 Comments

Let’s Eradicate Bad Product Ownership, part-1

Mike Cottmeyer has been one of my longer-term colleagues in the agile community. He’s built a nice coaching business in the Atlanta area and has been contributing his ideas for quite some time. He’s someone that, when he writes something, I usually read it.

I don’t always agree with Mike. But that’s ok. He always makes me think (or rethink) differently and that’s quite valuable to me. I like to be challenged.

He recently wrote a blog post entitled: Kanban Isn’t The Answer To Bad Product Ownership. In it, he made the case the title implies. And he made it quite convincingly. But the post also made me consider a couple of things:

  1. How fundamentally important the Product Owner role is. Specifically, in Scrum, but generally in agile teams. I’ve seen the difference that an excellent Product Owner can make to a team. And conversely, the damage “bad ones” can do.

  2. And lament the number of bad product owners (organizational, group, and individuals) that I’ve seen in my own coaching travels.

So, in this piece, I want to explore some of the You might be a bad product owner, IF… patterns that I’ve seen. In the hopes that we might be able to avoid some of them.

3 Comments

Is Agile in Late Adoption Stage?

4 Comments

Is Agile in Late Adoption Stage?

I wrote a coaching article a while ago that illustrated an agile coaching anti-pattern. It was quite well-read and I received quite a bit of feedback on it.

One of the folks who responded was Mick Maguire.

https://www.linkedin.com/feed/update/urn:li:activity:6345281715686166528
A great article by Bob Galen, he shines a light on an all too common pattern, especially among the late adopter market that we are in these days... My advice... If you are about to engage agile coaching, and you don't want to waste (a very big pile of) your money, make sure the first conversations are "what does success look like?" and "How will we know if we are getting there?...”

I’m not focusing on the coaching part of his reply, but more so reacting to this entry level statement:

“Especially among the late adopter market that we are in these days…”

Mick’s comment has stuck with me since I read his reply. Making me think about Geoffrey Moore’s, Crossing the Chasm and where the agile (movement, methods, frameworks, etc.) might be on that scale.

4 Comments

Making Technical Debt, well…Visible

Comment

Making Technical Debt, well…Visible

Julee Everett and Ryan Ripley shared a wonderful article on making technical debt more visible. In that article, they focus on visual metrics that illustrate progress in cleaning up debt.

I’d encourage you to read it.

Inspired!

The article also made me think a bit about my own experience with technical debt and how to influence the organization to take it more seriously. Here are some advice tidbits to make your technical debt more visible –

Comment

My Heros: Mike Cohn

5 Comments

My Heros: Mike Cohn

There are individuals who have influenced my professional journey significantly. Sometimes, by working with me directly. Other times, by their writing or position in our software community. And other times, simply as a role model.

I've started a segment on my blog called – My Heroes. I’ll post intermittently, perhaps every 1-2 months. But it serves as a reminder to me to be thoughtful and appreciative of the folks who’ve influenced my growth and skills. And of course, they get none of the credit for my many foibles.

The fourth one up is: Mike Cohn

Mike is one of those folks in the agile community that influences things without taking an obnoxious or too controversial stand. He's supremely experienced, is very pragmatic, and simply shares what has worked for him. 

I first "met" Mike by reading his books. He wrote two of the most influential books in the "early days" of Scrum and agile. 

these books were seminal at the time when many of us were really struggling with agile requirements (user stories) and agile planning.  From my point-of-view, they were game-changing in providing practical guidance and advice for agile teams when it was needed the most.

5 Comments

Stop Norming & Performing!

2 Comments

Stop Norming & Performing!

Perhaps it’s just me, but I’ve been indoctrinated into the Tuckman Model as THE view or model when it comes to team maturation and overall health.

You all remember Tuckman, don’t you?

He presented the following stages:

  1. Forming,
  2. Storming,
  3. Norming,
  4. and Performing
  5. sometimes Adjourning

that teams go through in their evolution to a solidly performing state.

One of the things that it’s influenced in my coaching and leadership style is the predilection to honor the team. That is, once a team is formed and performing, I am loathed to break them up for whatever reason. Even good reasons like the business priorities have changed or there is a desperate need for the skills of one team member in another team. Or even, the team has some dysfunctional relationships brewing.

2 Comments

Can ScrumMasters Remove (Non-functioning) Team Members?

2 Comments

Can ScrumMasters Remove (Non-functioning) Team Members?

I’ve been teaching and coaching Scrum for nearly 20 years. During that time, I’ve always tried to stay true to the basic Scrum guidance and the Scrum Guide. But I’ve also shared my own practical experience.

One of the things that I’ve been consistent about in my guidance is that the ScrumMaster is NOT a manager or HR role. That is, they should not be “mucking around” with personnel performance issues. At least not directly.

For example, they should not be writing/executing Performance Improvement Plans (PIPs) or removing folks from teams or firing folks.

So, you can imagine my shock & chagrin when I saw an article by Barry Overeem that seemed to be saying the opposite. Now I’ve followed Barry for many years and I normally align with his recommendations. Or at least I see the soundness in his perspective. And often he simply makes me think about things in new ways. Which I appreciate.

But in this case, I think this is a very dangerous point of view and flat out wrong. So, let me share my thoughts…

2 Comments

Back to Agile Basics

2 Comments

Back to Agile Basics

There’s been a movement afoot in the agile community for a while. It’s about getting back to basics. I characterize it as:

  • Agile leadership is nice, but…
  • Agile planning & forecasting is nice, but…
  • Agile Project Managers are great, but…
  • All the certifications are nice, but…
  • Scaling frameworks are nice, but…
  • Accenture, Gartner, etc. interest is nice, but…
  • DevOps and Business Agility are nice, but…
  • Adoption, transformation, etc. are nice, but…
  • Making $billions is nice, but…

We’ve lost the essence of agility. We’ve forgotten the very things that got everyone excited in the first place. The simplicity. The power of the team. The results that an engaged customer can inspire.

2 Comments

Guidance for Soliciting (Receiving) Feedback

2 Comments

Guidance for Soliciting (Receiving) Feedback

We’ve all been there. Someone walks up to you in the hallway, musters up their courage and gives the gift that keeps on giving – direct, thoughtful, feedback.

In this case, I’m presuming it’s constructive or otherwise challenging feedback to share with you. And if you’re a leader within the organization, you have to realize that it was probably hard for them to muster the courage to give you that feedback. Let’s say it’s critical.

Or conversely, you're walking down the hall and run into a colleague. And you ask them for feedback on how you're handling yourself in a critical agile project. As a leader. Again, they muster up their courage and share honest and open feedback with you.

So, what is the next thing you do?

Of course, you don’t:

  • Consider it a gift;
  • Thoughtfully digest it;
  • Look for the “truth” in it;
  • Thank the person for their candor;
  • Ask them for any other feedback;
  • Confirm an example that supports the feedback;
  • Ask clarifying questions to better understand the feedback.

Instead, you ask them for precise examples that support the feedback they just gave you. Probing, inquiring, and looking for direct evidence. Picture an episode of Law & Order. Clearly, putting them on the defensive and making the feedback their challenge versus your own.

If you’ve followed my writing, you know that I’m quite enamored with Kim Scott and her Radical Candor book. (check out another post here) I saw this blogs picture on a LinkedIn post and it inspired me to write this short reply.

The "Gift"

Whenever someone gives you constructive feedback, you want to consider it a gift. Don’t challenge them. And don't ask them for "supporting evidence".

Instead, simply accept it and consider it. Most of the time, it’s the gift that keeps on giving.

Stay agile my friends,

Bob.

2 Comments

Forget about setting goals?

Comment

Forget about setting goals?

For years and years, I've been a strong advocate of goal-setting within your agile teams. Ares where I think goals are important include:

  • At the daily stand, focusing the conversations towards the teams' goals;
  • During sprint planning and at the sprint review, focus towards the sprint goal;
  • If you're doing releases, ala SAFe release trains or a similar mechanism, then having a release-level goal is important;
  • To me, Definition of Done and Definition of Ready, are goal-oriented. Providing clarity on the teams' constraints;

But...

Comment

Hiring a ScrumMaster?

1 Comment

Hiring a ScrumMaster?

Introduction

A colleague of mine in Dallas, Jack Schwartz, sent me an email asking the following:

Bob,

I’m working on a presentation focused towards Hiring a ScrumMaster and I wonder if you could provide some insights to the following questions:

  • What are the top skills you like to see in a good Scrum Master?
  • How can a hiring manager tell if a prospect is truly an agilest and not just using scrum words with ‘legacy’ project management? (other than clairvoyance)

Thanks,

Jack.

Well, Jack here is my initial stab at a response…

What are the top skills you like to see in a good ScrumMaster?

Well, first I’d like to say what I’m not looking for:

  • I’m not looking for someone who is strong in a functional area within the team. For example, if I’m staffing for a ScrumMaster in a team with a weak or non-existent Development Team Lead in it, I’m not looking for the SM to fill that role. Or an equivalent, PO, UX, BA, Testing, or any other role. If I have a skills gap or weakness in a team, I need to fill that with someone with those skills.

1 Comment