Help! There’s A Hole In The Boat!
Introduction
Let’s picture this scenario:
You are planning to go fishing by boat. You have prepared everything for weeks.
You have checked the boat to make sure it’s secure and save, prepared your fishing equipment, prepared the logistics, etc.
On the paper, you’re ready to go.
So on this awesome Saturday afternoon, you go to the harbor and start the great journey with a friend of yours with the hope that you will enjoy the great time and go home with lots of big fishes.
After 30 minutes of sailing, not even close to the fun yet, you realize something wrong is happening. The boat is leaking! There’s a hole in the boat!
What should you do?
Wait, this is suppose to be an article about Scrum, right?
How is that story related to Scrum anyway?
Stay with me 🙂 I’ll explain.
There’s A Hole In The Boat
Let’s think of it this way.
You have a project which is handled with Scrum approach.
The Sprint time box is 2 weeks.
This is your 6th sprint.
Last sprint (Sprint 5) the increment was released to production. It was tested and the team was confidence that the increment is ready to be deployed.
Unfortunately, 2 days after Sprint 6 is started, you realized that there was a bug from Sprint 5’s release.
What should you do?
Should you put the bug in the Product Backlog and work on that on Sprint 7?
Should you put the bug in the Sprint 6 Backlog and deploy it by the end of the Sprint 6?
Should you put the bug in the Sprint 6 Backlog and deploy it right away after it is solved even when Sprint 6 time frame is not yet done?
Sprint 5 increments are like your preparation for fishing, where you prepare the boat, fishing equipment and logistics.
It was all perfect, tested and ready to be deployed.
So Product Owner approved that the increment ready for market.
Sprint 6 is like when you start going for sailing.
Your sprint goal is “to have fun fishing and get lots of fishes by the next day”.
The bug from Sprint 5 is like the hole in the boat.
This is the moment where you have to decide what to do with the hole (bug). And you better decide quickly!
First Thing First
The question that’s popping up usually “Can we release to production before the time box ends?“
Ideally, we should deliver zero bug increments and ideally the release happen every time the sprint end.
But well…let’s be realistic! Flaws happen, let’s deal with it rather than whining about it.
In this kind of situation, you need to know how big is the effect of the bug – subject to the whole project – and is there any workaround to handle that bug while the team are fixing it.
Lets discuss one by one the questions raised above:
Should you put the bug in the Product Backlog and work on that on Sprint 7?
In my opinion, if the bug can wait for Sprint 7, then it is not a bug.
Most probably it is only a wrong requirement.
We’re talking about a hole in a boat! A life threatening issue!
A “red flag” system problem!
Should you put the bug in the Sprint 6 Backlog and deploy it by the end of the Sprint 6?
If workaround is available (in the boat case, the hole is small and you can just patch it without going back to the shore to fix it), then this approach might be an option.
Product Owner can suggest to put the bug fixing in the Sprint 6 Backlog and ask Development Team whether they can work on this without endangering the Sprint Goal and the quality goals do not decrease.
Development Team is the owner of the Sprint Backlog, they’re the one who will put that bug in to the backlog
Should you put the bug in the Sprint 6 Backlog and deploy it right away after it is solved even when Sprint 6 time frame is not yet done?
In this case the hole is big! Fixing it on the spot will not work.
You have to leave everything else, go back to shore, fix the hole and when it’s ready, go back sailing.
Which means, your Development Team might need to stop for a while to swarm and fix the bug, release it to production and back to work on the Sprint Backlog until the time box ends.
If you have enough number of developer in the Development Team, one or two developers can work on the bug fixing and the rest can still work on the Sprint Backlog.
Experience Is The Best Teacher
Well, Sprint 6 is tiring, huh?
Satisfying sprint goal, fixing bug, etc.
Now we’re on the end of the time box. As always, this is the time for Sprint Retrospective.
I would suggest you to use this event to retrospect and plan for the action the team must take to avoid this kind of things happen again.
The team need to be more careful in developing, unit testing, system testing and also user testing.
Product Owner needs to be more careful in deciding whether the increments are ready for deployment or not.
Scrum Master must make sure that the team are doing the practice correctly or not.
Conclusion
There’s no exact solution for this.
The condition you’re having on the field will determine the solution you need to take.
Mistakes are stepping stones to Success
Plan for more accurate testing during the coming sprints to avoid “hole in the boat scenario” happen again.
For the question “Can we release to production before the time box ends?“
I would say “YES” but it’s not the best approach and definitely the very last option that you can use.
It’s like your “emergency money” that you can only spend if something really terrible happen.
Nobody wants to have a terrible thing, right?
good article, easy to understand
Thanks yodha 🙂
In my experience its depends on the bugs severity. If it’s critical, you need to fix the bugs right away and have it deployed to the production, because your customer cannot wait til the end of the sprint – usually the development team call it as an hotfix.
Bugs can be categorized as the something that still has a workaround and can wait until the release or the next sprint :). If you’re development team use gitflow versioning mechanism, you can easily categorized the error as the hotfix and bugs and applied to different version of source code, so it will not mix up 🙂
Thanks for your input pak made
Cool
thanks deny 🙂
“For the question “Can we release to production before the time box ends?“
I would say “YES” but it’s not the best approach and definitely the very last option that you can use.
It’s like your “emergency money” that you can only spend if something really terrible happen.”
releasing the increments(including a hotfix), doesn’t have to wait the sprint timebox ends, its up to the PO’s policies and strategy. it also depends of the product type and engineering practices, skills and culture in the organization. for several companies, frequent and/or daily release can be better because it shortening the feedback cycle. just my 2 cents 😀
Agree dayu 🙂
Thanks for the sharing.
This question was actually raised by someone in a workgroup and I found that interesting to be put here since many people think that Scrum can only deliver after the sprint ends.
Great article, thanks for sharing!
I haven’t had any experience in implementing scrum and just beginning to learn more about it for my own benefit so it’s always good to hear stories from those who have implemented it and experience how it is!
Thanks bagaskara