Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Parent Full thread

I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months.

It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint.

At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.

Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test?

What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.

>> 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.

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.

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.

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.

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.

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.

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.)

Sprints are meant to correlate with frequent releases. Yes, sprints are a bit weird when we are talking about such large horizons. That sounds like a square peg, round hole problem.

Yeah, I've tasted all of those pain points myself. At $work our app developers expect a working API with all the new routes and endpoints from day 0. We manage this, of course, since we're all adults by simply talking to each other. But... yeah.

Day 0 is presumably agreeing the API contract, day 2 is mocking that, day 3 is implementing tests, day 4 is coding? Hopefully they know that? :D

> Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.

You can just ship 2 days into the next sprint if you need to. You don't have to only ship at the end.

Reply on news.ycombinator.com