3 ms·
It seems that the main and only problem "solved" by SCRUM is the awkward situation where a freelance-team or solo developer happily present the result of their
by fzeindl 3y ago
It seems that the main and only problem "solved" by SCRUM is the awkward situation where a freelance-team or solo developer happily present the result of their (web-, ux-, app-)implementation that took them half a year, the customer realizes they wanted something else and both are angry at each other.
So now SCRUM has a feedback cycle that prevents that from happening.
It makes sense for UX and interaction-heavy parts, but not at all for systems and backend programming, which are much harder to divide into a workable backlog.
- Cthulhu_ 3y agoIt makes sense for back-end too though, especially in the context of a larger organization. Teams A, B and C need features X, Y and Z from the back-end team. Back-end team says they will cost 3, 5 and 8 story points respectively. Back-end team's product owner talks to the teams to ask about priority. Z is planned for next sprint, X and Y for the one after. Teams A, B and C plan their work that depends on those features accordingly. Everybody happy. We work with SAFe where that process of inter-team dependencies are formalized in quarterly "sprints" subdivided into 3-4 3-week team sprints. That's easy enough to explain at least, it's a shame the website makes it look so bad: https://scaledagileframework.com/ https://scaledagileframework.com/
- fzeindl 3y agoI am glad to hear that you use 3-week sprints. 2 week sprints are too short, yet everyone uses them without questioning.