3 ms·

>> could have it right now if you add 2 days to the sprint. Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in

>> could have it right now if you add 2 days to the sprint. Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.

usrusr 4y ago
Do you "modulate" a sprint's length once a year, once a month or once a week? I've seen open sprints named after a pair of calendar weeks multiple months in the past. And for some reason those were still called "sprint". I'd call unwillingness to modulate rather low on the cargo cult scale.
- dolmen 4y ago
  We modulate sprint length based on resources available. There is no point to keep a strict 2 week sprint if during one week most of the team will be on vacation (ex: Christmas), so we make the sprint duration to 3 weeks.
  - b3morales 4y ago
    I am curious why you would change the duration rather than changing the workload. Sprint velocity is a ratio of both components: either can be adjusted to preserve it.
    - robertlagrant 4y ago
      Yes, changing the workload would be the normal approach. Same for if people are going to be on training courses, or the team decides they need to spend more time on training in general, so they're going to lower their workload permanently by 5%. I can imagine it becoming really hard for the team to track their velocity if the sprint length varies.
SpicyLemonZest 4y ago
I kinda feel like this shows the weakness of the concept. I’ve worked in a purported scrum model for years, and this is the first time I’ve ever heard of the idea of variable length sprints. Is there a hidden core that most people don’t implement properly, or is there no “there” there and agile consists entirely of calling the planning procedures you like “sprints”? I’ve grown increasingly skeptical of whether adopting agile even prevents the waterfall model rather than making it less legible when it happens.
- PaulHoule 4y ago
  I could care less if a team is ‘agile’ but I do care if it has practices that are effective for the group and the work that it does. If anything a good process is not about using good methods but avoiding the bad ones that predictably blindside people every time. For instance, I think the kanban concept is more basic than estimation. That is, teams that keep starting new work without finishing the old work are working very hard but get very little ‘done’. Thus you have some limit on how many tickets can be open. I know a very well run cafe where that’s the main management practice they use, only taking orders when they are running low on work in progress. My beef with estimation is that the model that ‘task A has N subtasks and you can estimate the individual subtasks and add them up’ (which works well in a certain sense) is often less correct with the model that ‘the developer sends a work unit to the tester which may or not be sent back to the developer’… in which case the most important factor for how long it takes to do work is how many times you send it off to the tester. Sometimes I dream about working with a ‘tester’ in a much more closely coupled way than I do. I always have to ‘test’ something myself to convince myself it works to avoid the embarrassment of sending something to the tester that is 100% busted. I frequently spend a huge amount of time setting up tools and environments for testing. That includes the traditional unit testing (which runs quickly) but also processes like building a full text search index for a system with a few million records, testing to see that a machine learning model builds automatically and works properly, that a full text search engine gives relevant results, or spending four hours building a database so I can run interactive queries against it. If somebody was helping out on that kind of stuff and could test stuff I do with a turnaround of minutes instead of ‘fill out a lot of paperwork and wait 2 days to 2 weeks’ I’d spend more time thinking and coding. (W/ the caveat that thinking about testing can lead to a better design more often than it leads to Test Driven Design Deformation.)

>> could have it right now if you add 2 days to the sprint. Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.

usrusr 4y ago

Do you "modulate" a sprint's length once a year, once a month or once a week? I've seen open sprints named after a pair of calendar weeks multiple months in the past. And for some reason those were still called "sprint". I'd call unwillingness to modulate rather low on the cargo cult scale.

dolmen 4y ago
We modulate sprint length based on resources available. There is no point to keep a strict 2 week sprint if during one week most of the team will be on vacation (ex: Christmas), so we make the sprint duration to 3 weeks.
- b3morales 4y ago
  I am curious why you would change the duration rather than changing the workload. Sprint velocity is a ratio of both components: either can be adjusted to preserve it.
  - robertlagrant 4y ago
    Yes, changing the workload would be the normal approach. Same for if people are going to be on training courses, or the team decides they need to spend more time on training in general, so they're going to lower their workload permanently by 5%. I can imagine it becoming really hard for the team to track their velocity if the sprint length varies.

SpicyLemonZest 4y ago

I kinda feel like this shows the weakness of the concept. I’ve worked in a purported scrum model for years, and this is the first time I’ve ever heard of the idea of variable length sprints. Is there a hidden core that most people don’t implement properly, or is there no “there” there and agile consists entirely of calling the planning procedures you like “sprints”? I’ve grown increasingly skeptical of whether adopting agile even prevents the waterfall model rather than making it less legible when it happens.

PaulHoule 4y ago
I could care less if a team is ‘agile’ but I do care if it has practices that are effective for the group and the work that it does. If anything a good process is not about using good methods but avoiding the bad ones that predictably blindside people every time. For instance, I think the kanban concept is more basic than estimation. That is, teams that keep starting new work without finishing the old work are working very hard but get very little ‘done’. Thus you have some limit on how many tickets can be open. I know a very well run cafe where that’s the main management practice they use, only taking orders when they are running low on work in progress. My beef with estimation is that the model that ‘task A has N subtasks and you can estimate the individual subtasks and add them up’ (which works well in a certain sense) is often less correct with the model that ‘the developer sends a work unit to the tester which may or not be sent back to the developer’… in which case the most important factor for how long it takes to do work is how many times you send it off to the tester. Sometimes I dream about working with a ‘tester’ in a much more closely coupled way than I do. I always have to ‘test’ something myself to convince myself it works to avoid the embarrassment of sending something to the tester that is 100% busted. I frequently spend a huge amount of time setting up tools and environments for testing. That includes the traditional unit testing (which runs quickly) but also processes like building a full text search index for a system with a few million records, testing to see that a machine learning model builds automatically and works properly, that a full text search engine gives relevant results, or spending four hours building a database so I can run interactive queries against it. If somebody was helping out on that kind of stuff and could test stuff I do with a turnaround of minutes instead of ‘fill out a lot of paperwork and wait 2 days to 2 weeks’ I’d spend more time thinking and coding. (W/ the caveat that thinking about testing can lead to a better design more often than it leads to Test Driven Design Deformation.)