“The word has come to mean goodness and light and mom and apple pie,” Allen Holub, a Bay Area programmer and consultant, said. “People don’t actually know what it means anymore.”
The word he’s talking about is Agile, the software development methodology formalized in 2001 that’s been gaining prominence in the tech community — and other environments — ever since.
But, as is clear from takes like Holub’s and the sheer number of “Agile is dead” memes, the philosophy is hardly untouchable. Agile started as a fluid set of practices, and, in many ways, it remains so. That means different organizations interpret it differently, and some interpretations are more helpful than others. At best, Agile makes companies sensitive to customer needs and resilient to market shifts. At worst, it’s a branding tool slapped on with few real changes.
Underneath the hype, however, lies a methodology that made waves for a reason. Companies want to be agile because it makes life better for employees and customers, industry wisdom dictates.
The Agile Manifesto, penned almost twenty years ago by a group of notable software developers, laid out four fundamental value statements:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In some ways, these values and the Agile principles that came out of them look different now. The face-to-face communication encouraged in the sixth Agile principle is tricky with a remote engineering workforce. The third principle’s directive to deliver working software weekly has, in many instances, been shortened to daily.
In the grand scheme, however, Agile’s fundamentals still apply. Because they are principles and not processes, there’s no one correct way to do them.
“The goal should never be conformity,” Howard Sublett, CEO and chief product owner at Scrum Alliance, said. Sublett and Holub disagree on a few things — Holub seems to detest Agile certifications, like the ones Sublett’s organization provides — but on at least one point, they’re in harmony: Agile looks different everywhere.
“If the goal is some big scaling framework or something that is insisting upon compliance and conformity across an organization, that’s one of the least agile things,” Sublett said.
Agile gives ownership to developers
We’re currently living through the Fourth Industrial Revolution, marked by the rise of technologies like artificial intelligence, cloud computing and the Internet of Things. But many of our attitudes about work were formed during the Second Industrial Revolution at the turn of the 20th century, when innovations like mass manufacturing called for high productivity and minimal employee input.
Sublett, on the other hand, uses words like “art” and “joy” when talking about software development. Assembly-line thinking, he said, has no place.
That line of thinking says 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.”
Less red tape means developers respond faster to customer feedback
A better way, Sublett said, is for developers to communicate directly with their end customers. That ideally 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.”
I think people forget that when you’re building software, no one has ever done what you’re doing before. That’s why it’s art and it’s software at the same time.”
One way this manifests is in documentation. In an Agile shop, long specification documents — and even documentation as a product unfolds — 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 — or any 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.
Agile makes developers happier
“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.”
Agile gets pitched as a more humane style of management (or lack thereof) because it boosts job satisfaction among developers. 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 said. “That’s why it’s art and it’s software at the same time.”
Agile gets the right software to customers faster
“‘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.
Holub echoed the idea that Agile shifts power from managers and processes back to development teams. But he added a few other benchmarks he uses to measure agility when he walks in the door at a new company.
Agile streamlines projects by dismantling siloed teams
One is the presence of cross-functional teams. That means instead of a design team handing ideas to an engineering team which hands ideas to a testing team, and so on, employees 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.
Agile reduces the risk of flubbed deliverables
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.
Companies are hiring people to do the work, so why don't they trust people to do the work?”
“They’re afraid of stuff,” Holub said. “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.
Agile lets teams pivot to something better
Which brings us to estimations. Holub isn’t a fan, 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.
Whatever your approach to planning (Holub recommends sharing value projections instead of delivery estimations), make sure there is room to change 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 on 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.
Agile can morph to meet a company’s particular needs
When Jeff Cernauske first worked at a company calling itself Agile, he wasn’t convinced.
It was 2012, and he was a software developer at a small business unit within a larger company. They were 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, he said. Their adjustments worked well, and Cernuaske soon found himself at a larger financial institution.
Now, Cernauske is a program manager at Northern Trust Hedge Fund Services (HFS). He’s only been on the job three weeks, and he’s got a big goal ahead: scaling the company’s existing Agile practices across 20 development teams in a highly regulated industry.
Northern Trust has already taken steps toward Agile practices. It bought Omnium, a collection of middle- and back-end investment technology solutions, from Citadel in 2011, and in 2018 brought a portion of Omnium’s software development talent in house. In September, the company deployed a web-based dashboard for fund managers to view important metrics and workflows. Now, HFS has more than 200 technologists helping to tailor the products to clients’ needs faster, and those teams have borrowed habits from Agile, like working cross-functionally and iterating quickly based on client feedback.
The org chart didn’t matter. You’re still allowed to talk to people, right?”
“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 believe Agile has much to offer the company and its customers, they said.
Agile encourages communication and self-organization
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. You’re still allowed to talk to people, right?” 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.”
Agile prioritizes relationships, even when processes are required
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.
Agility is what separates successful companies
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,” he 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 feedback — from customers and employees alike — 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.”
