There’s a long-awaited point in history of each development team. Weeks and months of their hard work, conveniently split into sprints, are finally about to conclude in the Holy Grail of boards, managers, and shareholders – the release. This is when all the changes and adaptations couple with technical excellence and the finished product – or just, hopefully, valuable part of it – is given into willing hands of end-users. I believe there are countless parallel universes in which things just work fine. Users are happy, sales skyrocket, and team seamlessly switches to next product. Thing is though, we live on planet Earth, which leads to a slightly different outcome.
Namely, all hell breaks loose.
At start, everything looks good. Given a proper Agile delivery, majority of major issues are already covered. Then, one day, an email hits the team’s inbox. Just one sentence, describing the action one of users attempted, with a screenshot showing the unsatisfactory result.
There are two ways the situation tends to develop from that point.
Option one: team can feel the irresistible urge to fix their masterpiece, to wipe out their moment of weakness, to right their wrong. Someone will drop whatever they’re doing and jump straight to work on the bug. Because user’s satisfaction and the value provided to them is what’s it’s all about.
Option two: team can, with their hearts bleeding, store the issue as one of the items in the backlog. Because of Scrum. Then, hopefully, a Product Owner would prioritize it properly. And then, they would work on it in the next iteration.
Both paths comprise the industry standard for teams that never tasted serious exposure to ongoing support of existing product. As you probably expect by now, both are wrong. And it’s not the worst of it yet.
Once, this way or another, they would start solving the bug, what would they actually work on? One sentence and a screenshot? What follows is a peculiar exchange of emails, ridiculously funny especially when there’s some intermediary between end user and the team.
(Agile proselytes disclaimer: Yes, I know you cannot imagine separating the team from end users. Believe me or not, inexperienced ones, it does happen every now and then. And quite often, it makes sense.)
With a problem described this way, it might take days to figure out what actually happened. And that work is done by (usually) expensive developer, who planned to deliver specific value over the iteration. And still, we’re far away from actually providing a solution, or at least a viable workaround.
And if there’s one thing users hate, that’s waiting, being stuck in limbo, without a clear idea of whether anyone is looking at their pain and making it disappear.
Now pause and reflect on the above. The bug, the issue, the problem… Yes. That’s all just a single instance.
One bug, with all the craze.
What if you had five? Or ten? Or twenty? Each of them more important than the other, of course.
Yes, it would be great to get a dedicated support team to handle such an inflow. Unless you’re a really big organization, that’s not likely to happen. It’s especially painful, when taking into account that it’s not uncommon to treat such teams and activities as a liability.
How to approach it differently?
Let’s start with some minimum criteria – either to be guarded by whoever is the interface to end-users or mailed to them as a template, if they don’t figure it out by themselves (they never do). Depending on the reality of your product, these could include:
- Product version;
- Operating system version;
- Hardware used;
- Steps leading to the fault;
- Some kind of log file;
- Impact.
The last one is pretty much the most important – based on this, you can assign priority of a bug. For example, A for complete system (or essential functionality) failure, B for reduced usability / performance, C for minor things like spelling errors. Of course, priority can always be overloaded – imagine a typo in your client’s company name. A minor fault, yet embarrassing enough to solve it as soon as possible.
But who would do that? After all, the team is all busy with their regular work, with backlog and priorities properly set – so the problem remains. Sadly, managers are most likely to blame at this point. It’s deceptively easy to lie to oneself, hoping for the best, that nothing will bug the team (sic!).
It’s like assuming gravity will not work particularly well during that daring car stunt you’re performing to impress your colleague during your midlife crisis.
Sadly, gravity always happens.
When planning the release, take that into account. Bugs, or their increase inflow, is certainty. You’re free to fool yourself if you like. Then you’re free to hire someone like me to have that mess sorted out. Odds are you live in a free country, so be my guest.
Handling the inevitable is actually quite easy. Reserve part of team’s capacity for handling incoming issues. If there’s less of them – they will take up some unplanned backlog item. If there’s more – well, being Agile, you will inspect and adapt, and reserve some more.
It’s also good to appoint someone as a gatekeeper. This person would bounce back poorly written bugs, ask clarifying questions, assign priorities based on criteria. If it’s a team role, have people rotate it. One reason is that developers have innate hatred for being stuck in support work. We all hate bugs. Second is that it makes perfect sense to expose all the team members to pains of end-users of their masterpieces. In time, they become more aware.
As Benjamin Franklin famously said, “By failing to prepare, you are preparing to fail”. If you got here, you’re likely to be prepared better than most teams are.
The only question is, will you really do anything about it?