Once upon a time, in a far-away land, there was a QA analyst who wanted to please both her manager and her agile team. Pleasing both seemed mutually exclusive at times. This QA analyst consulted at a client organization that thought it had implemented agile, but the result was more Scrummerfall than true agile. Often, the requests received from the manager seemed in direct conflict with the analyst’s commitments to her agile team. The analyst felt the requests not only slowed her down, but also didn’t provide much value.
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?
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?
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:
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. For example, small team practices where the results of every sprint are released, are clearly not candidates for the use of a hardening sprint. And I do believe it requires maturity and balance to use them effectively, something not all organizations are ready for.