So your company has decided to adopt agile as its go-to methodology for software development. Chances are you got here because there were one or two rogue teams who felt constrained by the traditional waterfall model and wanted to try something different. They started following the 12 principles of agile software development and produced positive results. Now the rest of the organization wants to follow suit. If it worked well for one or two teams, it'll be even better for 10. Right? Maybe not. Too many cooks might spoil the software.
There's 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 myths and misconceptions, including the ones you should worry about.
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.
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 more often than not, 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. Bringing an experienced agile coach on board 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.
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.
Myth #4: The agile team member is a jack-of-all-trades but a master of none
Agile teams are encouraged to work on features from end to end, including crossing functional and component boundaries, 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. We don't want the end result to be a camel.
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.
Small, independent agile teams usually do without an architect role because everyone on the team is responsible for the architecture. But in larger agile organizations, there's typically a system architect who's responsible for consistent design across the different agile teams. The Scaled Agile Framework (SAFe) has a place for an enterprise architect who's responsible for integration and consistent design across the organization's different portfolios.
You'll also find other cross-team specialists in larger organizations. Often known as shared resources, these specialists include user experience experts, security specialists, quality assurance specialists, and more.
A true agile organization ensures that good design isn't sacrificed and encourages and nurtures team members who wish to specialize in certain areas while staying abreast of the broader picture.
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 up-front planning of a complete application before you start development and 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, but it takes a different form from the planning you used to do in a waterfall approach. You need to be doing rolling—just-in-time planning based on experience of your team's velocity and capacity. Once you have a set of candidate 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 team might need to use a spike to gain more knowledge of the technical or functional considerations for an upcoming story.
The approach to planning in an agile enterprise is highly efficient, with the detail of planning increasing with 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.
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 colocated teams.
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 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.
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 get 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.
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.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
