<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

7 Myths About Agile Methodology

You may have heard a lot about Agile methodology but how well do you understand it? Do you think it’s organized chaos? Do you worry that all planning is thrown out the window, or conversely, that you’ll spend an entire software development project in meetings? If so, I have some bad news: you’ve been exposed to some myths about Agile.

You’re not alone. Any approach as buzzy and written about as Agile is bound to accumulate a few misconceptions about what it is and how it works and Agile has collected its fair share since its inception in 2001.

What is Agile methodology? Briefly, it’s an approach to software development that values adaptive planning, iteration, continuous improvement and collaboration between developers, clients and sometimes, the end user of a project. Rather than sticking to a plan for the plan’s sake, Agile encourages a quick and adaptable approach to changes or problems. For people used to its predecessor, Waterfall, that agility can be misinterpreted as chaos and a lack of discipline. Thus, a myth is born.

Ready to bust a few more? Here are seven common myths about Agile, debunked.

post-itPhoto by Daria Nepriakhina on Unsplash

Do you really need to choose between Agile or Waterfall?
Read the truth

1. Agile is a silver bullet.

Agile is great but that doesn’t mean it’s great for all organizations. Some larger organizations, like corporations that employ several teams of developers, may benefit from the more traditional Waterfall method, which allows the project to move at a pace all the teams can keep up with. In other words, just because Agile is buzzier than Waterfall doesn’t mean it’s always better. Be honest about your organization and its needs before you adopt Agile for the sake of adopting Agile.

2. Agile doesn't have to be fully implemented.

Just because you’re trying to implement Agile doesn’t mean the methodology is going to work for you. While you can modify Agile somewhat to fit your organization’s needs — by modifying the length of sprints, for example — you still have to implement Agile in more or less the way it was designed. You can’t throw away a part of the process that seems inconvenient or time-consuming.

An example of this is backlog prioritization, a step in which the team and the project owner list all a product’s desired features and prioritize them. No one looks forward to this meeting — it’s long and sometimes the end user is busy and doesn’t see the benefit of sitting through a meeting like this but it is important because it sets priorities for the project.

Basically, Agile is a process. If you decide not to do certain steps, that will affect your outcomes.

3. Agile has too many meetings.

There are a lot of meetings (or “ceremonies” if you’re implementing Scrum) in Agile. There’s the daily standup, the retrospective, sprint planning and backlog grooming. The key; however, is that it’s not too many meetings.

With Agile, only the people who have to be in certain meetings are required to be in those meetings. If you feel like there are too many meetings, or that you’re not getting quality time in those meetings, you may be doing them wrong. Maybe the product owner is talking too much in the daily standup, which is a meeting for the team to discuss the day’s tasks. Maybe everyone is sitting in the backlog grooming meeting instead of just the product owner and a few key team members.

The meetings in Agile all serve important functions and they come with specific rules. When the rules of the meeting are not followed, they become ineffective meetings and it can seem like there’s too many of them.

4. Agile requires no planning.

Agile can seem like chaos after years of using Waterfall: there’s no analysis before a project to find out exactly what the product should do, no documentation, no planning at all, dogs and cats living together, mass hysteria!

That’s not exactly the case. It’s true that in traditional Waterfall development, most of the time at the start of a project is spent on extensive planning: business analysts create user requirements, system requirements and functional requirements. Project managers create project plans and Gantt charts. After all, all of that has to be complete and approved before the developers can get to work.

While Agile puts the developers to work right away, that doesn’t mean there is no planning. The planning is simply an ongoing process performed during development. Requirements are gathered ahead of development, in small chunks. Then, each sprint starts by gaining agreement on what features will be developed next.

Analysis happens on-demand, and probably in more detail, because the developers are performing analysis as development is taking place, while talking to end users and the product owner. Documentation happens the same way, as a scheduled part of each sprint.

whiteboard-business-chartPhoto by Christina Morillo on Pexels

5. Agile is only used to build small projects

The Agile process creates small teams that collaborate as the development happens. The teams are designed to be cross-functional.

Small team = small project, right?

Not necessarily.

Bigger projects can be divided up in different ways. Multiple teams can be assigned to build out different parts of the architecture, or focus on specific features, for example. Agile largely works because it breaks down complex requests into smaller tasks, allowing the team to move faster to build each request. That concept scales, no matter the project size.

6. Agile can't work remotely.

It is true that Agile encourages involvement from stakeholders and business leaders throughout the development process and also encourages everyone to be physically nearby whenever possible.

That aspect of Agile can cause people to think that all Agile team members have to be under one roof. In reality, there are many Agile teams — both co-located and all-remote — that are very successful.

Communication needs to be real-time, yes. Collaboration is crucial, yes. But technology can step in to help communication and collaboration happen, easing the burden of requiring all team members to be at a single location.

7. Agile teams don't really know what they're building until it's done.

Waterfall development starts with the end product in mind. The challenge with this is more often than not, requirements change midstream. Clients redefine things, new features get added, new directions are set, projects get delayed and cost estimates based on the original functionality go out the window.

Agile starts out by admitting that most projects have uncertainty and the potential for change. But there is a goal for every Agile project: a high-level plan defines the overall goal but the details are refined as the project is built. This lowers the risk of rework and allows stakeholders more flexibility in design, as development progresses.

And when there is rework, it happens right when it needs to happen — in the middle of the project, when it’s easiest (and cheapest) to fix a bug or make a change. In Waterfall, that rework happens at the very end of the project and those changes often mean the entire project needs to be changed.

Thinking of going Agile?

If you still have questions about Agile and whether it’s right for your project, it may be time to call in an expert. Get in touch with Omni, we’re Wisconsin-based technology consultants with extensive project management experience. We can help you understand and implement Agile methodology. 

Should you choose Waterfall or Agile for your next IT project?

Watch On-demand

Share:
Paul Rasmussen

About Author Paul Rasmussen

Paul wants to live in a world where he can golf every day of the year, he has an unlimited number of “Do Overs," and he hits every goal he sets for himself. As a project manager, one of Paul’s strengths lies in managing multi-faceted Agile projects. After tackling some tough ones, he’s learned a lot about which management styles do and don’t work in a given situation, when and how to ask the hard questions, and how to identify who can be counted on at critical junctures. Throughout the project cycle, he strives to give team members and clients more than what they expect. “When I can do that, it’s amazing to see the lasting business and personal relationships that are made.” Outside of work, you are likely to find Paul at the golf course, brewing up his own specialty beer, or whipping up something new and crazy for Saturday breakfast. The past few years he has spent an inordinate amount of time assembling toys for his kids. Paul grew up in Sparta, near LaCrosse WI. He graduated with a degree in Management Information Services from UW - Oshkosh. He and his wife Jody have two daughters (Maddison & Skylar) and a son (Dyllan).



Disclaimer:

Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.