In my previous post, “Agile Q&A: Are there types of User Stories?” I discussed the difference between User Stories, Non-User Stories, and Spikes. During a class where Product Backlogs and Agile practices are discussed the following question typically arises…
What about defects?
Managing defects in Agile is simple. They are merely another desired option (or change) for the product. Add them to the backlog and prioritize accordingly.
I wish I could simply stop there. To be honest that statement sufficiently answers the question, but I always get a funny look or two when I provide that answer to a class or a client so I imagine you would like me to elaborate a bit as well. (I do love to ramble on…)
But what about critical production defects?
Of course there is an exception to any rule, and the idea of handling defect just like any other backlog item is no different. If there is an “oh no, the system is down we simply cannot function” sort of defect of course ‘fire-drill prioritization’ is a valid operating model and you should fix it. Any defect that is causing problems in production and impacting business operations should be addressed with a sense of urgency, we simply ask that you think about the sense of urgency with a critical eye.
Searching “Define: defect” on Google tells us…
Noun: A shortcoming, imperfection, or lack: “genetic defects”; “the property is free from defect”.
If we take that definition as is, any request to add a feature to a system is really a defect – right? Clearly the production system has a shortcoming or else we would not be asking for the new feature in the first place. So the question simply becomes… Do you work on a new feature or change the way one already in production is already working?
Additionally, we make compromises as software development professionals all the time conceding to technical limitations, the price of complexity in favor of easier options, and quite often just-get-it-done attitudes. As a result there are lots of things in production that are either not working as intended or could work much better. They are all defects. Many of them were probably coded the way we wrote them down whether or not we really wanted them to work that way in the first place. (Ahhh, the price of traditional requirements documentation.)
So, handling defects in an Agile operating model is really about re-framing the way we think about defects in the first place.
- A defect is no different than any other option for changing the system
- Add it to the backlog and prioritize it accordingly
- Fast-track any critical defects in production that are disrupting business as usual
- If necessary, use an item type of “defect” when adding it to your backlog
You mean my team has to do all the production support as well?
If you’ve been to one of our Agile Training courses then you’ve likely heard one of the Davisbase crew talk about the best practices of a Agile teams. A key aspect of the curriculum on this is the notion of “start as a team, finish as a team” and it goes along with holding the team accountable for the overall quality of the product. (That’s an opening for another few #BecomingAgile posts right there.)
Ideally, if your organization is taking a ‘product based’ mindset to organizing teams, then yes. If your team is responsible for a defined portion of the product (or the entire product) then your team should pay the price for getting something wrong. The idea of being accountable for the production support of your product is a great motivator for building it right the first time. It is far too easy for a team to get lax about code quality when they know that some other operations team is fixing all the bugs. Now, that doesn’t mean you cannot justify operations teams that are first-level support for business critical the-lights-are-out sort of defects. There is a plethora of strategies for how to break down the assignment of that work.
I’m simply suggesting that if a defect comes up in production, consider the following…
- Is it critical to have this fixed ASAP?
- If yes, then stop work in progress – move forward and fix it
- If no, keep on reading…
- Can it wait until the next release the Agile team has planned?
- If no, then consider a fast-track option for getting it done.
- If yes, then keep on reading…
- Is it more or less important than something else on that team’s currently defined Release Plan?
- If yes, then add it to the backlog in correct priority order and update the Release Plan accordingly
- If no, then simply add it to the backlog and get to it when the time is right