One of our clients changed over to Scrum at the enterprise level. The teams had completed several sprints and one major release had taken place. I was managing the support (Operations) team. When we looked at the incidents, we could see that all kinds of issues (such as usability, performance, data issues) were raised by the business users in the incident management tool.
When we started to dig into the next level of detail, we realized that the complexity of the issues were high, a lot of effort was needed to triage the defects, and interdependencies across the subsystems were numerous. To add to all of this, these subsystems were developed and maintained by multiple vendors. To address these issues, we had to coordinate with all the vendors who were involved in subsystem development (sometimes escalated via the client PMO team to involve other concerned vendors). This was a Herculean task.
Had the client PMO team, along with the business teams, been actively involved during all the sprint demos, and had acceptance criteria been evaluated thoroughly, the situation described above could have been avoided. Though everyone (client teams, vendor teams) claimed we were following Scrum, the bottom line was that it was a classic, traditional Waterfall model, and blame games started when system went live.
Tips for avoiding such situations:
Clearly define Definition of Done (acceptance) criteria for all sprints.
Plan continuous integration and testing (including performance tests) rigorously in all the sprints.
All product owners, Scrum teams, and ScrumMasters (from both client and vendor organizations) must actively participate in sprint demos and get business feedback.