When most people think about the Agile Manifesto, their minds go directly to the four values or the twelve principles. But the very first line—so often overlooked—may be the most powerful:
“We are uncovering better ways of developing software by doing it and helping others do it.”
This sentence reveals the mindset of those seventeen explorers who gathered in 2001. They weren’t writing commandments to be followed blindly. They were driven by humility in the face of complexity, and curiosity. They saw software development as a field in motion—something to be advanced by trying, learning, and sharing.
The values and principles that followed are insightful, yes. But if we forget the mindset behind them, we risk falling into complacency.
The Trap of “Best Practices”
In today’s Agile community, it isn’t always clear to me that this spirit of exploration is still alive. Too often, we fall back on the comfortable recipe book of “best practices” and are reluctant to let people self-manage to figure things out on their own.
Practices like User Stories, Daily Scrums, or Impact Mapping can be incredibly valuable—in context. They are “good practices,” not universally prescriptive ones. The moment we declare them “best practices,” we shut down curiosity.
Delivering value, discovering product–market fit, and organizing people for complex work are all complex problems. Complex problems cannot be solved by prescription alone. They require empiricism: forming hypotheses, running experiments, learning from outcomes, and deciding what to do next.
That’s why agile development is iterative and incremental. That’s why we have Sprints. That’s why we meet customers early and often.
The same mindset should apply not just to product development, but to how teams and organizations operate. Yet, once organizations adopt a framework—Scrum, SAFe, LeSS, XP, OKRs, the “Spotify model”, it doesn’t matter—they tend to cling to it, rather than continuously experimenting with how they organize.
Ask yourself: When was the last time your team or the broader organization intentionally ran an experiment on how to organize and work together more effectively?
The two personal stories below should provide insights about what such experiments can look like in practice, and the kind of learnings they generate.
Story #1: Stopping Scrum and See What Happens
One software product team I was supporting had been using Scrum for over three years. Scrum had become second nature, and by most accounts it was working well.
After releasing a major version, the team anticipated a large number of customer support requests and unpredictable change requests. During their Sprint Retrospective, one developer raised a bold idea:
“I think we don’t need a Sprint right now. Why don’t we stop Sprinting for a little while and just focus on responding to whatever happens next?”
The team agreed it was a reasonable, low-risk experiment. We switched to a Kanban-style approach for four weeks.
At the end of that period, we reflected. Customer support had stabilized, but something unexpected surfaced:
“I realized that having a Sprint Goal makes me want to do my best every day. I actually miss having a Sprint Goal…”
The team decided to restart Sprinting—with renewed energy and a stronger appreciation for Sprint Goals.
Our process was simple but powerful:
- Form a hypothesis: Things will be easier if we stopped doing Scrum for now.
- Run an experiment: Stop Sprinting for a little while.
- Reflect on the outcome: We miss Sprint Goals.
- Decide what to do next: Restart Sprinting, with greater focus on Sprint Goals.
Story #2: Experimenting with Different Team Structures
A sales and marketing department in a pharmaceutical company I was supporting had been running with cross-functional regional teams of about ten people, each with a designated “leader.” The setup had been stable for a year and seemed to be working reasonably well. The teams had learned to embrace transparency, to run small experiments, and to make most decisions on their own.
The Department Head noticed a common challenge across multiple regional teams: some members struggled to meet targets for similar reasons. We decided to experiment with something different. We created a temporary five-person team drawn from different regions. This new team of five was given a broad mission, no designated leader, and the freedom to set their own objectives.
Several Sprints later, the team achieved its mission and was disbanded. In their reflection, they identified three insights:
- Temporary teams are useful and surprisingly not that disruptive to the rest of the organization.
- Smaller teams of five are a lot more effective at exploring ideas and making decisions than the usual and larger teams of ten.
- Not all teams need a designated leader—removing the role can increase ownership and speed up results.
A month later, the Department Head decided to apply these learnings (especially 2.) more broadly, splitting all teams into two.
Again, the pattern was clear:
- Form a hypothesis.
- Run an experiment.
- Reflect on what happened.
- Decide what to do next.
Embracing Empiricism Beyond Product Development
When teams and organizations recognize that finding the best way to organize and work together is just as complex as building products that delight customers, they begin to see Empiricism as a universal tool.
By contrast, when leaders cling to frameworks or “best practices,” they close the door to curiosity and experimentation. And without curiosity, continuous improvement stalls.
The first line of the Agile Manifesto is a reminder: Agile is not a finished recipe—it is a mindset of exploration. We are still uncovering better ways, together, by doing it and helping others do it.
So my question to everyone is: What experiment will you run next?
ー
Gregory Fontaine is among about 350 Professional Scrum Trainer™ (PST) at Scrum.org and the CEO at Agorax GK. He has many years of experience applying Scrum both in software development and in a variety of other fields. He was the first Japanese speaking PST and has been supporting clients and students in Japan for many years.