Agile killed agility.
Like the owner in the fable of the goose that laid the golden eggs, the Agile industry went too far with a good idea. Agile lost its roots through its commercialization, the proliferation of certifications, and the influx of consultants.
Surveys have shown a decline in Agile over the past several years. Leading agilists declared its death. Others are trying to reimagine and reinvigorate it. I think we should simply return to its foundational roots.
In this article, I reflect on my nearly 40 years of experience “being agile” and explain what matters. It’s not the frameworks, practices, or tools—it’s the mindset and ways of working. This article is a companion to my 9-part series on Project Management Back to Basics, where I outline the essential components of project success.
Agile is a Mindset
As Agile rose in popularity, 2-day certification courses became the rage. Scrum Alliance alone reports over 2 million certificate holders. These courses teach the tools but do not impart wisdom. The 2013 version of the Scrum Guide noted that it was “simple to understand but difficult to master.”
Adopting Scrum terminology became a poor substitute for agility. Simply overlaying practices without changing culture does not help and often makes things worse. Hour-long daily stand-ups, translating requirements into user stories just to meet the “right” format, or adopting Jira are just a few examples.
The agile mindset is naturally occurring. Watch children at play without parental supervision. They self-organize. They seek feedback and iterate. These natural tendencies are unlearned through education and the acculturation process in most enterprises. However, it does not have to be that way.
I lacked formal training when I started managing projects. My education was in Economics, not in engineering or software. My first exposure was building financial models in Lotus 1-2-3 (the now-defunct precursor to Excel). I was applying concepts to a new industry using a new tool and learning through experience. I would review my work (very) often with my boss and adjust what I was doing. It made sense; only later did I learn this was the iterative process.
My first big project was automating a mission-critical application for the U.S. Treasury Department and Federal Reserve. The lead developer suggested using screen prototyping (wireframes) to document the requirements. The application was essentially built in 6 months. It would have taken at least that long to document the requirements.
It’s About the People
The Agile Manifesto’s first value statement is “Individuals and interactions over processes and tools.” The 5thand 11th Agile Principles describe building teams around motivated individuals and recognizing that they will develop the best solutions. Jim Collins, in “Good to Great,” said that great leaders get the right people on the bus and put them in the right seats.
I have worked with great teams that operate with minimal process and with mediocre teams that rely on prescriptive processes. I prefer the former. It’s the people who solve problems and create innovative solutions. I remember a meeting where we faced a complex technical challenge. We brainstormed, argued, and drew pictures on a whiteboard. We found a solution quickly and remarked that it was easier than expected.
The challenge and the magic lie in creating a collaborative environment. Colocation and face-to-face interactions can create the right environment. Proximity and workspace design help. The Allen Curve shows that communication declines with greater distance. Technology can bridge the gap for remote, virtual, and hybrid teams, but there is more.
One of my offices seemed optimized for collaboration. The building was relatively narrow. Managers worked in offices with smoked-glass walls and no doors. Cubicles were low and had glass walls. It was easy to “visit with” and work as a team. Somehow, the quality and depth of collaboration extended to those in other cities, a phenomenon I am still pondering.
Create the Culture
Culture is paramount. You can have great, smart people. You can talk about an agile mindset. But if you have not created the culture, you will fail.
The secret to building and leading high-performing teams can be distilled into three simple rules:
- Create psychological safety;
- Empower the team; and
- Organize for simplicity.
According to Google, psychological safety is the single most important factor in creating high-performing teams. Its presence fosters innovation, creativity, and the passionate pursuit of excellence. Its absence creates a climate of fear and unproductive competition. Tim Clark defined four stages of psychological safety:
- Inclusion safety. You are part of the group.
- Learner safety. You are comfortable asking questions.
- Contributor safety. Your opinion matters.
- Challenger safety. You can question your peers and superiors.
Creating empowerment is simple. Let people make decisions. However, managers often struggle to let go. It’s scary. I am the boss; shouldn’t I have the answers? What if something goes wrong?
Relinquishing this control has a profound impact. Team members make good decisions—often better than the boss—and own the outcomes. If it was a bad choice, they are motivated to fix it. And the manager is freed from feeling they need to know and be involved in everything.
The 10th Agile Principle states that simplicity is the art of maximizing the amount of work not done. If we want teams to be innovative and creative, we need an environment (system) that fosters—rather than stifles—change.
I worked for companies that were opposites: a move-fast-and-break-things telecommunications provider and a risk-averse financial services company. The first was entrepreneurial (“Agile” had not been coined yet) and a fun, great place to work. The second tried to be agile but was constrained by its command-and-control culture, achieving only limited success.
Software (and Solutions) Evolve
A satellite needs to be perfect before it is launched. Software—and many other solutions—need only be good enough. Good enough is not bad. It means that sufficient functionality and quality expectations have been met to deliver value.
Projects often fall prey to the tyranny of the perfect over the good. I had users insist that a non-critical feature be available at launch. After delaying implementation to accommodate that request, they realized it was not what they wanted and asked for it to be removed.
All projects can benefit from rigorous prioritization and rationalization of features. Clearly define the minimum required features for each release, recognizing that the product will evolve. In the average software product, 80% of features are rarely or never used.
What does this mean? Perhaps Agile is not really dead. Agile is an idea, and ideas do not die. Instead, maybe we have reached the limits of exporting Agile practices, much as GM struggled to adopt the lessons learned from its joint venture with Toyota across other facilities. Transferring practices without the culture does not work.
I believe that we should return to the basics. Focus on mindset, people, culture, and evolving the solution, as they are the preconditions for being agile. The frameworks were meant to serve as guides for those already on the path.
© 2026, Alan Zucker; Project Management Essentials, LLC
See related articles:
- Back to Basics, Part 1: State of the Union
- Back to Basics, Part 3: The Approach
- Back to Basics, Part 4: Project Phases
- Back to Basics, Part 5: Way of Working
- Empowering Your Teams
- Simple Rules for High-Performing Agile Teams
- Simple Rules: Make it Easy
- Simple Rules: Psychological Safety
To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/.