Agile Development Myths and Facts

Gone are the days when software developers required detailed lists of product specifications from their clients! These days it's all about being flexible and adapting to change. And even though the Agile manifesto was published back in 2001, so it's not a new idea, many businesspeople continue to believe all sorts of Agile-related myths. Here are the most common ones.

1. Agile is easy to implement.

That's not true, especially with large development teams, who tend to resist change. Companies who want to implement the Agile operating model properly will need to dedicate a lot of time and resources to make it happen "by the book". And let's not forget that the benefits won't be instant; in fact, the delivery capability may be lower during the transition phase.

2. Teams who use Agile don't spend that much time crafting documentation.

This misconception stems from the fact that some clients misunderstand one of the Agile Manifesto guidelines: "working software over comprehensive documentation". Some people understand that this phrase means "just build great software and spend little time documenting its features". In reality, the guideline refers to the development stage of the project, stating that team members shouldn't waste their time creating comprehensive documentation while they are building the product, because some features may change, rendering parts of the documentation useless. Once that the project is done for good, it should, and it will be shipped with detailed documentation.

3. Agile doesn't require additional planning.

Scrum teams use sprints to do their work, and people tend to think that nothing will ever change during these sprints. However, if the developers are busy fixing bugs all day long, so the project doesn't progress as expected, the team will meet to create a new plan which addresses those issues.

4. Work will always fit in a sprint.

That's not true either. Many Scrum teams will break down business-focused stories into smaller tasks. This way, a story may continue for the duration of two or three sprints, for example. And even backlog items that fit into a single sprint may be broken down into subtasks.

5. Developers choose to do what they want.

Nothing could be further away from truth! The Product Owner is setting the expectations, and the entire team needs to fulfill the requests. Sure, Agile requires teamwork and collaboration, but the team needs to be disciplined as well.

6. Scrum and Kanban aren't compatible.

Actually, several teams combine both methodologies, and ScrumBan has successfully proved that. Developers who employ ScrumBan merge the prescriptive nature of Scrum with the process improvement features of Kanban, achieving great results.

By making use of Scrumban, teams can take care of projects that involve frequent user story changes and/or a lot of bugs fixing without experiencing burnouts.

7. Agile doesn't scale.

Actually, this is true to a certain degree. Just like with other software development methodologies, Agile doesn't scale very fast. It takes a lot of time to manage large groups of programmers, designers, and so on, making sure that all of them pull in the same direction. So, while Agile works fine for large scale projects, the methodology is perfect for smaller-sized development teams.