4 ms·

How do you deal with a sudden bug in released version then? Or even bugs in the curent dev branch? All developers time is allocated to new features, there are n

How do you deal with a sudden bug in released version then? Or even bugs in the curent dev branch? All developers time is allocated to new features, there are no openings – so all the bugs are moved to the next spring automatically and we release with criticals? Edit: everyeone's answering with very good advice on how to handle it, but my intention was not to ask for advice for any situation I encountered personally, but rather as a criticism of published document. It's written as if it covered all the bases, but it doesn't cover bugs.

beat 8y ago
Apply the five whys. Why do you have a critical bug in the production release? Is is environment-specific? Did the released code not match requirements? Or were the requirements themselves wrong? It's not "What do you do about critical bugs?", it's "How do you stop having critical bugs so they don't disrupt your development process?" If criticals in production are a regular part of your life, then you're doing something wrong as an organization. But to answer the question itself... if you have a critical bug that requires enough development resources to prevent completing the iteration successfully, then the iteration is ruined. End it right there and start over with a fresh planning session. Yes, everyone will howl. Pain is your body telling you something is wrong.
- SketchySeaBeast 8y ago
  > If criticals in production are a regular part of your life, then you're doing something wrong as an organization. I believe that may be slightly idealistic - a test case doesn't get covered by the stakeholders and suddenly once the solution is in, it suddenly pops up its ugly head. It takes a ton of self-awareness and resources for a project to know its every use before it gets to the end user.
  - beat 8y ago
    One oddball case does not a "critical" make. That's part of it. Not every bug is a critical bug. Not every bug is worth wrecking your iteration over. And if you're seeing critical bugs that wreck iterations on a regular basis, we're back to my point - you're not planning very well.
numbsafari 8y ago
I've seen this handled a few different ways. What you do is going to depend on the size of your team and your current business context. Like the rest of engineering, there are few hard and fast rules, you have to weigh the trade-offs. One approach is to prioritize all bugs before all features. This is the Joel Spolsky approach. In a typical sprint-based environment, this basically means that available work effort is allocated to bugs, and only remaining work effort is allocated to new features. The Google SRE model (as I understand it) tries to moderate this by basically saying the team has some flexibility in work allocation between bugs/features unless certain SLOs are missed. When that happens, you go full Spolsky. But that doesn't really address the "what if a critical bug comes up mid-sprint". To address that, you basically adopt an on-call support model. Each sprint, one (or more, or a half, etc.) are assigned to be the support person. They triage any issues or bugs and address them as best as possible. It really helps if there is a rotation, just like your operations on-call rotation. In fact, it's best if you view this as the "escalation level" from your operational on-call rotation. You can provide a similar resource for marketing or other kinds of events as necessary. The benefit is that you have an up-front acknowledgement of the level of investment needed for responsiveness, as well as being able to provide folks with periods of interruption vs. periods of deep work, and share that burden. Lastly, I think it's really important to separate "release" from "sprint completion", especially in a SaaS environment. If you build your CI/CD and release processes around releasing at the end of the sprint, you end up building a very inflexible infrastructure. It's much better if you can release often, as work is completed. So, if you have a small feature ticket and you tackle it early in the sprint, ship it right away. If a bug comes up, release the fix as soon as it's available. I've been on too many teams where you have an inflexible release process tied to the sprint. When something comes up, it interrupts the whole flow to get something done. So, "end of sprint" != "big release".
- beat 8y ago
  Yes, small releases are a huge part of making this work. "We can't do short iterations because iterations are so much work!" is the core of resistance. Something's going to go wrong, and we have this heavy bloated religious "deployment" ceremony with ten people on a call for six hours and how on Earth could we do that once a week? Yeah. We can't do short iterations because of all the crap we do because we do long iterations. I'm always paraphrasing Kent Beck... if you can't write your requirements on a card, you need to use a smaller card.
ElBarto 8y ago
Trivial bugs can just be fixed. Non-trivial, non-urgent bugs can go to the backlog for the next sprint(s). Non-trivial, urgent bugs replace go into the current sprint, with planned dev. being kicked down to the next sprint.
sidlls 8y ago
Here's how to handle the situation you are in right now: 1. Work with the team to identify what item in the current sprint will be delayed. 2. The EM and Scrum Master should communicate the delayed issue to their leadership. 3. Identify any long-term objective that will be delayed and communicate that as well. If there's a question about why a delay will occur be honest: either the critical issue affecting customers gets fixed now, or the new thing customers don't yet have gets attention. Going forward, allocate 1 day per person in each sprint as capacity to address bugs. Do this explicitly if you have mature leadership who understand how development works, or implicitly by padding other estimates if you haven't. Addressing bugs should be an implied task every sprint. When there are no important and urgent bugs, that capacity should be used to address tech debt instead.
- golergka 8y ago
  This is good advice, but I'm already doing something along these lines and my point is that this is not covered by the OP at all. My question was not intended as asking for advice for my personal situation - it was a criticism of published document.
