3 ms·

Point 2 is very interesting. Any anecdata to corroborate?

by dfee 4y ago

shoo 4y ago
A subtlety of point 2 is that not all products or services benefit from multiple deploys per day. If each deploy creates work or risk for the customer, then beyond some point, frequent deploys may be harmful. Your customers may have more valuable things to do than consume or help QA the latest increment of your offering. Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.
ineptech 4y ago
Sure. I worked on a legacy (monolith, >5 years old, no automated test coverage) thing and managed the teams that turned it in to a modern (microservices, ci/cd, full test coverage) thing. So, kind of a naturally occurring A/B test. Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments. Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them. That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.
- scombridae 4y ago
  All you have to say is "rolling release," or "why releasing according to lunar phase is dumb." That you need to explain it the way you did is another example of the bs job creation mindset, aka, agile.
  - shoo 4y ago
    I've worked in a similar environment. The motivation to batch releases was largely driven by a desire to do full end-to-end integration testing of changes between a number of entangled backend and frontend systems. It often took days to stabilise all the components in the single pre-production staging environment used for end to end integration testing, then run through the test plan. Perform batched end-to-end testing of system was the process bottleneck. Monthly releases created similar crunch dynamics of changes being delayed by a month if they weren't stable enough to enter the monthly test cycle. Since end to end testing is the bottleneck, you don't want to feed in low quality inputs (rushed changes that are likely to cause issues and then trigger re-tests of the entire slow end to end test process). I'm not saying this is the best way to do this, it definitely isn't, but there can be some reasoning behind it.

Point 2 is very interesting. Any anecdata to corroborate?

by dfee 4y ago

Point 2 is very interesting. Any anecdata to corroborate?

shoo 4y ago

A subtlety of point 2 is that not all products or services benefit from multiple deploys per day. If each deploy creates work or risk for the customer, then beyond some point, frequent deploys may be harmful. Your customers may have more valuable things to do than consume or help QA the latest increment of your offering. Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.

ineptech 4y ago

Sure. I worked on a legacy (monolith, >5 years old, no automated test coverage) thing and managed the teams that turned it in to a modern (microservices, ci/cd, full test coverage) thing. So, kind of a naturally occurring A/B test. Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments. Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them. That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.

scombridae 4y ago
All you have to say is "rolling release," or "why releasing according to lunar phase is dumb." That you need to explain it the way you did is another example of the bs job creation mindset, aka, agile.
- shoo 4y ago
  I've worked in a similar environment. The motivation to batch releases was largely driven by a desire to do full end-to-end integration testing of changes between a number of entangled backend and frontend systems. It often took days to stabilise all the components in the single pre-production staging environment used for end to end integration testing, then run through the test plan. Perform batched end-to-end testing of system was the process bottleneck. Monthly releases created similar crunch dynamics of changes being delayed by a month if they weren't stable enough to enter the monthly test cycle. Since end to end testing is the bottleneck, you don't want to feed in low quality inputs (rushed changes that are likely to cause issues and then trigger re-tests of the entire slow end to end test process). I'm not saying this is the best way to do this, it definitely isn't, but there can be some reasoning behind it.