Most teams can recite the Agile Manifesto on autopilot. Few can explain why their daily habits actually serve the work. That gap is exactly what a new guide from Maarten Dalmijn tries to close, and it's the headline of the latest edition of age-of-product.com's long-running Food for Agile Thought newsletter (issue #402), shared with 48,061 peers.
The guide, still labeled V0.8, argues you can talk about the core of Agile without ever mentioning the word "Agile" or quoting the Manifesto. It's a deceptively small shift in framing with surprisingly large consequences for how you run stand-ups, set your Definition of Done, and judge whether a team is healthy. The same newsletter also surfaces fresh thinking on platform-team collaboration, sustainability as a Done criterion, AI's missing user docs, and the discipline of saying no.
Key facts
- The 402nd edition of Food for Agile Thought highlights Dalmijn's "Agile From First Principles Guide V0.8," which reframes Agile without the usual jargon.
- The issue was shared with 48,061 peers, according to age-of-product.com.
- Pierre Pureur and Kurt Bittner propose adding sustainability criteria to a team's Definition of Done.
- Pete Hodgson, writing on Martin Fowler's site, argues platform teams need different collaboration models per phase of migration, consumption, and evolution.
- Ethan Mollick flags the AI industry's neglect of user documentation, while Jason Cohen pushes for a metric system rather than a single KPI.
How we got here
Agile has spent two decades accumulating luggage. Certifications, ceremonies, Jira dashboards, role wars between PMs and Scrum Masters, all of it piled on top of four values and twelve principles that were originally written for a much smaller world. By the early 2020s, a typical mid-sized company had three "agile transformations" under its belt and a workforce that could pass a Scrum quiz without changing how it actually worked.
The reflexive answer to that fatigue has been either to ship yet another framework (SAFe, LeSS, Scrum@Scale, you name it) or to declare Agile dead. Dalmijn's bet, judging by this guide, is a third path: forget the brand, keep the mechanics. Talk about feedback loops, working in small batches, and the cost of rework. Let the word "Agile" show up in the org chart, not in your daily decisions.
What changed in this issue
The guide itself is the center of gravity. Everything else in issue #402 orbits it. Pureur and Bittner take a related swing by asking teams to bake sustainability into their Definition of Done, so "done" stops meaning "merged" and starts meaning "we can live with this for years." Hodgson (writing on Martin Fowler's blog) goes after the silent killer of large orgs: platform teams that try to use one collaboration model for migration, consumption, and evolution, then wonder why nothing sticks.
You also get two sharper pieces for product leads. Cohen argues against single-number metrics and for a small system that serves different stakeholders. Mollick points out, wryly, that the AI industry keeps shipping faster than it documents. And there's a recurring "saying no" thread, in a Steve Jobs clip from WWDC'97 and in Catherine Norris's product-management writing, that pairs neatly with Dalmijn's stripped-down framing.
Our analysis
Stripping labels is more than a stylistic choice. It changes who gets to disagree. When "Agile" is the brand, pushback sounds like heresy. When "Agile" is replaced with a working principle like "shorten the feedback loop," a skeptical engineer is just doing their job. That, more than any certification, is how blameless retrospectives actually become blameless.
The trade-off is real, though. Without shared vocabulary, a team can't easily onboard new hires, audit its own health, or compare notes with another squad. The strongest teams we see treat first principles as a default state, then layer light conventions on top so newcomers can find their footing. If Dalmijn's V0.8 is adopted widely, watch for a wave of homegrown vocabulary that fills the gap, and for the inevitable confusion when two teams mean different things by the same word.
Who benefits? Senior leads trying to fix a stuck transformation. Who loses? Consultants selling framework rollouts. The interesting middle case is the platform team, which is already drowning in shared-services ambiguity. Hodgson's piece lands hard there: pick a model, name the phase, then move on.
A practical example for your sprint
Say you are a team lead, and your squad's retro has been a polite campfire for two months. Run one experiment using Dalmijn's framing. In the next planning meeting, skip the word "sprint." Instead, ask three questions: What's the smallest thing we can ship this week and learn from? What would tell us, by Friday, that we're wrong? What's blocking us from finishing the thing we already started? Capture the answers as principles, not tickets. Then, in retro, look at whether you honored them. You'll learn more about your team in two cycles than in a quarter of story-point debates.
While you're at it, steal one idea from Pureur and Bittner. Add a single sustainability line to your Definition of Done, something like "this can be maintained by one person on call without paging anyone." Watch how quietly the design conversations change.
Bottom line: what to watch next
Keep an eye on Dalmijn's V0.9. If he keeps the no-label stance but adds concrete patterns teams can copy, this guide could quietly outlast the next framework wave. Track whether more teams start publishing their own "first principles" one-pagers. And watch the platform-team conversation: as more engineering orgs split into product and platform halves, the collaboration model per phase is the argument that will quietly decide who ships and who litigates.
The throughline of issue #402 is simple. Names age. Habits don't. Build the habits, and the framework will follow.
Key takeaways
- Try running one planning meeting without the word "sprint" and see what changes in the conversation.
- Add a sustainability line to your Definition of Done so "done" means more than "merged."
- For platform teams, name the current phase (migration, consumption, or evolution) before picking a collaboration model.
- Treat metrics as a small system serving different stakeholders, not a single KPI.
- Use first-principles framing to lower the cost of dissent in retros.
Frequently asked questions
What is the Agile From First Principles Guide?
It's a V0.8 draft from Maarten Dalmijn, highlighted by age-of-product.com in Food for Agile Thought #402. It tries to explain Agile's core mechanics without using the word "Agile" or quoting the Manifesto.
Why do "first principles" matter for project managers and Scrum Masters?
They shift the team's vocabulary from brand-level terms to working habits like feedback loops and small batches, which makes pushback feel safer and retros more honest.
How do Pureur and Bittner suggest changing the Definition of Done?
They propose adding sustainability criteria, so architectural and operational longevity become part of what "done" means for a Minimum Viable Architecture.
What did the newsletter say about platform teams?
Pete Hodgson's piece, hosted on Martin Fowler's site, argues platform teams need different collaboration models for migration, consumption, and evolution, rather than a single shared process.
What's the practical first step for a team lead reading this?
Run one planning meeting using plain questions instead of Agile jargon, then judge the team by whether the answers held up by retro.