You have likely heard many reasons why you should ditch waterfall methodologies for managing your projects and adopt Scrum instead. However, the following three situations are going to guarantee that scrum will not work at your company.
1) Lack of management buy-in
In order for scrum to succeed within your organization you need to have the support of management. Scrum processes and artifacts are quite different from what most managers/executives are familiar with. If your management team is not comfortable with the new process then they are likely to become an impediment (albeit an unwitting one).
Solution: If you want your management to be onboard with scrum and even champion it to other executives; you need to provide them with ammunition. In this case, the ammunition is knowledge; knowledge of the scrum processes and examples of companies which have successfully used scrum to improve their project success rate.
2) Not empowering the team
Scrum works only when the project team is empowered to use their insight and experience to make the appropriate decisions. Treating the team like a bunch of children (like many project managers do) does not motivate the team to perform to their best ability. You need your team to work at 100% and use their creativity and passion to push the project to completion.
Solution: As the scrum master you need to focus on serving the team rather than leading them. Your primary mission is to make sure the team has what they need to succeed. As the old saying goes “Give a man a fish…” well, you know the rest.
3) Viewing Scrum as a light-weight methodology
Many teams jump to Scrum because they feel that it is an approach to a project that just lets them code/build/etc. and not have to worry about processes or documentation. The teams that adopt Scrum because of this misconception are doomed to fail in their adoption of Scrum and in the execution of their projects.
Solution: Set realistic expectations that Scrum is just as rigorous as traditional methodologies. While traditional methods require a great amount of documentation, they usually offset this by reducing the amount of time the developers are in meetings and the amount of communication the team is required to create. Scrum on the other hand may reduce the initial documentation expectations, but it requires the team to be available and increase the frequency and immediacy of communication. This can be a big change to developers who sometimes camp in front of their monitor for a day or two at a time and do not talk to other team members.
While the challenges above are legitimate ones, they are by no means insurmountable. I have provided some basic ways you can counter the bad habits and situations you may encounter. Scrum is a powerful tool for creating change within an organization/project and the effort to implement it is well worth it.