3 ms·
Wandering offtopic, perhaps, but I've noticed that this kind of behavior seems to strongly correlate with Scrum. The work starts getting rushed toward the end
by mumblemumble 3y ago
Wandering offtopic, perhaps, but I've noticed that this kind of behavior seems to strongly correlate with Scrum.
The work starts getting rushed toward the end of the sprint. Every two weeks, people start furiously cutting corners to meet a completely artificial due date. And then there's basically zero chance that you'll be able to get the PO to agree to cleaning it up in the next sprint, because they can't see the problem.
Scrum of course prescribes all sorts of adornments you can add to try and counteract this effect. But I'm a firm believer that an ounce of prevention is worth a pound of cure.
- Yoric 3y agoOh, interesting observation. Would you say it is scrum itself or just the existence of arbitrary deadlines?
- mumblemumble 3y agoI think it's the application of Scrum to work that doesn't primarily fall inside the (Cynefin) "simple" domain-type work that Scrum was designed for. It's fine if the work is straightforward and easy to estimate. But, if it isn't, things get problematic. There are three variables that interact with each other when working on a project: time, scope, and quality. If you pin down both your acceptance criteria and the time you have to implement (which is basically what happens in a sprint planning meeting), then quality is the only remaining variable you have to manipulate when things aren't going according to plan.
- JonChesterfield 3y agoThe two week rush + everything is always broken failure pattern is solvable. Given dubious project management schemes, do the refactoring and cleanup first. Then the functional change is easier to review as it's against a sane background, and there's minimal planned cleanup after in case that phase gets dropped. Call writing the tests characterisation if that helps.