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.

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?

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?

A seasoned director of software development was championing agile adoption at her company. It was a moderately scaled initiative, including around 100 developers, testers, project managers, BAs and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were set loose to start sprinting.

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.

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.

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.

A few years back I was coaching a large group of Scrum teams at an email marketing SaaS firm. The group had been practicing Scrum for over four years and had become a high-performance agile organization. Most of my efforts focused on fine-tuning from the perspective of an external set of eyes. Working with this organization and its development teams was a privilege.

If you read Hardening Sprints: The Good, Bad, & Downright Ugly (Part One), you know I promised to give you other contexts where hardening sprints may be appropriate. But know I am certainly not lobbying for hardening sprints to become a part of “Core Scrum: as a globally applied practice. I can clearly envision many contexts where they are not that useful or helpful.