There’s often a lot of fear, uncertainty, and doubt surrounding Agile as organizations scale, but not all of these anxieties are justified. Here are some of the more common Agile myths and misconceptions, including the ones you should worry about.

8 Myths and Misconceptions about Scaling Agile:

Agile Myth #1: You can’t scale up Agile—it doesn’t work like that

To address this, take a look at the Agile Manifesto. It says that we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto lists the four primary values of Agile (on the left) and compares them to the reality of traditional methodologies (on the right). But at scale, individuals and interactions require processes and tools to get things done.

Your working software will need at least some documentation, and while you’ll collaborate with your customers, you almost certainly need to have a contract in place first. The Agile Manifesto acknowledges the realities of larger organizations, as long as you continue to place more value on the items on the left.

Agile Myth #2: Agile doesn’t work with large software projects

Many successful enterprises claim that Agile is unplanned and chaotic, with no long-term estimates or plans. They say, “Waterfall works great for us—we’ve been doing it for years. It gives our project managers and business leaders concrete plans to enable all the stakeholders to align and prepare for large changes.”

While they believe their plans are more accurate, the reality is that often their effort and schedule estimates bear little resemblance to reality. The longer the project runs, the more inaccurate the estimates become. But if you introduce Agile and scale it correctly, you can improve on all parameters, whether you were successful before or not.

Resistance to Agile is often rooted in the radical change that people need to make in their daily work practices in order to embrace it. Identifying and training Lean-Agile Change Agents can be extremely helpful in making this mindset transition. That extra push is a great way to train teams so they embrace Agile concepts such as scrum, sprint, and stand-up meetings.

Agile Myth #3: There are no testers in Agile

It’s sometimes said that there are no testers in Agile, only testing. There’s certainly truth in the fact that testing is infused throughout the Agile methodology, but it’s done by many people.

Developers write unit tests and are often involved in both functional and non-functional testing, such as performance testing, security testing, etc. Development testers use their development skills to focus on testing. But there are also testers in the Agile organization. The difference is that the role of the tester in Agile has become more collaborative and proactive than before, when the main focus was on running tests, finding bugs, and logging them in the system.

Today’s Agile tester is involved in helping to identify user stories, scoping, and estimating, and helping to define the meaning of “done,” as well as testing. And when they find bugs, they don’t just log them into the system. They collaborate with the developers to reproduce the bug, fix it, and verify it before the end of the sprint so the team can meet its goal of delivering working software.

Agile Myth #4: The Agile team member is a jack-of-all-trades but a master of none

Agile teams are cross-functional and are encouraged to work on features from end to end to allow them to minimize dependencies and deliver working software at the end of a sprint. Consequently, team members need to develop broader skills and knowledge of the product, but they also need to understand its many layers and components. Different feature teams may be working on the same layer and components, so they’ll need to “play nice” with each other and ensure that they’re not stepping on each other’s toes. But because everyone is a generalist who knows “just enough” of each component, there’s a concern that no one has the broad view needed to identify duplicate code and ensure consistency within the user interface and the internal architecture.

But the Agile developer isn’t just a generalist. A true Agile developer is a “generalizing specialist,” meaning that they specialize in one or more technical areas, such as Java, security, or databases, but they also have a general knowledge of software development and a broad knowledge of the business for which they’re developing the software.

Agile Myth #5: You won’t need to plan

“We used to be waterfall,” you say. “We used to spend most of our time in planning meetings, where we’d plan and plan some more before starting development. Now that we’re Agile, we don’t need to plan anymore.” Not quite.

It’s true that you won’t spend months doing up-front planning of a complete application before you start development (only to find that the requirements have changed halfway through the coding phase), but you’ll certainly need to plan your sprints ahead of time. You need a long-term vision, and you need to plan your budget and resources. You’ll have to coordinate multiple teams.

Planning is necessary in Agile development, but it takes a different form from the planning you used to do in a waterfall approach. In Agile Planning, you need to be leveraging rolling planning based on an analysis of your team’s velocity and capacity. Once you have a set of prioritized stories to be implemented in the upcoming sprint, which might include stories that weren’t completed in the previous sprint, the team will elaborate on the acceptance criteria for each story and estimate the time to implement.

The approach to planning in an Agile enterprise is highly efficient, with the level of planning detail increasing alongside the likelihood of the user story being selected for implementation. Agile doesn’t waste time on detailed planning of stories that won’t be implemented.

Agile Myth #6: Distributed teams can’t be Agile

While it’s true that having the whole team in one physical location promotes smoother interaction and information exchange, this is an impractical luxury for most organizations.

Expansion into global markets means teams are assembled from different geographical locations, and this is where technology and your own flexibility come to the rescue. Video conferencing has come a long way, and meetings can be held over four different continents at the click of a button. Tools for collaboration and file sharing are plentiful and can support distributed development. If you’re flexible with team members and can accommodate different time zones and efficient meeting practices, you can overcome the challenges of geography.

Distributed teams present advantages, too. For example, while one developer sleeps at night, another on the other side of the globe can test the code he committed at the end of his workday. With a little effort, distributed teams can be just as Agile as co-located teams.

Agile Myth #7: My team can be Agile, and other teams won’t have to change

As one team starts to move toward two-week sprints and accelerates delivery, it creates demands and challenges for the rest of the organization. In a larger organization, that team is likely to be producing deliverables such as services or components as part of a larger project, and they can’t become an Agile feature team if they’re only responsible for that component.

To effectively transition to Agile, you’ll need to engage the other teams working on the project and restructure your responsibilities so that you’re better aligned with the principles of Agile cross-functional teams.

In a large organization, you must deal with late adopters who still work with traditional methodologies, corporate bureaucracy, or even external APIs that aren’t necessarily synced with your plans for development. But you can work around these challenges. Using the flexibility inherent in being Agile, you can align with other teams’ schedules, move user stories around to accommodate the latest corporate directive, or rework some architecture to overcome a bug in that external API you’re using.

Agile Myth #8: You need to throw out your current tools

If you buy a new mobile phone, you don’t need to replace all your family members’ phones. They work with each other, even if they come from different vendors or have different operating systems.

The same is true with the software lifecycle management tools you’ve been using. Most lifecycle management tools are able to integrate with each other and share information across different teams. If you need to implement new tools for managing your Agile project, you should be able to continue to work with your existing portfolio management and test management software and synchronize them so everyone is viewing the same information while working with different tools.

Remember – there’s no end game

Agile at scale is not an end game. It’s still evolving, and it’ll probably continue to evolve until the next big thing comes along in software development. For example, look at the Scaled Agile Framework. It’s currently in its third version and continues to evolve. As long as you shift your mindset, use the right coaches, adopt Agile practices, and move from the items on the right toward the items on the left, you’ll find yourself constantly improving and reaping benefits for your business.