Every growing engineering organization hits the same inflection point. Teams are struggling with coordination. Someone suggests “we need a framework.” And then the debate begins: “Should we use Scrum or Kanban?”
Most organizations waste months on this question—forming committees, hiring consultants, mandating frameworks. Six months later, teams struggle because one methodology was forced on everyone.
Here’s the real question: How do we give individual teams autonomy to choose what works while maintaining organizational planning visibility?
The reality is that your product team might thrive with Scrum. Your platform team might need Kanban. Your support team might run something entirely different. This isn’t chaos—it’s appropriate specialization.
The problem? Some tools force you to choose one or the other, reinforcing an all-or-nothing approach. Or they make cross-team planning difficult to reconcile and, in large organizations, nearly impossible when different teams use different approaches.
We built Atono to solve a different problem: enabling team autonomy without sacrificing organizational planning.
Individual teams should have the autonomy to choose what they want to use to get the job done. Not what leadership mandates. Not what the tool supports. What actually works for their context.
After 25 years of software leadership, I’ve observed these debates across hundreds of engineering organizations. When one methodology “wins” and is mandated, everyone eventually gives up and goes through the obligatory motions. I remember one customer who had a “forecasting” team whose sole job was to reconcile sprints, cycle times, and dependencies.
Different work contexts demand different approaches. A team building new features has different coordination needs than a team maintaining infrastructure. A team handling customer escalations operates differently from one planning quarterly releases. No single framework can optimize for all of these.
Teams also need the flexibility to change over time. What works for a five-person team doesn’t work for a fifty-person organization. What works during rapid growth often fails during product maturity. As context changes, teams need the freedom to evolve their approach.
When you mandate one methodology across an entire organization, a predictable pattern emerges. Teams adapt their work to fit the framework instead of the framework fitting the work. Productivity suffers because the process doesn’t match the problem. Teams game the system (”let’s just say everything is a two-week sprint”) or ignore it entirely. Methodology becomes bureaucracy instead of enablement.
The reality is that many teams are already running what’s sometimes called “Scrumban”—hybrid approaches that borrow from both frameworks. This isn’t a workaround—it’s teams adapting to reality.
Real autonomy means individual teams can choose Scrum, Kanban, or hybrid approaches based on what actually helps them ship. And they can change that choice when their needs change.
But team autonomy creates a different problem for organizations.
The challenge every leader faces: “Your team wants to run Kanban instead of sprints? That’s fine—but I still need to know what we’re delivering in the April release.”
According to Scrum.org research, 81% of Scrum Masters already use Scrum and Kanban together—yet most tools force teams to pick one or cobble together workarounds.
This isn’t just a visibility problem. It’s a forecasting complexity problem.
Scrum teams forecast with story points and velocity. Kanban teams use cycle time and throughput. When a product manager needs to answer “when will this ship?”—someone has to translate between two different systems by hand.
Scrum team says “Sprint 14.” Kanban team says “probably 3 weeks.” Leadership asks “will Feature X ship by March 15?” Someone has to reconcile these different formats. Manually. Again.
Story A (Scrum team, Sprint 12) depends on Story B (Kanban team, “in progress”). When does A actually start? When does the whole thing ship? This is where spreadsheets explode.
When velocity changes or a Kanban team hits a bottleneck, all downstream projections need manual updating across systems. Most organizations solve this one of three ways—and all of them are bad:
Option 1: Mandate one methodology. This kills team autonomy to gain planning simplicity. Multiple teams spend energy fighting the process instead of shipping.
Option 2: Let teams choose, plan in spreadsheets. This maintains autonomy but planning becomes manual hell. Hours spent copying data between tools and translating between systems. Plans are out of date the moment they’re created.
Option 3: Separate projects per team. Individual teams get their methodology but the organization loses cross-team visibility. Release planning requires jumping between 10 different views. Dependencies stay invisible until they break.
Linear optimizes for one continuous flow approach—cross-team planning only works if everyone runs the same way. Jira can technically support different methodologies but requires separate projects per team, breaking visibility across the organization.
You need tools that give individual teams autonomy AND give organizations planning visibility—with unified projections across methodologies. Not one or the other. Both simultaneously.
At Atono, our Vancouver and Victoria teams both use a mix of Scrum and Kanban. Different projects need different approaches. We needed to support team autonomy while maintaining release planning visibility.
Last week, we shipped features that reflect that reality.
Any team that chooses Scrum gets dedicated support: optimized backlog management grouped by sprint, burndown charts accessible with one double-click, and sprint calendar view.
Our design philosophy was simple: getting to your sprint details shouldn’t require multiple clicks through nested menus. In tools like Jira, reaching a burndown chart takes four or five clicks. We made it one double-click. When you’re managing sprints daily, those seconds add up.
Any team that chooses Kanban gets flow-focused features: continuous flow board views, cycle time optimization, and estimated completion dates.
When a team needs to split a story mid-sprint or track work flowing across teams, those capabilities work the same regardless of methodology. Individual teams can switch between approaches without reconfiguring everything. The tool adapts to the team’s needs, not the other way around.
This is where supporting both methodologies becomes more than just feature parity—it’s about unified forecasting.
When work crosses sprint boundaries or flows through Kanban, leadership can track what matters through Following. When teams need to right-size work whether planning sprints or optimizing flow, Split Story works for both.
Most importantly: you can see what all teams across the organization can deliver in April regardless of how they work. No spreadsheets. No jumping between projects. No manual translation between story points and cycle time. One view with unified projections across all teams.
Many tools have recognized the need for hybrid approaches—monday.com notes that “a strong Linear alternative should support fast issue tracking, flexible workflows (Scrum, Kanban, or hybrid).” But support is different from integration. Atono doesn’t just support both—it unifies planning across teams regardless of methodology.
Individual teams choose their methodology. The organization maintains planning visibility with unified forecasting. No configuration gymnastics. No forcing everyone to work the same way. No sacrificing one for the other.
We approached Scrum support with extreme focus. There’s not much room to innovate in Scrum itself—it’s a well-defined framework. Where we can innovate is in removing friction. Minimal clicks. Dogmatic adherence to what Scrum actually requires. Zero fluff. The behaviors to manage sprints should be as efficient as humanly possible.
Atono’s power comes from giving teams that autonomy without sacrificing release planning effectiveness.
Not “Should we mandate Scrum or Kanban?”
But “How do we enable team autonomy while maintaining organizational planning?”
When you reframe the question this way, everything changes.
What becomes possible: Individual teams choose what works for their context. Teams can evolve their approach as needs change. Leadership gets cross-team visibility for release planning with unified forecasting. Methodology debates disappear when tools stop forcing the debate. Teams focus on shipping instead of defending their process choice.
Team autonomy doesn’t mean organizational chaos. The right tool makes both possible simultaneously.
When we talked to product organizations after they started using Atono, the methodology debates just stopped—not because we solved them, but because the tool stopped forcing them. Teams focus on work instead of process.
Team autonomy and organizational planning aren’t trade-offs. They’re both table stakes. The question isn’t “Scrum or Kanban?” It’s “Why are we still using tools that force us to choose?”
We’ll dig into these specific topics live on January 27:
How to maintain unified planning visibility across different team approaches
Signs your team should switch methodologies
When frameworks start to break down and what to do about it
If you’re wrestling with these methodology questions across your teams, join us for a deeper conversation.
Webinar: “Scrum, Kanban, or both? How to design workflows that actually fit your team”
When: January 27, 2026 at 1pm PST
Duration: 45 minutes
Format: YouTube Livestream
Presented by: Tobias (CTO of Atono) and Aaron
Not every team works the same way—so why would one workflow rule them all? Join us for Inside Atono, where Aaron and Tobias dig into the trade-offs between Scrum, Kanban, and hybrid approaches. We’ll talk about when frameworks break down, what kinds of work thrive (or die) under sprint commitments, and how to build workflows that support your team instead of the other way around.
What you’ll learn:
When Scrum starts to crack under pressure—and what signs to watch for as your team or product matures
How to design workflows that encourage deep work and flow instead of constant context-switching and handoffs
Examples of hybrid approaches in Atono, including how to balance predictability with adaptability for remote and distributed teams
Who should attend:
Engineering leaders choosing methodologies
Product managers coordinating across teams
Teams feeling constrained by current frameworks
This post is public, so feel free to share it.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.