two people figures carved out of wood with the word coaching spelt out on scrabble tiles


I’ve been doing more pairing lately. Much more. But, more specifically pair-coaching.

I’ve been pairing in my conference workshops and talks, quite a bit, with Mary Thorn on the agile quality and testing side of things. I’m also pairing with Josh Anderson on our Meta-cast and I’ve done a few presentations with him. Very enjoyable.

I’ve also been pairing more in my writing. For years, I’ve been a lone wolf writer. Nobody but myself saw my writing before it entered the light of day. Now, I’m learning the value of having reviewers and editors. Second opinions matter. A second set of eyes matter. Having a partner in your endeavors can be quite a bit of fun.

programmer from behind fixing bugs found in the programming code on the computer monitor

Bugs, Bugs, and More Bugs! (Part Two)

Do you Count Bugs as Part of Your Velocity?
Again, it depends.

If you size your bug stories as part of your backlog refinement, then yes, they are planned for a sprint and result in velocity.

However, there is a potential dilemma. For example, what if you are building a story and find bugs related to your design and coding efforts? As you find those bugs, do you log them and consider them stories? Or are they simply related to the original (parent) story and repairing the bugs is part of the original implementation effort estimate?

Programming code abstract screen of software developer.

Bugs, Bugs, and More Bugs! (Part One)

In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics. But certain themes form a Top 10 topics list everyone seems interested in.

One of those items is how to handle bugs. I get questions like:

Do you estimate bugs (planning poker – points)?
Are bugs equivalent to stories?
When do you file a bug while sprinting?
Do you count bugs as part of your velocity?
Can you deliver a story in a sprint with bugs still open?

Many arms reaching for helping hand

The Agile Project Manager – Please Sir, May I Have Some Help? (Part Two)

As promised in Part One of this blog, we will now explore the differences between doing Agile and being Agile as well as provide helpful advice on how to ask for help.

One of the biggest challenges I find in my coaching is Agile teams not asking for help. Often teams get a brief sense of Agile methods and dive in before they truly know what they’re doing.

Part of the problem is the inherent simplicity of the methods themselves. On the surface, everything sounds so easy. All you need is:

Colleagues discussing using digital tablet and laptop

The Agile Project Manager – Fail NOW as a Strategy (Part Two)

This is the second installment of a two-part series, as promised in Part One, this blog will discuss how to embrace failure as a way to help your teams reach greater success.

Continuing with my earlier coaching example from Part One, I remember talking to a group of our Scrum Masters at an old employer. If you don’t know about Scrum, the Scrum Master is the primary coach and guide and agile leadership voice within the agile scrum team. They’re also responsible for maintaining core agile values within the team and for the team’s overall performance.

Two people brainstorming and writing on white board

The Agile Project Manager – Fail NOW as a Strategy (Part One)

I was at a conference not long ago speaking on and sharing various agile topics. After one of my presentations, a young man stopped me to ask a few questions. We struck up a nice conversation that eventually discussing sprint dynamics within Scrum teams. I mentioned that I usually coach teams toward declaring their sprints a success…or (pause for meaningful effect) …a failure.

I do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s). He was visibly upset with my view. He said they (he worked at a well-known Atlanta company) had never failed a sprint. Never! They could not, nor would not, use that WORD in their culture.

Picture of software code with a puzzle on top of it

Refactoring and Technical Debt: It’s Not a Choice, It’s a Responsibility (Part Two)

If you read part one, Refactoring and Technical Debt: It’s Not a Choice, It’s a Responsibility, you should be familiar with my thoughts on technical debt and refactoring. Now we will explore the different types of strategies for refactoring.

I have used a set of strategies quite effectively to combat technical debt and inspire refactoring in several companies.

There is no succinct silver bullet. However, if you apply the following with persistence, you will be well on your way to delivering more sound and robust products.