Although the word agile implies flexibility, a recipe for a disastrous Scrum implementation is to cherry pick which rules, roles, and ceremonies to honor. Stakeholders must first have a command of the rules of the road before there can be a meaningful discussion on adapting them successfully.
While Scrum tackles the project management "triangle of constraints" differently from waterfall, both must contend with scope, schedule (time), and cost (resources).
Waterfall commits schedule and budget based on early, fixed scope. If one changes, all could be up for renegotiation. These changes can happen at any time.
Scrum fixes the time box (sprint length) and the resources (team membership) and leaves scope flexible until a sprint begins. It then repeats this arrangement over and over again in short cycles (e.g., every 2 weeks for a sprint, every 10 weeks for a release or program increment) to develop a predictable capacity. If team membership changes or sprint duration changes, predictability is lost and must be re-established over multiple iterations.
All meaningful measures of progress in Scrum are built on the following assumptions. These are the rules that successful Scrum implementations do not break.
Once the sprint starts, the scope is fixed. (There is some room for exception here, but it must be the exception and not the rule.)
Teams are cross-functional, 100% allocated, and stable.
Work on quality is baked in to the sprints.
Workflow (value delivery) is transparently measured.
The health of the development cycle is judged by the predictability of its overall capacity, not on its ability predict dates for any one deliverable.
If Scrum is not delivering results for your organization, look at where the organization might be exhibiting the following behaviors:
Injecting unplanned work into sprints.
Failing to populate team with the necessary skill sets or to develop T-shaped skills within the team.
Allocating team members part-time, or pulling them out of sprints.
Failing to measure progress and use burndown charts (of story points, task counts, or task time tracking) to stabilize velocity over time.
Planning by asking "when is feature x going to be done?" rather than taking ownership of the roadmap and prioritizing the program and product backlogs.