Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Scrum is the most popular of agile methods and since agile has become mainstream it is chosen more and more often as something teams should try. No surprise we often see Scrum implementations fail.
My question is: what are the most important factors which drives Scrum adoption to failure or in other words: what has to be done correctly by a team/an organization to make Scrum implementation success?
In my opinion Scrum has quite simple rules that focus mainly on general workflow and team organization, thus I see the following factors crucial:
Scrum itself is not enough. It isn't a prescription for the full software development process. @Pawel, I once heard you saying the same thing about Kanban - if we put the crap in, then the crap will go out of it. I would say it's totally the same with Scrum. It needs a good engineering culture behind it. So the first reason would be forgetting about that fact. Many people think that following Scrum workflow will magically result in better software, while the only thing they will get out of it will be uncovering even more serious problems about the way they make software. This leads to the second reason...
One of the most valuable properties of Scrum is that it quickly makes problems visible. But that's all. Now when adopting such a framework (like Scrum) we need to be prepared to deal with those problems. But many times teams try to either ignore them or just game the framework to keep the problems hidden. This way they create impression that everything goes fine through iterations, but in the end the blame goes to Scrum.
Finally it's about false expectations. I think the scrum adoption failures are more often spotted in the environments used to more prescriptive (not to say heavier) software development methods/processes. The false expectation is that by adopting Scrum methodology (which it is not, but just a framework) will tell us how to create software better. Our organization will become faster, we will have a better quality code, and we will do all that with a lower budget. While Scrum a good step towards improving the process, it's still only small piece of the puzzle.
There is however a lot of generalization when talking about Scrum adoption (including my own answer ;-)), while the framework is all about the context, details and collaboration to uncover the very local problems. It's also the reason why it's so hard to actually form a universal list of reasons for failing scrum adoption.
Scrum requires a very skilled project team, starting with the project manager, who manages the entire process, the product owner, the customer and the developers. In scrum, one weak link affects not only the certain stage in which it functiones, but it affects all the following iterations as well, again and again and again. Therefore, to my opinion - the most important thing when working with scrum is a strong dedication and commitment to the project by all project team members.
In addition, the following factors are important:
Good luck!
Scrum, like any methodology, fails because of a lack of leadership. When there is no leadership from outside or from within the team, Scrum fails. The idea that letting a team "self-organise" will solve all problems is a myth. Self-organisation doesn't happen out of the blue. It needs leadership. If there is no leadership from within the team, and the 'outside' (i.e. management) has left the team on its own to "self-organise", it just won't work. You can find all kinds of excuses, but its the lack of leadership that makes it fail.
So make sure your new Scrum team has sufficient support and guidance, before it is left to run the show on its own.
One thing I want to add to Tsiki Azuz requirements: Not only dedication and commitment to the project by all project team members, but also by both the customers and even more important the company management!
I am very convinced that this does not only require agreement, but explicitly stated and executed commitment from the management.
To that extend, adoption of Scrum is not anyhow different than any other change in organizational structure or approach, which in my understanding all require clear and executed commitment from the management.
Culture and paradigm shifts are necessary.
Development Teams need to self-organize, break out of their roles, and work together. Coders must assist with testing and documentation. Testers must work with coders to improve code coverage early in the Sprint. Communication is key.
Management needs to trust and empower their Development Teams. Constantly asking for status updates is disruptive. Micromanaging individuals defeats the possible productivity gains. Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments the main obstacle in large organizations. I would personally root cause that reason to ignorance of the framework at all levels, especially executive.
The Scrum Guide must be honored. Violations, however minor, reduce the effectiveness of and therefore trust in the framework.
Scrum is not enough. Some people think that if they pass scrum master or scrum product owner certs, they will be able to ship software flawlessly. The learning doesnt stop there. The team should also learn some technical stuffs like for example from XP. I had seen a team using scrum and when the customer requirement was changed, they found out that the refactoring is very difficult because they didnt apply or didnt have the knowledge in applying OOP. In the end, they just stick to the current implementation because it will be painful to change things.
Another thing is the commitment and teamwork. There will be cases that some people in your team will be against scrum.
Scrum has hijacked Agile. In theory it's the gospel. It fails because its practical implementations in most organizations directly violate the Manifesto. It introduces repeated inefficiencies with its constructs, dilutes ownership and accountability, and gives everyone an excuse. It relegates good Agile methodologies to second class citizens while promoting droning. It ends up hiding mistakes for later flareups rather than dealing with them. The many parodies of Scrum are so funny because they are true.
