3 ms·

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 enginee

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.
- numbsafari 8y ago
  If we can all agree that "shipping" is a feature[1] and that "shipping faster" is a competitive advantage, then "shipping fast" is probably one of the first features we should invest in as a team, from leadership to private chef. If it takes 10 people and six hours to accomplish the release of even the smallest of features, then it sounds like there's a bug with your "ship fast" feature and the team should invest some or all of its resources in fixing that. You probably can't do it over night, but you gotta chip away at it over time at the very least. If you are looking for justification backed up by real world numbers, I highly recommend the book "Accelerate" by Nicole Forsgren, et.al.[2] [1] https://a16z.com/2014/04/16/shipping-is-a-feature-some-guiding-principals-for-people-that-build-things/ https://a16z.com/2014/04/16/shipping-is-a-feature-some-guidi... [2] https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ https://www.amazon.com/Accelerate-Software-Performing-Techno...
  - beat 8y ago
    Yeah, I know. And I've read the book. But I work in enterprise devops. This is the reality of many, many teams. Which means there's a lot of unnecessary process that needs to get tossed and a lot of automation that needs to be built in order to do short iterations and get out of the 3-6 month window.
    - numbsafari 8y ago
      Me too! I feel your pain. Have you considered giving it as a gift to your peers and leadership? I really think it's a great read and resource for anyone trying to sell organizational change. I wonder if any of those "automation needs" could be turned into startup ideas?
      - beat 8y ago
        Done that, too. I actually tried a startup in the monitoring space, but sadly failed (it was great fun losing $100k or so, tho... well worth the experience!). But the automation needs problem is more a consultancy thing than a product thing. There are lots of products. Teams buy them, with the best of intentions. Lots of management wants to believe they can buy their way out of the hard problems of not having any discipline. Sigh.

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.

numbsafari 8y ago
If we can all agree that "shipping" is a feature[1] and that "shipping faster" is a competitive advantage, then "shipping fast" is probably one of the first features we should invest in as a team, from leadership to private chef. If it takes 10 people and six hours to accomplish the release of even the smallest of features, then it sounds like there's a bug with your "ship fast" feature and the team should invest some or all of its resources in fixing that. You probably can't do it over night, but you gotta chip away at it over time at the very least. If you are looking for justification backed up by real world numbers, I highly recommend the book "Accelerate" by Nicole Forsgren, et.al.[2] [1] https://a16z.com/2014/04/16/shipping-is-a-feature-some-guiding-principals-for-people-that-build-things/ https://a16z.com/2014/04/16/shipping-is-a-feature-some-guidi... [2] https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ https://www.amazon.com/Accelerate-Software-Performing-Techno...
- beat 8y ago
  Yeah, I know. And I've read the book. But I work in enterprise devops. This is the reality of many, many teams. Which means there's a lot of unnecessary process that needs to get tossed and a lot of automation that needs to be built in order to do short iterations and get out of the 3-6 month window.
  - numbsafari 8y ago
    Me too! I feel your pain. Have you considered giving it as a gift to your peers and leadership? I really think it's a great read and resource for anyone trying to sell organizational change. I wonder if any of those "automation needs" could be turned into startup ideas?
    - beat 8y ago
      Done that, too. I actually tried a startup in the monitoring space, but sadly failed (it was great fun losing $100k or so, tho... well worth the experience!). But the automation needs problem is more a consultancy thing than a product thing. There are lots of products. Teams buy them, with the best of intentions. Lots of management wants to believe they can buy their way out of the hard problems of not having any discipline. Sigh.