Scrum Will Never Work
You're almost guaranteed to hear someone mutter it under their breath when it's announced that an organization is moving to Scrum methodologies. Scrum will never work here.
Myth: There are too many meetings.
Everyone hates useless meetings. I hate them too. Luckily agile meetings are time boxed focused events. If you're sitting in a daily one hour standup with forty other people, then you're doing it wrong. The daily scrum is time boxed at 15 minutes, and efficient teams should be able to get through it in five minutes. Even if something goes wrong and further discussion is needed, then only the people directly involved need to stay. Grooming sessions can be painful if everyone is just dumping user stories into a big list. If everyone has access to a release schedule, then team members can pre-groom their user stories and drop them into the appropriate future sprint. The meetings should become more efficient with every sprint.
Myth: Everyone gets to do whatever they want.
While team members are given more autonomy over how they work, they are not given complete autonomy. The scrum master and the product owner are responsible for keeping everything on track. Someone may submit a user story requesting that that the headers on the ports are green instead of blue. That may very well be a valid request; however, the product owner might decide that releasing the updated quarterly reports are more critical. The color change can sit in the backlog.
Myth: It's too hard to get everyone to agree.
How many times have planning sessions dragged out because not everyone agrees on how to weight a user story? Who cares? Let the person doing the task make the final decision. User story points are guidelines for estimating level of effort. It's not an exact science. Make use of multiple reference stories. Will the user story take more effort than 3 point task X but less than 7 point task Y? Rely on the scrum master and product owner. The developers can work on other user stories while the product owner works on clarifying requirements.
Myth: Team members are allowed to waste time and resources only to fail.
This is an exaggeration of fail fast, fail often. No one likes failure, especially frequent failure. Occasional failure is inevitable not matter what project management framework you use, and failures do not need to be catastrophic. In order to fail fast, you need to recognize failure and react accordingly. Fast fails also afford the opportunity to communicate out to key stakeholders. Something as simple as letting commitment slip a few days is a failure. The key is to learn from why the failure occurred, and come up with a plan to prevent that same failure in the future. Ideally you should never encounter the same failure mode more than once or twice.
Myth: Agile does not work for operations.
Operational teams often get a large chunk of their work load from a help desk system in the form of support tickets or incidents, and this work is often very random. Restarting a process to restore services might be an incident, but the work to find the root cause and implement a solution are definitely user stories that need to be planned. Developers get varying requests too. Not every request is push code to prod.
Just like any other major organizational change, success or failure is largely determined by the level of commitment and planning put into the change. Implementing Agile practices is no different.
