- wrong estimations (time, impact, risk, complexity)
- bad requirements (inconsistent, incomplete, testable, conflicting, faulty)
- development involved in operations (bug analysis, data correction, deployment, hot-fixes)
- delays in development (bugs in legacy system, missing documentation)
- testing (quality/quantity of test cases, un-mockable interfaces, long running offline processes, performance issues, live and test system differ)
General problems with Scrum:
- development (gold plating, rework, misunderstandings and bugs from collective code ownership)
- estimations (missing experience, excessive estimations for unpleasant stories)
- technical debt vs. velocity (architecture violations save deadlines)
- performance (stories are functional requirements, performance is normally no acceptance criteria, often only specified as "system should be fast and responsive")
- testing (time, cost, hidden bugs, product owner focused on functionality and business value, not code quality)
- absence, outstanding feedback (illness, vacation, conflicts, laziness)
This gives some questions:
- Are all these problems exceptions or daily business in software development?
- Does Scrum deal with these problems efficiently or solve them?
- Does Scrum only work in an ideal world?
Some discussions on these topics can be found here:
- How do you apply Scrum to maintenance and legacy code improvements?
"The real key is to adapt Scrum to what your team need to be happy and productive." (team = developers)
- Couple of questions about sprint in scrum methodology
- Is collective code ownership mandatory in Scrum?
From the theoretical point of view, the main issue is synchronizing all stories and developers at the end of the sprint. Stopping a sprint for a hot-fix is quite uncommon, instead management just overloads developers. Developers are forced to hold deadlines, even if estimations tend to be wrong. This can lead to more bugs, less tests/documentation, incomplete stories, more hot-fixes, more delays, developers being idle and others being overloaded. Some people skip estimations and testing to make scheduling of deadlines easier, but quality is not for free!
Doing things like "insert at least one task to each sprint to improve the process" or "insert at least one task to each sprint to avoid the code becoming legacy code" is the way to go. Same for evaluating new technologies or tools. Other adaptions for quality in Scrum are "insert a testing sprint before the rollout" or setting up teams cross-functional, which means they should not include only developers, but also testers, configuration and requirements managers.
Feature-driven development defines features without a sprint scope and therefore has less dependencies. A feature/developer can be paused to do a hot-fix without any impact on other features. But having 2 features that depend on each other still requires completeness for both.