12

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?

|improve this question
10

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.

|improve this answer
6

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.

|improve this 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.

|improve this answer
  • 4
    That is absolutely incorrect. There is nothing in the Scrum Guide that says that you can't release many times a day. The Sprint cadence is about Planning, not delivery. – MrHinsh - Martin Hinshelwood Aug 1 '17 at 5:54
  • @MrHinshPST I disagree, given "Scrum Teams deliver products iteratively and incrementally". The increments are clearly the Sprints, as such that essentially means "Scrum Teams deliver products in Sprints", not "Scrum Teams plan delivery in Sprints and then deliver whenever". Of course, your mileage may vary, but that's my interpretation. – Sarov Aug 1 '17 at 13:08
  • It's worth noting that "rules" in agile are ultimately just guidelines, and teams should take whatever works from these. To focus on a team "doing strict Scrum" misses the point. All teams should consistently and constantly refine their process, but only parts that work for them. Arbitrarily forcing parts of Scrum that don't work for the team or client is counter-productive and against the spirit. If OP adds more benefit to the client by releasing 3 times in a sprint, then why on earth would they not do that? – dKen Aug 2 '17 at 8:54
  • @dKen I would argue that it is against the spirit of Agile, but not of Scrum. From the Scrum Guide: "Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." However, I do agree that that's not always the best approach. Hence why I noted that "there's no reason you specifically have to use Scrum". Scrumbut and Scrumban and Kanban are not Scrum. But sometimes they're good ideas. – Sarov Aug 2 '17 at 13:15
2

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!

|improve this answer
1

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.