It’s a sweeping religion across technology teams — the kind of religion that comes with an official manifesto, evangelists, and high-dollar training seminars. It’s the Agile methodology.
For many teams over the past decade, it’s become a tried-and-true approach for developing software, products, and features. It’s the answer they’ve been craving and it makes sense out of the worst kind of chaos. It paves a structural path for breaking apart large initiatives into digestible pieces with an ideal formula for cross-team collaboration.
But it’s not for everyone.
As someone who has held multiple roles on six different Agile-based teams across my career, I’ve seen companies struggle to squeeze, contort, and conform themselves into an Agile box because they think it’s “what all the successful companies are doing these days.” And when they fall short, it’s because “we failed Agile” rather than contemplating that maybe “Agile failed us.”
If you ask technology leaders why they’re integrating a particular process and the answer is “because Agile says so,” then you might be working with sheep of blind faith instead of true innovators who are able to critically analyze a team’s unique needs.
Agile in three paragraphs
The basic principles of the Agile methodology were formed back in 2001 by a diverse committee (just kidding — it was 17 middle-aged white male software developers with names like Mike, Jim, and Ron). While the smart concepts made a lot of sense and resonated widely, unfortunately, their detailed Manifesto for Agile Software Development is now as crusty as the 2001 website it still lives on, yet people still quote it like the Bible.
That being said, you can argue that certain core values hold the test of time. In a nutshell, these original values encompass 1) individuals and interactions over processes and tools; 2) working software over comprehensive documentation; 3) customer collaboration over contract negotiation; 4) responding to change over following a plan.
Over the years, the concept of Agile has evolved beyond value statements and into varied frameworks that are used across start-ups to Fortune 50 enterprises. For example, Scrum is an iterative method of product development that uses agile principles, and the Scaled Agile Framework (aka, SAFe®) includes five core competencies for “Lean Enterprise,” with the goal of having teams produce deliverables quickly across a predictable cadence. Scrum and SAFe® have a lot of overlap, but they’re technically different frameworks that serve different needs.
Where Agile falls short
It focuses on products over people.
Real-life doesn’t exist in neat little sprints in which tasks can be allocated in perfectly measured doses. Real-life includes sickness, burnout, holidays, celebrations, vacations, births, deaths, accidents, tragedies, heartbreak, and natural disasters. It includes firings, hirings, surprise resignations, and unexpected budget cuts. It includes shifts in mindset, shifts in focus, and shifts in skill development.
Yet the nature of the deadline-driven, sprint-focused delivery cycle is that continuity is key. You don’t just pause the sprint cycle for a month because it’s flu season or because Todd suddenly quit or because Shelly is taking maternity leave. And you don’t just halt sprints altogether because you realize that maybe the product itself needs to be completely reevaluated.
Because, according to Agile: “The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Sure, you can adjust your available hours during sprint planning or adjust your burndown chart (a graphical representation of how time is translated into work progression). But that still assumes that you’re psychic enough to know at the beginning of a sprint exactly how time allotment will play out, or that it will be easy enough to simply shift resources or shift focus during the cycle while fulfilling all committed deliverables. It’s rarely that simple.
Let’s say the team is feeling burnt out after consistently pounding out deliverables, and desperately needs a change of pace. Or maybe there’s a need to halt delivery for a while to assess and to focus on research and ideation.
Keeping within the spirit of Agile, they may transition to something resembling more of a Design Sprint, which designates specific blocks of time for understanding the user, defining the problem, and ideating solutions before jumping into a prototype. Yet that model doesn’t address the core pace and pressure issues that may have injured morale in the first place. It might actually make the situation worse due to the often unrealistic expectations it creates — now, instead of allowing for the time and patience to examine a problem from various angles, you’re compelled to pick an angle and run with it (because, after all, Phase 1 ends tomorrow!).
According to the Agile manifesto, “Working software is the primary measure of progress.” In other words, progress is more about the product and less about the people behind the product. People, in this case, are just a means to an end.
Allowing for boundless change isn’t always a good thing.
It’s crucial to have a system that’s built to support the inevitable need for change. Sometimes, however, it’s actually better to stick to defined parameters than to allow an open door of revolving requirements. Yet a core Agile principle is to “welcome changing requirements, even late in development.” And because “changing requirements” is usually open to interpretation, it means that it’s easy to take advantage of the people who are producing the product — and those producers feel they have no choice but to be stepped all over, for the sake of “remaining agile.”
This gets into the messy world of “scope creep.”
While people define scope creep differently, it’s generally agreed that scope creep is not simply swapping or adjusting a requirement before the team dives into the work. Also, it’s not scope creep if the team has allotted time for unknown discoveries. Rather, scope creep occurs when stakeholders want to tack on new requirements during the development phase without sacrificing existing requirements, or they see a near-final product and decide they want to go in a new direction within the existing time frame.
Think of it this way: If you hire someone to paint your living room walls, it would be unreasonable to decide when they’re 80% finished that you’d actually prefer the walls to be gray instead of green and to be unwilling to allot extra time or pay for extra supplies. It would be perfectly reasonable, however, to change your mind on the color before the painter made any initial purchases.
Yet many teams will say, “We can practice Agile while avoiding scope creep.” And theoretically, they can. But the principle of Agile in itself means that you’re already inherently vulnerable to scope creep, so you would need savvy product owners and release managers who can exercise keen discernment and negotiation while maintaining the courage to stand up to leadership. Unfortunately, in many organizations, those team members either lack that skill set or lack such authority.
It enforces a hivemind approach to collaboration.
As someone who’s held leadership roles within organizations, I’ve seen the value of nourishing different work styles and personalities. We perform our best when we’re given the space to let our unique mental processing thrive without too many barriers. We’re all designed differently, and different things come more naturally to different people.
Some people work best with tactical problems; others with more abstract problems. Some people can form a brilliant solution in a quiet space over a two-hour period; others may be more suited to form a brilliant solution in a crowded room over a two-day period. Some rely more heavily on data while others rely more heavily on intuition, only to arrive at the same conclusion. That doesn’t mean that one style is always better than the other or that one mind is more “evolved” or “efficient” than the other. But it means that we should be careful about one-size-fits-all collaboration mindsets.
Obviously, there needs to be some form of collaboration standard within an organization, and there needs to be a defined workflow. But over and over again, I’ve seen creative lights dimmed and inspired spirits dampen because people are forced to work within the confines of their organization’s Agile standards.
The Agile manifesto states that “business people and developers must work together daily throughout the project.” It also states that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
In other words, have fun being locked in a room with others for hours.
You might point out that this was written in 2001 before digital collaboration tools made it much easier to work on remote teams — and that 20 years later it’s become much more efficient to practice Agile across literally every time zone in the world. Then why, in my last role, did leadership insist that we start co-locating and freeze remote hiring for the sake of Agile? Because too many people are relying on that crusty, two-decade-old manifesto that was written by a team of 17 guys as if their perception of reality speaks for every organization indefinitely.
Even the United States Constitution allowed for amendments. The “Twelve Principles of Agile Software” apparently do not. Teams may scramble to come up with their own Agile adaptations, but they still feel the need to work by a defined methodology of “Agile” rather than simply creating and evolving their own standards.
By minimizing “process,” it ironically overcomplicates process.
I once heard a conversation at a program increment planning session that went something like this (names have been changed).
Don: Hi, James. We’re having trouble piecing together your vision for this feature. Do you have any additional documentation on how you arrived at this solution?
James (snidely): Well, Agile says no documentation, so no, I don’t. In Agile, we have conversations.
Don: Got it. Well, are you free to come over and have a conversation with my team right now?
James: But I’ve already had extensive talks with all of them. Like, endless meetings and calls where I am just repeating myself like a broken record. And I have to meet with Li before noon. Maybe we can all have a meeting at 2 pm.
Don: Only half of us will be available at 2 pm though, and I think they need to hear it from your mouth because I’m clearly not translating it well.
There are multiple problems with this scenario. Firstly, Don’s team is clearly confused because no one has articulated a clear vision to them. This could be due to many reasons. Maybe the epic itself was lacking; maybe not. Secondly, James has a bull-headed interpretation of Agile documentation standards, while Don feels that the standard is more about minimal documentation over no documentation. Thirdly, think about all the time that’s been wasted with repetitive conversations that may have been spared if enough information had simply been documented somewhere.
I’ve seen the same conversation manifest in multiple forms over different Agile-related issues. All of those conversations get into the weeds on how exactly the Agile methodology is supposed to play out within an organization.
By adhering to the Agile standard of “individuals and interactions over processes and tools,” we can mistakenly begin to reject the importance of cohesive workflows or reject the processes and procedures that have proven to be effective for our teams.
Rather than conforming to fuzzy interpretations of how Agile is “supposed” to work, how about defining process with your team from the ground up? Rather than obeying an outdated set of guidelines, what about crafting your own guidelines based on the unique structure of the organization, the unique strengths of the team, the unique nature of the product, and evidence of past successes?
Why companies are determined to fit inside the box
Executives love the promise of Agile-focused frameworks because these methods are thought to produce faster and cheaper product delivery. Many developers, strategists, architects, designers, project managers, and product owners love the structure and predictability of Agile processes.
If it works for everyone on a team, morale is high, the organization is delivering top-notch products consistently, business stakeholders are happy, and no one is experiencing burnout, then why not use it?
Well, maybe for all those instances when it doesn’t work for everyone on a team. And morale is low. And the organization is delivering quantity and speed over quality. And stakeholders aren’t happy. And teams are burnt out.
Yet even when these negative factors are present, organizations tend to remain convinced that Agile is the gold standard for any form of product development, and that 2001 guidelines translate into every company’s vision, culture, and values two decades later. It’s the flawed logic of “successful companies do it, and we want to be successful, so if we do it we’ll automatically become successful.”
I once worked for a Fortune 50 company in Silicon Valley. One day my colleague asked a VP to why we were transitioning to an open-office environment (e.g., tearing down the cubicle walls) when research showed that open-office settings are not conducive to productivity for most roles. The VP replied with one line: “Because it’s what successful companies like Google are doing.”
The premise seemed to be that we had to model everything Google did culturally and infrastructurally because they have a successful business model — when in reality, our business model was nothing close to Google’s.
While claims exist around Agile’s statistical success rates, the results are pretty hard to quantify once you dig into the data. Such claims might compare Agile to “traditional” project management methods without defining what those methods are. They also tend to measure short-term successes over long-term patterns and have questionable ways of defining what “success” even means.
Daring to innovate
Upper management, middle management, and every staff member participating in an Agile process should be able to justify why they use Agile and why it makes the most sense for their team or organization. “Because leadership says so” isn’t good enough, and “because it’s what everyone does now” isn’t good enough. That is cult speak.
Do you think some components of the Agile methodology or some components of specific Agile frameworks would suit your team well? Great. Try them. You can still have an Agile-influenced process without drinking the whole box of Kool-Aid, and you can still embody the spirit of Agile in your own unique way without shopping for a framework that someone else decided is ideal for your organization. Be like the band who borrows blues riffs combined with hip-hop beats but ultimately encompasses their own signature sound.
Many people buy into the false myth that “if it’s not Agile, then it’s Waterfall.” (“Waterfall” generally refers to a more linear approach to product delivery that is still deadline-driven.) But this dichotomy only exists when we create it. A method can be one or the other, encompass traits from either or both, or reject traits from either or both. Comfort exists in definitions, but the freedom to innovate is more powerful than comfort.
When companies spend high dollars on Agile training so they can fit into a predefined Agile mold, they should be confident that the mold is the right fit. All too often, however, they spend endless resources on forcing the shoe on the wrong foot. The result is confusion, frustration, high turnover rates, and compromised products.