If you've been developing software for any significant length of time then you have no doubt run into the term "Hotfix" at some point.
It's a fairly commonplace term, used to refer to a defect or outage in a production environment that needs to be addressed as a matter of urgency. This usually involves interrupting the current flow of work to produce a patch release to resolve the issue.
Hotfixes tend to be treated differently than other defects. The word "hot" implies a greater sense of urgency. The issue in question is normally something that was accidentally introduced in a recent release and is now causing major issues for customers.
Makes sense. However, it doesn't always look like this.
If you are working on a scrum team, encountering a hotfix might play out something like this:
Product owner notifies the team of a new ticket
They say that the ticket is being brought into the current sprint
They say that the ticket needs to be picked up immediately and pushed out in a hotfix
You may have experienced this on a number of occasions, but have you ever looked at one of those tickets and thought "hmmm this doesn't sound much like a defect to me, it sounds like a new feature"?
I have seen this numerous times. This is something of an anti-pattern that I like to call Hotfeatures.
What does a Hotfeature look like?
It's not too hard to think of an example of a ticket that might sneak its way into a sprint like this.
Let's say you are developing a medical records system, and you have a screen that displays a table of all the patients in a particular hospital.
One day, the Product Owner comes by and says "we need to push out a hotfix to paginate the patients table because hospital X has like 20,000 patients and it loads really slowly".
This isn't a defect, this isn't causing a major production outage. This sounds like a feature that probably should have been implemented a lot sooner, but now someone is complaining about it so it becomes an "urgent fix"
This brings me to my first point about hotfeatures: They are often a sign of poor prioritisation.
It is the responsibility of the Product Owner to prioritise the backlog of work and ensure that the development team is delivering the features that provide the most benefit to the customer. So if we get to the stage where they have to inject user stories mid-sprint because customers are complaining, that suggests a failure on their part.
Why does this happen?
That kind of leads into my second observation regarding hotfeatures. Specifically, what causes this behaviour? Obviously the PO is supposed to keep in mind the best interests of both the customer AND the team, so why would they do something that can have a detrimental impact on the team's productivity?
In my professional experience, a major cause of hotfeatures cropping up is difficult customers.
I'm sure you know what I mean, we all have that one customer. The one with really strict policies and stringent change processes. The one who is the first to notice when something goes wrong and is often the most vocal.
I have experienced many scenarios where a ticket is injected mid-sprint and given ultra-high priority because it's something THAT customer wants. The PO is choosing to bend to that customer's will because there is an ever-present risk that they will simply terminate their contract or subscription if they are not 100% satisfied.
I appreciate the dilemma here. The PO doesn't want to have a negative impact on the team, of course they don't. However, they also don't want to have to have an awkward conversation with the difficult customer where they have to tell them to wait for something to be delivered.
That said, I return to my original assertion: hotfeatures are fundamentally a sign of poor prioritisation. We shouldn't get to a point where customers are being blocked or otherwise negatively impacted by missing or incomplete features in the product. And that is the responsibility of the Product Owners.
What can we do about it?
My advice to any development teams experiencing this, is to call it out. The team should not have to suffer because of bad prioritisation or awkward customers who expect to be constantly pandered to. Hotfeatures may start small but it becomes a slippery slope, and before you know it, your sprint commitment no longer has any meaning. You will end up constantly carrying work over into subsequent sprints due to mid-sprint injection of work.
Raise the issue with your Product Owner. Don't let it become standard behaviour that your sprint commitment is merely a suggestion.
It. is. a. commitment.