deficit-driven development
Are you familiar with the feeling of playing catch-up to an idealized vision of your company product that exists only in the mind of your product owner?
It might play out like this: someone is not happy with how a feature was implemented -- it just doesn't fit their vision of it. So a bug is created documenting how it's "wrong" and how it ought to be instead.
Because the team norms were never set on how to treat bugs versus features, every sprint is feature heavy, while bugs keep piling up.
More and more pressure is put on developers to "fix the bugs", yet developers are still expected to deliver new features. Depending on your Agile process, bugs might not even be estimated. Developers time is now fragmented with context switching, and to compound things, now also have UX, QA, and the PO interrupting their development of new features to ask about when these "bugs" might be resolved. Requests of the "personal favour" variety might start appearing.
Stop it. It's not a bug. It's an improvement.
"Oh! But it was supposed to work like this!"
If the Product Owner is unhappy with how a delivered feature works in actuality, then it's a good idea to retro how the original ticket was defined. Could it have had more clarity around the design? The acceptance criteria? Perhaps it was too light on context, and there were too many assumptions made without enough shared domain experience between product and development. Once the weak points are discovered, the team's able to move forward in the Agile spirit of iterative continuous improvement:
- Create a new ticket to capture the new work to be done.
- Link it to the previous ticket, so the team benefits from the additional context.
It's about flow of control
The cost of bug-driven-development is that you go from a one-way control flow (crucial to high-productivity team, and the basis for continuous delivery) to a bidirectional control flow where requests for work to be done arrive on the developers plate from different sides:
- from the PO as high-priority project-planned features from the product backlog, often tied to sprint objectives
- from the PO, QA, or UX as "bugs" on previous work done
Trying to achieve the sprint objectives while also trying to resolve subjective "bugs" complicates every step along the sprint. It's like trying to ride a bike with two flat tires. One flat is enough, please.
Merges and releases become exponentially more difficult. Productivity drops and the introduction of more bugs is inevitable. Morale drops as the language of "bugs" seems to imply fault on the developer.
and scope creep.
Further, teams that are automatically accepting of aribitrary "bugs" entering the backlog allow for a dangerous backdoor for allowing scope creep to enter into the project.
These bugs are often not "groomed" with the same critical eye as features entering the backlog; I've seen teams where bugs aren't even pointed! The work to be done is magically hand-waved away, and then people seem surprised when the bugs aren't resolved.
It's demoralizing to the whole team when week after week features stay open, and it's even more so when someone suggests to start a "bug grooming" ritual to help with their prioritization, only further reducing the amount of productivity hours.
So what's a bug?
A bug is something that does not pass the acceptance criteria and the team norms, including the "definition of done" for that particular piece of work. It's quite simple, yet for teams new to Agile it can be quite hard to change from previous behaviours.
Early on Agile team development cycles it's crucial that teams have enough time in their sprint to address all the factors that can pop up. It's critical that the scrum master sets the expectation that throughput will be very low while team norms and team alignment are being established.
Team norms and alignment will help the team understand what exactly a bug looks like, and how it is to be prioritized against features. If bugs can be understood not as "nice to haves" or "things we missed", but as mission-critical blockers (core functionality is broken) it's much easier to align on how bugs are always to be resolved before new features.
Things that might previously have been perceived as a bug are to be understood as "UX improvements" and "accessibility improvements" and crucially, these can all be used to further flesh out the definition of done for product features. This is one of the core strength of Agile -- for once the team understands the new definition, the team benefits from this new expectation on every subsequent sprint. The boundaries of a feature become integrated into the team as team norms, so developers can be effective in taking requirements and delivering on them autonomously.
Alternatively, having to rework a previous feature to include a "fix for a bug" which was not part of the requirements or team norms indicates that fault resides on the developer, rather than on UX, or ultimately the PO. And by not identifying the gap and reworking back into the team norms or definition of done, the team is only setting itself up for the exact same problem to come up again in a future sprint.
The way forward is a shift away from "fault" altogether: what is being described as a bug is actually an improvement or iteration. And Agile already has a process for iteration, so let's use it.
Born into debt.
Sprint teams are not created to pay off the debt of some unrealized ideal product. Instead of living in a deficit sprint-by-sprint, strive to align the team toward viewing the current state of the product (no matter how early on) is the only source of truth, and work together iteratively each sprint to increase the surplus.
An added bonus to a team mindset shift from deficit to surplus thinking is that when the real bugs are encountered, they are delt with immediately. The whole team now understands that a bugs carries debt that reduces throughput of the team, and the longer the bug exists in the backlog, the more of a compounding effect that bug has on lost productivity.