ElBarto 8y ago
Bugs are change requests like any others.

beat 8y ago

Apply the five whys. Why do you have a critical bug in the production release? Is is environment-specific? Did the released code not match requirements? Or were the requirements themselves wrong? It's not "What do you do about critical bugs?", it's "How do you stop having critical bugs so they don't disrupt your development process?" If criticals in production are a regular part of your life, then you're doing something wrong as an organization. But to answer the question itself... if you have a critical bug that requires enough development resources to prevent completing the iteration successfully, then the iteration is ruined. End it right there and start over with a fresh planning session. Yes, everyone will howl. Pain is your body telling you something is wrong.

SketchySeaBeast 8y ago
> If criticals in production are a regular part of your life, then you're doing something wrong as an organization. I believe that may be slightly idealistic - a test case doesn't get covered by the stakeholders and suddenly once the solution is in, it suddenly pops up its ugly head. It takes a ton of self-awareness and resources for a project to know its every use before it gets to the end user.
- beat 8y ago
  One oddball case does not a "critical" make. That's part of it. Not every bug is a critical bug. Not every bug is worth wrecking your iteration over. And if you're seeing critical bugs that wreck iterations on a regular basis, we're back to my point - you're not planning very well.

numbsafari 8y ago

I've seen this handled a few different ways. What you do is going to depend on the size of your team and your current business context. Like the rest of engineering, there are few hard and fast rules, you have to weigh the trade-offs. One approach is to prioritize all bugs before all features. This is the Joel Spolsky approach. In a typical sprint-based environment, this basically means that available work effort is allocated to bugs, and only remaining work effort is allocated to new features. The Google SRE model (as I understand it) tries to moderate this by basically saying the team has some flexibility in work allocation between bugs/features unless certain SLOs are missed. When that happens, you go full Spolsky. But that doesn't really address the "what if a critical bug comes up mid-sprint". To address that, you basically adopt an on-call support model. Each sprint, one (or more, or a half, etc.) are assigned to be the support person. They triage any issues or bugs and address them as best as possible. It really helps if there is a rotation, just like your operations on-call rotation. In fact, it's best if you view this as the "escalation level" from your operational on-call rotation. You can provide a similar resource for marketing or other kinds of events as necessary. The benefit is that you have an up-front acknowledgement of the level of investment needed for responsiveness, as well as being able to provide folks with periods of interruption vs. periods of deep work, and share that burden. Lastly, I think it's really important to separate "release" from "sprint completion", especially in a SaaS environment. If you build your CI/CD and release processes around releasing at the end of the sprint, you end up building a very inflexible infrastructure. It's much better if you can release often, as work is completed. So, if you have a small feature ticket and you tackle it early in the sprint, ship it right away. If a bug comes up, release the fix as soon as it's available. I've been on too many teams where you have an inflexible release process tied to the sprint. When something comes up, it interrupts the whole flow to get something done. So, "end of sprint" != "big release".

beat 8y ago
Yes, small releases are a huge part of making this work. "We can't do short iterations because iterations are so much work!" is the core of resistance. Something's going to go wrong, and we have this heavy bloated religious "deployment" ceremony with ten people on a call for six hours and how on Earth could we do that once a week? Yeah. We can't do short iterations because of all the crap we do because we do long iterations. I'm always paraphrasing Kent Beck... if you can't write your requirements on a card, you need to use a smaller card.

ElBarto 8y ago

Trivial bugs can just be fixed. Non-trivial, non-urgent bugs can go to the backlog for the next sprint(s). Non-trivial, urgent bugs replace go into the current sprint, with planned dev. being kicked down to the next sprint.

sidlls 8y ago

Here's how to handle the situation you are in right now: 1. Work with the team to identify what item in the current sprint will be delayed. 2. The EM and Scrum Master should communicate the delayed issue to their leadership. 3. Identify any long-term objective that will be delayed and communicate that as well. If there's a question about why a delay will occur be honest: either the critical issue affecting customers gets fixed now, or the new thing customers don't yet have gets attention. Going forward, allocate 1 day per person in each sprint as capacity to address bugs. Do this explicitly if you have mature leadership who understand how development works, or implicitly by padding other estimates if you haven't. Addressing bugs should be an implied task every sprint. When there are no important and urgent bugs, that capacity should be used to address tech debt instead.

golergka 8y ago
This is good advice, but I'm already doing something along these lines and my point is that this is not covered by the OP at all. My question was not intended as asking for advice for my personal situation - it was a criticism of published document.

ElBarto 8y ago

Bugs are change requests like any others.