Should bug fixes be deployed as soon as they're ready?

Question

I'm changing the development methodology in my team. When I joined the company, there was no methodology whatsoever (basically, patch 'n' deploy) and in consequence we have 400k of spaghetti unmaintainable untested code.

I proposed a look into the Agile approach, and a we're doing a (quasi-)Scrum approach. Several months passed from the day I suggested releases based on sprints (rather than 3+ releases per day full of bug fixes) to the day my manager saw the benefits of this per-cycle release approach.

However, (since we have no tests nor QA and the whole thing is a legacy monolith, and) since we're mostly doing bug fixes (23 bug and UI-fixes, 2 User Stories last sprint) my manager feels it's weird we have to wait till the end of the sprint to release all those bug fixes.

I come from a background where we're usually backed up by automatic tests, and since we barely have to deal with bugs (1 or 2 bugs per sprint), we see no harm in deploying them along with big changes (like 4 or 6 user stories). So, since that is not the case in this company, should bug fixes be deployed as soon as they're done? Or should we deploy them at the end of the sprint along with the new features to maintain a commitment?

Answer 1

Regardless of framework used, the general idea is to:

• Deliver value to the client as fast as possible
• Deliver value to the client with as few bugs as possible

Agile-oriented methodologies are strongly based on automated testing as you mentioned, but you shouldn't be limiting your project just because Scrum / Agile say so.

Actually, other methodologies, like Kanban, could fit better your current model - fixes being delivered as soon as they're fixed.

It happens that, it seems you have other side questions here, such as the quality and coverage of testing. You can be delivering fast to the client, but at the cost of increasing the tech debt. If that's the case, then that's the key point you should focus on in your discussions.

Just avoid discussing 'Agile says so' and 'Kanban says that'. For end users, it simply doesn't matter much.

Answer 2

Firstly, there's no rule in Scrum (as far as I know) about not releasing finished work during a Sprint; so if those items are in the sprint, you can still potentially release them during the sprint.

Secondly, a sprint consists of work on sprint backlog items to create a finished increment. If you have bugs that emerge and are fixed during the course of a sprint, that sounds more like overhead, the same way that e.g. upgrading Rails versions would be. In that case, it might possibly make sense to exclude those items from the sprint.

Finally, being that Scrum is geared at product development, and you're not doing much of that at the moment, it might make sense to turn even more focus to getting this system cleaned up and under test, and postpone adoption of Scrum until you are ready to focus on developing your product. Scrum doesn't perform well in an environment with less-than-stellar engineering practices.

Answer 3

Sounds like you might want to look into Kanban.

Going strictly by Scrum, no, you should not ignore your Sprints and release bugfixes daily. But there's no reason you specifically have to use Scrum - in my experience, it works better for new development than for maintenance work.

Kanban, on the other hand, is a much lighter framework, involving simply a board with columns and Work In Progress limits for each column (with the exception of the first 'issue discovered' and last 'done' columns). It works much better for maintenance work where you're not concerned so much with estimation and you just want to get bugfixes out at a steady pace.

Above all, look into both Scrum and Kanban, understand their strengths and weaknesses, and bring the decision up to your Team, to allow them to decide. The best process shoved down a team's throats is often worse than a mediocre process that's fully understood and accepted.

Answer 4

Scrum doesn't either say that you cannot release during a Sprint, nor does it say that you must release after a Sprint.

But it does say that there must be a releasable increment at the end of a Sprint, and this should be made available for inspection in the Sprint Review, so that all stakeholders can inspect the changes, and provide feedback for planning the next Sprint.

A crucial aspect of Scrum is the definition of "Done". The Development Team should set a definition of "Done", which can be used to guarantee quality and ensure transparency. For these reasons, nothing should be added to the Increment if it is not "Done" (otherwise it would not be releasable).

I would say it's vital that the Development Team are helped to understand the business requirement to release regularly (if they don't already), and they should be enabled and encouraged to find a way of working that is appropriate for the needs of the business.

I would suggest that all parties consider the relative merits of releasing only after a completed Sprint, and releasing more regularly. Professionalism should mean that it's possible to find a system that optimizes quality and value.

The right decision will be dependent on the circumstances within your organization, but a core principle of Scrum is that regular releases allow greater inspection and adaption, and opportunities to gather feedback from customers.

The Sprint length should be set to match business requirements, and although opportunities to release before the Sprint end may be taken advantage of, everyone should be clear in understanding that the key responsibility of the Development Team is to produce that releasable increment at Sprint end.

Don't be afraid to try very short Sprints (e.g. 1 week, or possibly even shorter), but be aware that 2 weeks tends to be the most common, and there will probably be some interesting challenges with very short Sprints.

Be brave, experiment, inspect, adapt. Don't decide one way or another about releasing regularly, until you have enough information to make a good decision, and then when new insights come to light, be prepared to reassess, and change your mind.

Scrum on!

Answer 5

since we barely have to deal with bugs (1 or 2 bugs per sprint), we see no harm in deploying them along with big changes (like 4 or 6 user stories). So, since that is not the case in this company, should bug fixes be deployed as soon as they're done? Or should we deploy them at the end of the sprint along with the new features to maintain a commitment?

It is not about proportion between bugs and features, it is about loss and benefit. Generally speaking you must do what is the most beneficial for the company.

Select iteration period (cycle time) which maximizes income of the company. The smaller risks and costs of deployment are - the faster you can deliver. (Amazon famously deploys every 11.6 seconds on production.)

---

Also most likely you are not person making decision what to fix and when. Oversimplifying you are providing:

• Price tag and risks of each bugfix.
• Price tag and risks of deployment itself.

Most of the time you are not making decision what to do from development side. You have to provide the price tags and risks as clear and explicitly as possible for persons in charge of the company profit to make a decision what to pay and what amount of risk to accept.