Agile in the AI World Is More Relevant Than Ever: The Twelve Principles
https://agilemanifesto.org/principles.html
For ease and economy of blog length I have grouped these 12 into the below 6 themes.
On Delivering Value to the Customer
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently.
Together these say the same thing: don't wait, don't be afraid to modify the plan, get something real in front of people, and let their feedback steer you.
AI shortens the cycle time on all three. Prototypes come faster and feedback loops close faster. A late change costs whatever committed work it invalidates, so when the build window compresses, there is less committed work sitting there to be invalidated at any given moment. That is the real reason welcoming change gets cheaper.
On the Primacy of Working Software
4. Working software is the primary measure of progress.
It seems the term “software” in today’s context may not be comprehensive enough. The word is now applicable to a much wider audience. Software used to mean the technology a specialized team spent months assembling. It now means something larger, faster and far more incremental. A working prototype built in an afternoon by a business analyst counts. So does a client who built their own version and sent it over. But the gap between a demo or prototype and production-level software still remains significant but the accessibility of building software is now greater than ever.
Whether or not you agree there could be a semantic adjustment here, the core point of this Principle has not changed: trusting evidence over plans is exactly what lets a team say the AI pilot didn't move the metric (so kill it) instead of defending an approved roadmap.
On Simplicity
5. Simplicity, the art of maximizing the amount of work not done, is essential.
(As a side note, the original Manifesto uses em dashes for this Principle instead of commas. I'm sure there are pockets of conspiracy theorists out there asking whether the Manifesto was AI generated).
The Manifesto authors were telling us the highest-value thing we can do, ironically, is often to not do the work at all. Too many projects shipped with only a fraction of the "required" features ever used, and too many knowledge workers burned their best years building waste.
AI gives us a new way to act on this Principle. Leveraging agents properly across the lifecycle frees up time for every contributor, letting us maximize the amount of work not done by a human at a scale few of us could have imagined in 2001.
Of course, with AI there is also the temptation to now try to do everything, as everything now seems attainable, even if the value may be suspect or the go to market is nonexistent. So even though the cost to build has dropped, superfluous work still has costs (training time, opportunity cost, simply gumming up the works). Teams must stay disciplined, using dynamically prioritized backlogs and focusing solely on prototypes that address genuine customer needs.
On Collaboration
6. Business people and developers must work together daily.
7. The most efficient and effective method of conveying information is face-to-face conversation.
While the use of the word Agile has at times lost favor, the concepts of the team and product owner seem to have become the standard for most organizations. Maybe the greatest persistent contribution from the Agile movement was the identified need for the team to instill robust feedback loops with users.
Like software, the word “developer” now covers more ground than it did in 2001. The democratization of access to AI tools throughout an organization means the person building the first working version is often not in engineering at all. Business people are increasingly becoming the builders, or at least the builders of working prototypes. Read "developers" as everyone building or deploying the system and the Principle holds.
With our clients, face-to-face conversation has not been replaced by AI. If anything, we are seeing human conversation, not documents, as the primary means of communicating requirements and acceptance. The power of showing the business a prototype, sometimes within hours, is game changing. "How does this look?" "Ok, well how about this then..." empowers the user to request near-immediate change.
On the Team
8. Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.
9. The best architectures, requirements, and designs emerge from self-organizing teams.
10. Sustainable development: the team should be able to maintain a constant pace indefinitely.
This was never meant to be a pro-anarchy position. It is a bet that people closest to the problem, given real autonomy, will find better answers than a framework imposed from above.
As new opportunities are identified through daily market interactions, the people on the ground have more ability than ever to seize the moment and experiment with what is possible. Doing this collaboratively with colleagues on the ground will result in an idea fountain of “what ifs.” This requires empowering our people and visibly incorporating their valuable contributions. An organization that can tap into this will build a capability in continuous innovation, and this capability will have them win tomorrow.
This is also the argument for letting teams experiment with new AI-native practices rather than forcing 2015-era ceremonies onto 2026-era tools. And sustainable pace is more achievable, not less, when AI makes it possible to move faster without the requirement of 70-hour work weeks.
On Craft and Continuous Improvement
11. Continuous attention to technical excellence and good design enhances agility.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Technical excellence does not go out of style because a machine can write more of the code. If anything, judgment about what good design looks like matters more when the volume of code goes up. The retrospective, regularly stopping to ask if there is a better way and then making the changes, is the exact continuous-improvement bias an organization needs right now, because the current rate of technical advancements requires constant recalibration.
To keep pace with a marketplace and competitors armed with agentic tools, we believe the goal should now evolve from continuous improvement to continuous innovation: constantly testing the market and internal processes, then applying new concepts that can improve performance and increase return. We will further discuss this concept in a later blog, but we believe it is key for differentiating and thriving in this new era.
Where This Leaves Us
Of the Manifesto's twelve Principles, none of them needs to be retired. The words did not need swapping either. What they point to got bigger. “Software” covers more than it did. “Developer” covers more than it did. Documentation now serves a reader that did not exist in 2001.
The Manifesto has been stress-tested before. Offshoring tested whether individuals and interactions could survive a twelve-hour time difference. The scaled frameworks tested whether self-organizing teams could survive a program office. DevOps tested how frequently working software could actually ship. AI is the harder test, because it changes the cost of building at the same time it changes who gets to build, and the values are holding up.
If the Values and Principles are doing fine, it is incumbent on us Agilists (remember when that's what we called ourselves, without needing to explain it?) to make sure this movement keeps evolving, by becoming the agents of change ourselves. Looking ahead, the Manifesto reminds us to cling to core values, shed obsolete habits, and continually adapt our practices.
So let's examine the practices next, and recalibrate for our new reality. In the next blog we will discuss scrum and share some examples of evolving practices we are seeing at clients.