Many companies have enjoyed the benefits of agile — a methodology that breaks up projects into smaller parts and allows teams to get customer feedback and make iterative product changes on the fly — but even agile’s fans say it’s not without its flaws. The main one being a lack of consensus on the term’s actual definition.
“The word has come to mean goodness and light and mom and apple pie,” said Allen Holub, a Bay Area programmer and consultant. “People don’t actually know what it means anymore.”
While the meaning of agile isn’t always clear, there’s no denying its upsides when applied correctly.
To give you a sense of why the methodology remains popular among software developers and project managers, we rounded up 11 benefits of agile.
Benefits of Agile:
- Increased employee input.
- More responsive to customer feedback.
- Higher job satisfaction.
- Faster fixes and solutions.
- More cross-functional collaboration.
- Better risk management.
- Increased room to pivot and experiment.
- Customized company solutions.
- Decentralized communication.
- Bigger focus on relationships.
- Clearer paths to success.
11 Benefits of Agile Methodology
1. Increased Employee Input
Even though we’re currently living through the Fourth Industrial Revolution, many of our attitudes about work were formed at the turn of the 20th century, when innovations like mass manufacturing called for high productivity and minimal employee input.
Howard Sublett, CEO of Scrum Alliance, says that assembly-line thinking has no place in software development, because it assumes that people are resources to be managed, which creates a manager-employee dynamic many agile practitioners don’t support.
According to agile, the idea that people work at their full potential only when pressured is downright wrong.
“In a traditional environment, people have no skin in the game,” Sublett said. “They’re just waiting for some manager to tell them something.”
2. More Responsive to Customer Feedback
Developers should communicate directly with their end customers, according to Sublett. Ideally, that creates better products, but it also gives developers more ownership over their work. The answer to the question, “Why are you working?” shifts from, “Because my boss said so,” to, “Because my customer has a problem and I think I can fix it.”
One way this manifests is in documentation. In an agile shop, long specification documents are less important than frequent communication with the customers that will ultimately use the product. If engineers feel tied to a top-down product plan, they’re not well-positioned to pivot in response to customers’ feedback during the development process.
Another place this shows up is mandatory reporting. Developers work slower when they have to get approval from higher-ups for each idea or change. That means product managers have to reimagine their roles. Instead of managing direct reports and ensuring work gets done, they serve as a resource for their teams, providing support when necessary and stepping back when not.
3. Higher Job Satisfaction
Agile gets pitched as a more humane style of management (or lack thereof) because it boosts job satisfaction among developers.
“It’s humanizing the work,” Sublett said. “It’s allowing the decisions surrounding how to build something to be in the hands that are actually doing the work, rather than some senior vice president in some ivory tower handing it down through 19 layers of administration.”
When teams have the freedom to respond to customer needs in real time in the ways they think best, they see more value in the software they create — and in themselves, Sublett said.
“I think people forget that when you’re building software, no one has ever done what you’re doing before. If it’s been done before, you can buy it off the shelf,” he added. “That’s why it’s art and it’s software at the same time.”
4. Faster Fixes and Solutions
“‘Success at agile’ isn’t a thing,” Holub wrote on Twitter. “What you want is success at getting valuable software into your user’s hands.”
Holub tweets about agility a lot, and he’s built a career consulting on software and organizational dynamics for clients like Intuit and Autodesk. For him, agile certifications are too prescriptive: Companies that try too hard to be agile may actually become less agile.
“What agile means is that you are agile in the literal dictionary sense of the word,” he said. “It’s not some weird, made-up thing you have to do. In order to be flexible, you have to be flexible. So if you’re not, then clearly you’ve blown it at some point.”
So, what’s the definition of agility, according to Holub? If a customer is struggling to use a feature or functionality, and you can get a fix into their hands in a day or so, you’re agile. If you can’t, you’re not.
5. More Cross-Functional Collaboration
Instead of a design team handing ideas to an engineering team, which hands ideas to a testing team, and so on, employees can self-organize into cross-functional teams with enough mixed expertise to tackle a given project at all stages. That way, Holub said, passing a project between different silos doesn’t add precious days and weeks between conception and deployment.
6. Better Risk Management
Another measure of agility is an organization’s approach to risk, Holub said. Often, management tries to control risk by tightly overseeing the work of development teams. If management mediates communication between developers and customers, they may think customers are less likely to get dissatisfied. In actuality, those barriers could exacerbate some factors that cause customers to churn.
“They’re afraid of stuff,” Holub said of some skittish companies. “And what they don’t understand is that some of the things they’re afraid of are minimized when agile is done correctly. Risk, for example, comes from not getting things delivered. Risk comes from working on something for weeks or months — or sometimes years — and not knowing whether your customers are going to like it until you deliver.”
To truly control risk, he said, company leaders should take a step back and give development teams direct communication with customers so they can get feedback early and often.
7. Increased Room to Pivot and Experiment
Holub isn’t a fan of estimations because putting timelines on deliverables doesn’t leave room to adapt to customer feedback.
“You could have a roadmap, but it would have to be a dynamic window. It has to be one that’s changing all the time as you get new information,” he said.
Make sure your plan leaves room for changing directions. Whether it’s removing a card from a sprint or changing a user story after development work starts, Holub and likeminded agile practitioners advocate for a culture of continued experimentation.
And experimentation, Holub said, is only possible when organizations are committed to the psychological safety of their teams. In agile environments, psychological safety means participants have the freedom to give candid feedback, try brand new things and fail. If team members are working from a place of fear — of losing their bonuses, scrapping existing work or simply rocking the boat — both the work and morale suffers.
“Companies are hiring people to do the work, so why don’t they trust people to do the work?” Holub said.
8. Customized Company Solutions
In 2012, Jeff Cernauske was working as a software developer at a small business unit within a larger company. The team was putting together a customer-facing platform, and it wasn’t quite working. They’d been building for a long time without much success, he said, and eventually he decided that whatever agile was getting at, they probably weren’t doing it. He asked to attend a two-day scrum master certification course, and, as it turned out, he was right.
Cernauske went back to his organization with suggestions of how to pivot, and his company leaders bought in. Their adjustments worked well, and Cernuaske soon found himself at a larger financial institution.
As a program manager at Northern Trust Hedge Fund Services (HFS), Cernauske was tasked with a big goal: scaling the company’s existing agile practices across 20 development teams in a highly regulated industry.
“Philosophically, we are all in on agile,” Omnium platform executive Carl Lingenfelter said. “But we wanted to have somebody who had done that over a longer period of time in a more scalable way.”
Cernauske was their man. And despite Northern Trust’s big size and traditional structure, Cernauske, Lingenfelter and other company leaders say agile has much to offer the company and its customers.
9. Decentralized Communication
During his time in the finance industry, Cernauske got some first-hand experience with the methodology’s flexibility. Although his last company wasn’t organized into cross-functional teams, he and his coworkers realized there was nothing stopping members of different teams from sitting down together and speeding up the process, he said. They self-organized a team that cut across product, development and quality assurance (QA).
The benefits were clear. Product and development could create user stories more conversationally, and QA could formulate tests as they went instead of entering a massive documentation phase at the end of each project.
“The org chart didn’t matter,” Cernauske said. “Outside of the room, or the virtual room, as it were, there are org charts and hierarchy and managers and all that stuff. But when you’re meeting and everyone has a shared goal and a shared purpose, that kind of stuff shouldn’t matter.”
10. Bigger Focus on Relationships
The first agile principle taught Cernauske that relationships are more important than processes, and that can still be true at a company within a regulated industry, he said. Relationships and processes can exist on a continuum, rather than in opposition. The trick, according to him, is to prioritize relationships even when processes are required.
“If you, for example, are in a position where you have to submit a trouble ticket or there’s some documentation that has to be on file for a release, you’re still working with the people that are going to receive that documentation first and foremost. And then the documentation just becomes an artifact of that conversation,” he said.
Even common, bite-sized documentation like user stories are just artifacts of conversations between developers and other stakeholders, he added.
11. Clearer Paths to Success
Agile looks different everywhere. For Sublett, it often begins with a class to help students of Scrum understand what’s worked elsewhere and what could work differently at their own organizations. For Hollub, agile is an amorphous beast that cannot — and should not — be nailed down, but that will definitely make you nimbler. For Cernauske, it’s a set of fluid practices that don’t demand your adherence, but that reward a willingness to listen.
“I’m not dogmatic,” Cernauske said. “I believe that if you go back to the principles, every organization should be allowed to tailor it to their needs. And if you look at each one of these implementations, they all have an inspection and adaptation feedback cycle built into them.”
Reflecting regularly and adapting quickly to customer and employee feedback are agile essentials any purported practitioner can agree on. Whether a company is truly agile, however, will only be determined by its outcomes.
“The companies that are actually agile have a pretty significant competitive advantage,” Holub said. “Ultimately, Darwin will win here.”