5 ms·
I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone
by jibe 4y ago
I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.
- Kalanos 4y agoLove it. Lots of agile benefits for devs. Less hand-wavy requirements. You get to say how long your work is going to take
- groestl 4y agoAs a senior dev I hate this. Of course I'm going to drop everything, if what I do stops making sense on an org level. Why would I do anything else.
- deleted 4y ago[deleted]
- Spoom 4y agoMaybe you've never had a project manager whose whims change with the wind, and interrupts the sprint to add yet another high priority bug in the middle that absolutely-needs-attention-right-fing-now... every sprint. Scrum tries to stop that. Of course, if your project management listens to you and trusts you, you don't have this problem, so I understand your take.
- robertlagrant 4y agoSounds like you've had an awesome career with no experience of people slamming unnecessary work into your workload, or trying to design in detail things that won't be implemented for 6 months, and will have been redesigned 5 times in that time. For everyone else, sprint backlog is a useful tool that you decide when you should violate it, and by exception only.
- commandlinefan 4y ago> Why would I do anything else Because you'll get fired if you don't...?
- spaetzleesser 4y agoI love it when something needs to be done to unblock a large group of testers but the dev team says “the sprint is closed. Come back in three weeks and we will consider it”. Truly Agile.
- alistairSH 4y agoTesting should occur within the same sprint as dev where possible - if you're throwing all work over a fence to a distinct QA team, you're doing it wrong. If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task. And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively easily articulated. Sprints work less well for greenfield development with new tech - you just end up with long strings of spikes/analysis/PoC work (it can still work, but you tend not to have concrete deliverables each sprint).
- spaetzleesser 4y ago“ if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.” That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.
- alistairSH 4y agoFair enough, that's why my second sentence is there. The scrum master/manager should be building in QA support. If they aren't, they'r failing at their job. A individual developer should never be put in the position of killing a sprint in order to support a QA team for work the dev team did last week.