The Dao of Scrum
How achieving flow state, can empower your teams, delight your customers, and create a product that is a joy to build.
“The Master does his job and then stops.” –Dao De Jing, trans. Stephen Mitchell
Disambiguation & Context
Before we dive in, let’s establish a few key points:
Dao ≠ DAO — This article references The Dao (道) or “the way”, meaning the fundamental, ineffable source and flow of all things; as opposed to the Distributed Autonomous Organization (DAO) model associated with blockchain and Web3.
Scrum is a Means, Not an End — While Scrum is the primary reference framework here, these insights apply to any iterative development model (Kanban, Lean, AgileFall, Shennaniban, et al). Kanban, in particular, was built around flow — the concept central to this discussion. Kanban specifically deserves recognition as the methodology most commonly affiliated with those who aim to cultivate it. In general, the message here isn’t strict adherence to a framework or process — but rather it’s creating the conditions for flow to arise both intentionally and spontaneously.
Speed Does Matter, But Not at Any Cost —In the race to develop AI-driven services and tools, the ability to iterate quickly is critical. But no matter what we’re building — or why — the fundamental principles of work remain the same: Speed without sustainability leads to burnout, degraded quality, and diminishing returns. True velocity isn’t just about moving fast for the sake of speed and throughput alone; but rather it’s about moving fast in a way that lasts. Striking that balance isn’t always easy, but it is what we should be aiming for.
Preface
This wouldn’t be the first time that tech has been inspired by Eastern philosophy. The Agile Manifesto was shaped by ideas of adaptive planning and continuous improvement, concepts that mirror Zen and Daoist thinking. Lean development (from Toyota) and Kaizen (continuous improvement) are Japanese frameworks that have become deeply embedded in the way we build software today.
Many of our most effective software methodologies aren’t just new inventions — they reflect principles that have been understood for thousands of years. And honestly — why reinvent the wheel?
The Speed Myth: Why “Move Fast” Often Fails
“Rushing into action, you fail. Trying to grasp things, you lose them. Allow your work to flow, and it will unfold naturally.” –Dao De Jing, trans. Stephen Mitchell
My startup journey was one of the most cherished times of my career. Building a business with friends is a dream that few get to experience, and I had the fortune of having done so for almost a decade. It was a journey of many twists and turns, and lessons that serve me till this day, and this is one of them. Early in my startup journey, we faced an all-too-familiar problem.
We were outgrowing our initial phase of fast prototyping and experimentation. Our engineers now had deadlines, roadmaps, and real customers relying on timely delivery. Suddenly, velocity became the metric that defined engineering success.
Naturally, we did what many startups do:
We pushed for tighter deadlines.
We stretched our bandwidth thinner and thinner.
We hit the gas.
The result? The opposite of what we intended.
Velocity suffered and was unpredictable due to cognitive overload and mounting technical debt.
Quality suffered, leading to slowdowns from bug fixes and instability.
Burnout increased.
Despite our best intentions, we had fallen into a common trap: “If we’re not going fast enough, we just need to work faster. If we’re not delivering enough, we just need to do more.”
I started putting in nights and weekends. I booked AirBnB getaways to get prototypes done over the weekend so I wouldn’t be distracted by my usual social and neighborhood shenanigans.
Like trying to sprint a marathon. I had moments of speed, but the inevitable crash was just a matter of time. And when it came, it hit hard.
“The Way of Effortless Action”
“Do nothing, and everything gets done.” — Laozi
At first glance, this quote makes no sense. Laziness is not what is advocated for here. Instead, a passage like this points to the concept of Wu Wei (无为) : often translated as effortless action or action without force.
Wu Wei isn’t about doing nothing — it’s about doing things in alignment with the natural flow of a system, rather than constantly pushing against resistance. There’s a story about the butcher who was able to effortlessly butcher an ox you can check out. He could do this not because of brute strength, but because he moved with the natural structure of the animal, cutting along the spaces that already existed.
This principle is everywhere around us:
Flowing rivers carve through solid mountains by following the path of least resistance.
Trees grow strong by bending with the wind, not fighting against it.
A skilled rider moves with the horse, rather than trying to control every step.
All this points to the idea that when you stop forcing, things move naturally.
We’re not just dealing with rivers, trees or oxen here. This principle is just as relevant to software teams. When teams align with the natural rhythms of work — minimizing friction, working with constraints rather than against them — they unlock greater efficiency and creativity.
Agile, at its best, is a framework designed to work with that natural flow — creating space for teams to iterate, adapt, and move forward without burning out.
In this article, we’ll explore how software teams can apply these principles — not as rigid doctrine, but as a way to build products that are not only effective and user-friendly but also built in a way that makes them efficient and sustainable to develop. When teams operate functionally, the software they create follows suit.
Paradoxes
Nature moves in cycles — expansion and contraction, action and rest, effort and ease. Daoist philosophy embraces this rhythm as fundamental to how things function.
Ignoring balance leads to dysfunction. This was true when these principles were first articulated, and it remains true today. If anything, with the rapid feedback loops we now rely on in most aspects of modern work, the impact of imbalance is felt even more acutely.
This isn’t mystical retribution, folks— it’s just how systems work. When balance is ignored, either the product suffers, or the people building it do. Oftentimes, it’s both.
The biggest mistakes in software development come from pushing harder when we should be easing up, planning more when we should be adapting, and forcing outcomes instead of letting them emerge.
And strangely, some of the most effective ways to actually move faster, build better, and lead stronger teams appear paradoxical at first glance:
To speed up, sometimes you have to slow down.
— Rushing leads to rework. Thoughtful pacing prevents waste.By doing less, more is accomplished.
— Focusing on what truly matters — not just checking off tasks — yields better outcomes.Strength comes from flexibility.
— The ability to adapt and course-correct is far more valuable than rigidly sticking to a failing plan.
Sustainable high performance in software doesn’t come from constant acceleration — it comes from intentional pacing. It’s about balancing deep work with reflection, iteration, and recalibration — getting back on beat whenever the rhythm demands a pause.
So, the goal here isn’t to move as fast as possible — it’s to sustain momentum without collapse. The goal isn’t to rigidly follow a plan — it’s to stay adaptable, embracing change while continuing to deliver value. And lastly, the goal isn’t to do everything — it’s to focus on the right problems, solving what matters most with precision and impact.
When teams enter a flow state, they naturally find themselves working this way.
“The best way to predict the future is to create it.” — Peter Drucker
Turning a Corner
With leadership buy-in, our VP of Engineering and I, as a Lead Engineer, pursued Scrum certification training. Armed with this knowledge — and with the guidance of a seasoned Scrum expert on our team — we made a fundamental shift in the way we worked.
We kept velocity as an internal metric, using it as a tool for continuous improvement, not as an external pressure point. We became disciplined in our sprint commitments, taking on only what we could confidently deliver. At first, this felt like we were slowing down — but then over time we experienced how that in doing less, we were accomplishing more things. Instead of feeling constrained, morale started to improve as we consistently crushed our targets. Let’s break down what happened.
To speed up, we first had to slow down.
We worked hard — but we also paused when needed. We paused to pair, we paused to plan, and we paused to reflect. Retrospectives weren’t just ceremonial check-ins; they became spaces for honest reflection, where we confronted our pain points head-on and actively supported each other in improvement. Major refactors weren’t side projects or afterthoughts — they were scheduled, intentional work, ensuring that our product remained adaptable as it evolved.
Our strength came from flexibility.
By optimizing for flow, we became even better at responding to pivots and shifting priorities — without losing momentum on long-term product goals. We were no longer just reacting to change — we were embracing it, while keeping our team and product stable.
We worked together as a unit.
But more than just process changes, Scrum taught us to work in harmony across disciplines. Product Owners and Engineers were aligning toward the same goals. Some tasks took longer than expected, some were surprisingly fast — and we respected that reality. Engineers were active participants in product ideation, and Product Managers were deeply engaged in technical conversations. We became a true unit.
But one of the most important shifts we made was in how we structured our time.
By doing less, we accomplished more.
In all likelihood inspired by Google’s 20% time, we did something radical: we took a full day off from structured development every other week. No sprints, no planning, no expectations… just space for engineers to breathe, think, and reset.
Ironically, this was a game changer.
Free time for recalibration, deep thinking, and learning.
Space for collective exhalation and creative problem-solving.
A deliberate shift that pulled us out of mindless execution and kept us in thoughtful craftsmanship.
By creating some more space, we cultivated the energy to do so much more.
The results of all these changes? Velocity climbed steadily. What started as X points per sprint for a four-person team grew to an average of 2X, sometimes even 3X. Not because we pushed harder — but because we worked smarter, were more aligned, and found a sustainable rhythm that fueled itself.
To speed up, we first had to slow down.
To get strong, we had to become flexible.
By doing less, we learned how to accomplish more.
The Flow State of Agile: Beyond Mechanical Execution
Many teams today follow Scrum or some form of Agile methodology — yet I know plenty of folks reading this are thinking: “We do Scrum, but we don’t get these benefits at all.”
You’re not alone. But I’d argue the issue isn’t with Scrum itself — it’s with how and why it’s applied. Too often, teams use Scrum as a set of rituals rather than what it was meant to be: a tool for enabling flow.
Flow state is that cognitive sweet spot where engineers, designers, and product teams work with full immersion and minimal friction.
It’s the state described by:
🎭 Dancers on the stage — when movement and music become one.
🏂 Extreme sport athletes — when instinct replaces thought.
🛠️ Master craftspeople — when creation feels effortless.
It’s the moment when force is relinquished, and momentum takes over on its own. And this concept applies just as much to software engineering. When engineers hit flow, the work feels fluid, natural, and self-sustaining. But when misapplied, Scrum can just as easily introduce friction rather than remove it — turning into a blocker instead of a facilitator.
Scrum or any other framework isn’t the goal. Flow is the goal. Frameworks exist to provide the tools to help get you there. But flow state isn’t something you can force — it’s something you allow by creating the right conditions for flow to arise.
“Slow is smooth, and smooth is fast.” — Attributed to the Navy SEALs
Creating the Conditions for Flow State in Product Development
For teams to reach and sustain flow, the environment must support it. The right conditions remove friction, eliminate unnecessary barriers, and allow momentum to take over. Here’s what makes flow possible:
Autonomy: AKA “Get Out of the Way!” → Engineers need clear goals but maximum freedom to execute. Micromanagement isn’t exactly part of this equation.
Uninterrupted Focus → Flow cannot exist when engineers are constantly context-switching or pulled into unnecessary meetings.
Trust in Oneself, the Process, and the Team → Psychological safety removes hesitation, allowing deep engagement and risk-taking.
Clear Goals with the Right Challenge Level → Work should be engaging, not overwhelming — difficult enough to be exciting but not so hard that it induces anxiety. The team’s capacity should not atrophy, nor should it be brought past an irreparable edge for too long.
Immediate Feedback Loops → Fast CI/CD, observability tools and alerts, and collective retrospecting ensure the product remains in sync with performance targets, and teams stay in sync with their goals.
A Sense of Meaning & Purpose → Engineers hit flow when their work actually matters — when they feel connected to the product, the users, and the mission.
Flow isn’t a luxury — it’s what makes high-velocity engineering possible.
When Scrum is applied correctly, it isn’t about rigid processes or ceremonies — it’s about creating the conditions where flow state can emerge and sustain itself.
Don’t Just Take Our Word For It
Several well-known companies have transformed their operations by adopting flow-centric and Agile methodologies:
How “Focus Time” impacted Basecamp, Microsoft, Shopify and Github by cultivating flow: https://devdynamics.ai/blog/focus-time-and-its-impact-on-developer-productivity/
The well known Spotify Model; and how the organization took the principle of autonomy and learned how to scale it up: https://www.atlassian.com/agile/agile-at-scale/spotify
Another article on the Spotify Model; this one with a kick-ass title:
A Symphony of Agile Scaling, Autonomy, and Continuous Improvement
https://www.linkedin.com/pulse/spotify-model-symphony-agile-scaling-autonomy-continuous-improvement-anzge/JP Morgan Chase and others embraced Agile practices to achieve product releases every three weeks, significantly boosting productivity and responsiveness to market demands. https://www.growthaccelerationpartners.com/blog/real-life-examples-of-agile-methodology
The Real Need for Speed in the AI Race
Today’s AI boom has shifted the landscape of software development. Companies racing to deploy AI-driven solutions face unprecedented pressure to move fast.
AI research is progressing exponentially, meaning the window to establish market dominance is shrinking.
Compute resources are scarce, requiring companies to optimize not just speed but efficiency in deployment.
Regulatory landscapes are evolving, making it critical to iterate quickly while maintaining compliance.
So yes — speed matters more than ever. But confusing urgency for chaos is a recipe for disaster. The companies that will win the AI race are not the ones that burn their engineers out with reckless deadlines but the ones that build teams capable of delivering at a fast but sustainable cadence.
The key is not brute-force acceleration but designing engineering workflows that sustain flow state over time
But Where Do We Start?
You don’t have to declare “process bankruptcy” like we had done in order to start benefiting from these principles. Small, intentional changes can begin shifting your teams toward a more sustainable, productive, and fulfilling way of working.
Start committing to less.
Set realistic goals based on what your team can actually achieve — not what you hope they can. Track real throughput, adjust expectations accordingly, and prioritize outcomes over busyness.Audit your processes.
Gather qualitative and quantitative feedback to identify what’s working and what’s killing productivity. Which meetings, handoffs, or rituals add value, and which ones drain energy? What tools are adding friction to the process? What is taking up space and no longer delivering value? More importantly, will you have the courage to make changes?Integrate restorative cycles.
Work hard together — but also rest together. This isn’t about adding another vacation day or relying on weekends. It’s about creating space within the work itself to pause, reflect, and learn. Give the team deliberate, structured time to step back from execution and digest, recalibrate, and grow.Realign your team’s purpose.
Bring your team together to redefine what you’re aiming for, why it matters, and how you measure success. When teams understand their mission and feel ownership of it, engagement and flow follow naturally. And most importantly, do this often.
You don’t need a revolution — just the willingness to take the first step. Where will your team begin?
Join the Conversation 👇🏼 💬 📣
Have you experienced similar transformations in your organization? Do you believe these principles are practical, or do they seem too idealistic? Share your thoughts and experiences in the comments below. Let’s learn from each other’s journeys.