What was the single point of failure encountered when your company decided to replace the current processes with SCRUM?Can you give me some examples of things that have gone really wrong when a company tried to introduce SCRUM? I'd like to hear your anecdotes, something you experienced yourself, the big fail that you saw coming but couldn't prevent.I hear a lot of concern about missing documentation on decisions about the implementation details, and about story sizes and detail level of the stories.
What have you seen go wrong when introducing SCRUM?
scrum;failure
The biggest problem is misunderstanding. Common failures are:Only a team is doing Scrum but rest of the company (including sales, management, HR) still think in the old way. Examples:Continuous interaction with customer and customer's involvement is very important. HR has to understand that team performance is more important then performance of individuals. KPI must change to that.Feature definition is continuous process. Project definition will evolve during development by customer feedback. Because of that project deadline, required budget or result feature set can change (after approval by stakeholder). Change is part of the process. Estimation is continuous process you cannot say at the beginning of the project that you will be done with all features (many of them unknown at the beginning) within 5 months.Team is empowered to make decisions. Team makes commitment to amount of features delivered during next sprint. This cannot be demanded or commanded.Sprint is safe zone for the team. Once the team commits to some defined user stories the commitment cannot be modified outside of the team.Part of the old organization structure doesn't make sense when moving to Scrum. Scrum defines three roles: Scrum master, Product owner, team. There are other roles but these three are usually enough for delivering the application. The common non sense is having Scrum master, Team leader, product owner and one or more Project managers. Project manager and team leader are redundant roles in Scrum.Guy assigned Scrum master role is not doing Scrum master. Scrum master solves impediments. Anything that disturb team is impediment which must be solved ASAP. The most common failure is assigning this role to developer without any previous experience with Scrum. This role partially replaces common project manager but Scrum master is without power over team and Scrum master doesn't demand any features to be implemented. Scrum master guards the team even against Product owner with unrealizable requirements.Guy assigned Product owner role is not doing Product owner. Product owner has financial responsibility for the product. It is very specific and a key role to success. The role has something in common with analytic, project manager and product manager. Product owner collects and maintain requirements (usually in form of user stories). His responsibility is providing information to the team and defining priority of user stories. He should be on site with the team because cooperation between PO and the team is continuous.Changing process name to Scrum but leaving most of the process as it was in the old way. The most common scenario is that you will change from waterfall to Scrum and the most significant change is that you do not do analysis and documentation any more and you say that you Scrum.Requirements / user stories are missing definition of done - very common. If you don't have definition of done (acceptance criteria) you cannot make any assumption about complexity of user story during sprint planning. If you don't have them during sprint you cannot mark user story as completed because you cannot validate it.Quality is considered as optional. Quality in Scrum is first class citizen. We can say that each acceptance criteria should be covered by automated end-to-end test. Once you start reducing quality and adding untested features you are losing control over the product because features considered as done can stop working any time due to regression.Result of the sprint should be shippable increment (= working and tested) to the product.Edit:I'm adding important note. When using agile approach the main point is delivering the highest amount of business value to the customer as fast as possible. But the customer (represented by Product Owner) describes what is the business value. So it is not generally true that you don't have analysis or documentation when using Scrum. If customer requests analysis or documentation and mark it as business value (for example because of large scale or long term project which should be improved in next several years) you will create it as well. The most basic approach is including analysis and documentation in acceptance criteria for user stories. Analysis in such case is documented communication with the product owner in some standardized way.