Hacker News Reader

Comment by quickthrower2 | Hacker News Reader

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.

View on HN

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.

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.

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.

That sounds sensible to me! Thanks. Nice to get these perspectives as I have never heard a colleague say that before.

I guess you can then get rid of the 2 weeks? Because you can measure velocity as a continuous rolling average. Retros could be continuous too and standups already are. Grooming is easy to make continuous too.

Sure thing! We do still do 2-week sprints, it's just that nothing really happens when one ends and the next begins.

Try 3 week sprints. Or 4. ShapeUp by Basecamp recommends 6 weeks. Sticking to the same things everyone is doing is counter agile, and you should be experimenting and see what works for your team

Sounds to me that the artificial crunch is the problem. And if you have the capability to deploy quickly, I don’t see any value in sprints they tend to artificially delay deployments, reviews or retrospectives. If something needs talking about, don’t wait for a ceremony in a week and a half when everyone has forgotten about it.

I’ve been part of teams working this way without sprints and artificial crunch on mature and large scale services, so it really isn’t a MVP/startup only deal…

Separate deployment from release (Feature flags). Then you can do QA and show to stakeholders whenever in whichever environment. You can even use it for Code Review, though I prefer pair/ensemble programming to CR (better to correct things as you go than after the fact)

> What about review? Code review? QA? Showing off to stakeholders?

Take a look at Dave Farley's Continuous Delivery YouTube channel to see the answers.

I think it boils down to "don't do that" with good arguments why and how to assure quality instead.

Reply on news.ycombinator.com