Have you heard that Scrum will cure all the problems of you entire organization? Or, that you can only do Scrum and no other method? The myths surrounding Scrum and Agile development abound. Learn how to distinguish fact from fiction.
Myths One and Two
Agile development and Scrum – you’ve either heard the terms or are getting ready to apply this methodology in your own organization. But, before you start getting certified or hire someone to work on Scrum for you, you should probably learn some facts about Scrum and Agile development. There are quite a few myths that surround these processes and recognizing truth from fiction will increase your success at implementing Scrum.
First of all, you can’t just flatly say that Agile development will always deliver a project on time and within budget. While Agile development and Scrum increase the chances of a project doing this, it’s nearly impossible to say that no matter what, you’ll be able to stick the schedule and budget. Often, projects come in that are either too large or too complex to be completed by a single release date. It may take several releases to get the whole project done. And, things could arise that cause the project to become off-budget or off-schedule, including an approach that diminished the true size of the project.
And second myth of Agile is that it’s more customer-oriented. While customer feedback is welcomed and appreciated, many methods involve putting customers’ needs and wants first. This is not unique to Agile development.
Myths Three and Four
The same thing goes for team work. Scrum focuses on daily meetings, usually face-to-face, to find out how the team has progressed since the last meeting, what the team will do before the next meeting, and what problems arose that prohibited the team from meeting their goals. But, highly productive teams are not unique to agile methodology. Successful team work has been the foundation for productive output long before the Agile methodology came into development.
Another myth surrounding Agile development and Scrum is the concept that since the team delivered working software that they’re on the right track. Each release cycle delivers a working piece of software. But, this software must also coincide with a working design. Just because a section of software works right doesn’t mean that it will fit in with the rest of the software or even be what the customer wants or needs.
Myths Five and Six
Just because you use the term Agile doesn’t mean that you’re an Agile company. Many companies throw this term around only to use it as a way to confirm what they’ve always done in the past. But, using Agile methodology and Scrum doesn’t preclude other methods that have worked in the past. It’s not an all or nothing methodology. Agile methodology helps improve on methods that weren’t working in the past. But, it also emphasizes the need to use what has worked in the past with what can be achieved with Scrum and Agile methodology.
A balanced software development method is for what you’re aiming . Don’t give up on a tried and true method just for Agile. You’ll be setting yourself up for a move backward rather than a move forward.