2 ms·
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 refe
by 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 agoHow 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 agoJust 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.
- quickthrower2 4y agoThat 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.
- ineptech 4y agoSure thing! We do still do 2-week sprints, it's just that nothing really happens when one ends and the next begins.
- hw 4y agoTry 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