“Agile Signaling” is Gaslighting The Tech Industry
Agile Development • Health & Wellness
Most tech companies engage in agile signaling. They actually make it harder to change, but put on a show to pretend they're agile.
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
How the Software Industry Redefined “Agile” to Mean Anything BUT Change
When you hear the word “Agile,” does it make you roll your eyes or shake your fists in frustration because it seems like a complete waste of time? Thirty years ago, when Agile development first emerged, it meant something very different from what it does today. But how did that happen? In this episode, I want to help you understand the history of Agile development, how it was an amazing and beneficial practice when I started my software development career 27 years ago, and what went wrong along the way.
The Need for Agile Development
Thirty years ago, Agile development was introduced as a response to companies struggling to adapt quickly enough to changing market conditions. Imagine a company budgeting for a software project a year or two ago, only to have the rapid emergence of AI disrupt their entire plan. This kind of chaos requires companies to replan, start over, and adapt quickly, which can be costly and inefficient. Agile was designed to minimize the impact of such market changes, allowing companies to adapt without excessive waste.
Companies that truly practice Agile today are better positioned to handle these disruptions, such as the advent of AI, without incurring significant costs. However, many companies claim to be Agile while still operating in ways that are anything but, leading to frustration and disillusionment among developers.
Why Agile Was Created
The second reason Agile development became popular was due to the long history of over-budget and late software projects. In the late 90s, it was common for projects to be released much later than planned, leading to cancellations and a volatile industry. Agile was seen as a way to address these issues by helping teams identify problems early, adapt quickly, and ultimately deliver more predictable outcomes.
But what happened? Why does Agile often feel like micromanagement, with an emphasis on measuring and controlling rather than adapting and improving?
Four Key Events That Redefined Agile
Let’s explore four key events that transformed Agile from a methodology focused on change and adaptation into something almost unrecognizable.
1. The Introduction of Burndown Charts and Velocity Tracking
Originally, Scrum, a popular Agile framework, did not include story points, burndown charts, or velocity tracking. These were added later, pandering to management’s desire for predictability. While these tools might seem useful, they often lead to pressure on development teams to manipulate numbers, cut scope, and present a facade of consistent progress. This shift away from the original intent of Agile—adapting to change—towards satisfying management’s need for control, is a significant reason why Agile feels broken today.
2. Jeff Sutherland’s Book: Scrum: The Art of Doing Twice the Work in Half the Time
Jeff Sutherland, one of the signatories of the Agile Manifesto, published a book titled Scrum: The Art of Doing Twice the Work in Half the Time. While the title is brilliant from a marketing perspective, it fundamentally misrepresents the purpose of Agile. Agile was never about getting more done faster—it was about adapting to change and improving processes. Unfortunately, this book reinforced the misconception that Agile is about speed and efficiency rather than adaptability.
3. The Agile Certification Industry
As Agile gained popularity, the certification industry saw an opportunity to profit. Organizations began offering certifications that supposedly qualified individuals to implement Agile practices. However, these certifications often focused on superficial aspects of Agile, such as Scrum ceremonies and tools, rather than the deeper principles of adaptability and continuous improvement. The result is a generation of “Agile” practitioners who may be certified but lack a true understanding of what Agile was meant to achieve.
4. The Introduction of SAFe (Scaled Agile Framework)
The Scaled Agile Framework (SAFe) further diluted the meaning of Agile by promising to bring Agile practices to large organizations in a way that felt “safe” and controlled. However, as Jez Humble explains in his video “Why Scaling Agile Doesn’t Work,” scaling Agile often results in the opposite of what Agile was intended to achieve. The more people, teams, and dependencies involved, the less agile the process becomes. SAFe, with its complex diagrams and rigid structures, provides a comforting illusion of control for management but often sacrifices true agility in the process.
The Impact of These Changes
These events have left many developers feeling disillusioned with Agile. The term “Agile” is now often associated with micromanagement, rigid processes, and unrealistic expectations—far removed from its original intent. If you’ve never been on a truly Agile project, it’s understandable why you might feel frustrated and even gaslit by the way Agile is presented in the industry today.
Conclusion
Agile development was meant to help teams adapt to change, respond to market forces, and improve continuously. However, the industry’s redefinition of Agile has turned it into something very different. If you’re struggling with this, you’re not alone. The important thing is to understand where things went wrong and to find ways to either adapt and fix what you can or cope with what you can’t.
Do you feel gaslit by the software industry’s redefinition of Agile? What are you doing to fight back against it, and what challenges are you facing?
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.