4 ms·

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months

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.
noirbot 4y ago
I mostly agree on this - my extension to #3 is that estimates are fine as long as when you inevitably sometimes miss your estimate, you're not held to the fire for not being a fortune teller and asked why you didn't get it done last month. I'm also not sure I agree on your take on Sprints. In my mind, the value of sprints is that they provide a barrier where you should be able to go "we already loaded all our work for the next 2 weeks. If you want something done, we'll start it in N days." Done right, sprints are your defense against "can't we just do this thing".
- ineptech 4y ago
  re: estimates: This is equivalent to saying don't confuse estimates with delivery dates, which I wholeheartedly agree with. But you also have to be willing to say "The estimate was wrong, here's a new one" sometimes. re: sprints: You don't need a barrier against "can you do this thing". If the thing is important enough, do it; if it isn't, don't. You work on whatever the top priority is, and your sprint commitment is just a list of what the priorities were, N days ago. (Edit: you do still need a PO willing to say "doing the thing would delay the other thing" though)
quickthrower2 4y ago
Point 2, even with CI/CD multiple times a day, with zero flaky tests and a sweet build time and automated test time, it sounds like you still need almost zero time between the final git push and merge to $BRANCH causing a deployment. What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am not sure that is optimal. I have not heard a reasonable solution to this, other than abandon sprints maybe? I think this stuff works wonders when at MVP stage and number of users < 10 maybe. For mature and complex products, the type I typically have worked on it is not ideal.
- ineptech 4y ago
  Obviously not all projects are the same, there are certainly pieces of software that would be disastrous to do that with, I'm just speaking generally. For reference, my (very not-startup) team is ~20 engrs in 3 teams responsible for ~30 services and we deploy stuff ~25x/wk. Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.
  - quickthrower2 4y ago
    How do you avoid mini waterfalls? At some level of granularity you are doing one thing you committed to at a time. If someone else needs to check it thats a handover. How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on. If the aim is that the right amount of work is in each sprint then naturally the last day will be busy trying to get stuff reviewed.
    - ineptech 4y ago
      Just do away with sprint commitments. Pull a new story off the backlog each time someone needs a task, and count how much you accomplished at the end of the sprint instead of guessing at the beginning.
      - 4y ago
mihaigalos 4y ago
> 1. If the people on the team can't change the process, it ain't agile Absolutely. > 2. Sprints aren't a failure of agile, they're a failure of devops. I don't think so, here's the timeline: Scrum (90s), Agile (2001), DevOps (2009). So sprints have been around a long time before DevOps, the way I interpret it. > 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months How? Your event horizon spans only the next couple of iterations, everything beyond that is pure speculation.

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.

noirbot 4y ago

I mostly agree on this - my extension to #3 is that estimates are fine as long as when you inevitably sometimes miss your estimate, you're not held to the fire for not being a fortune teller and asked why you didn't get it done last month. I'm also not sure I agree on your take on Sprints. In my mind, the value of sprints is that they provide a barrier where you should be able to go "we already loaded all our work for the next 2 weeks. If you want something done, we'll start it in N days." Done right, sprints are your defense against "can't we just do this thing".

ineptech 4y ago
re: estimates: This is equivalent to saying don't confuse estimates with delivery dates, which I wholeheartedly agree with. But you also have to be willing to say "The estimate was wrong, here's a new one" sometimes. re: sprints: You don't need a barrier against "can you do this thing". If the thing is important enough, do it; if it isn't, don't. You work on whatever the top priority is, and your sprint commitment is just a list of what the priorities were, N days ago. (Edit: you do still need a PO willing to say "doing the thing would delay the other thing" though)

quickthrower2 4y ago

Point 2, even with CI/CD multiple times a day, with zero flaky tests and a sweet build time and automated test time, it sounds like you still need almost zero time between the final git push and merge to $BRANCH causing a deployment. What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am not sure that is optimal. I have not heard a reasonable solution to this, other than abandon sprints maybe? I think this stuff works wonders when at MVP stage and number of users < 10 maybe. For mature and complex products, the type I typically have worked on it is not ideal.

ineptech 4y ago
Obviously not all projects are the same, there are certainly pieces of software that would be disastrous to do that with, I'm just speaking generally. For reference, my (very not-startup) team is ~20 engrs in 3 teams responsible for ~30 services and we deploy stuff ~25x/wk. Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.
- quickthrower2 4y ago
  How do you avoid mini waterfalls? At some level of granularity you are doing one thing you committed to at a time. If someone else needs to check it thats a handover. How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on. If the aim is that the right amount of work is in each sprint then naturally the last day will be busy trying to get stuff reviewed.
  - ineptech 4y ago
    Just do away with sprint commitments. Pull a new story off the backlog each time someone needs a task, and count how much you accomplished at the end of the sprint instead of guessing at the beginning.
    - 4y ago

mihaigalos 4y ago

> 1. If the people on the team can't change the process, it ain't agile Absolutely. > 2. Sprints aren't a failure of agile, they're a failure of devops. I don't think so, here's the timeline: Scrum (90s), Agile (2001), DevOps (2009). So sprints have been around a long time before DevOps, the way I interpret it. > 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular than months How? Your event horizon spans only the next couple of iterations, everything beyond that is pure speculation.