Modern Agile Best Practices

Peter Zatloukal

Audience: Product development teams, and anyone curious what software process looked like just before agents.
Reading time: ~20 minutes.

July 2026 preface: I finished this in November 2025 and never published it. What follows the preface is the document substantially as I wrote it, because its timing turned out to be the most instructive thing about it.

Why This Sat in a Drawer

I spent a good part of last fall writing the document below. It was going to be my masterpiece: thirty years of shipping software, distilled into one long guide to modern Agile practice. Everything I’d learned about sprints, estimation, stand-ups, retrospectives, and empowered teams, written down in one place. I finished it in November 2025, did a final editing pass, and felt pretty good about myself.

Then a friend read it. He’s a professional software engineer, and at the time his team was aggressively experimenting with agentic coding practices at work. This was full agentic software engineering, for professional use only, well past vibecoding: they completely understood that they had to own all of the results, and they’d rebuilt their working process around that fact. His review: “Good stuff Peter, but I don’t even do estimations for Jira cards anymore. In the time I would do an estimation exercise, I just build it instead.”

I was scandalized. Estimation is load-bearing in the document below; there’s a whole section on it, with techniques and stories and hard-won opinions. And he was completely right. When building the thing costs about as much as discussing the thing, the discussion stops earning its meeting slot. It doesn’t end with estimation, either. Most of the ceremonies below exist because implementation used to be expensive. You planned carefully because building was slow. You estimated because capacity was scarce. You stood up daily because ten humans hand-writing code for two weeks drift apart. Change that one constant and the ceremonies don’t exactly become wrong. They become optional.

There’s an irony buried in the estimation section that I didn’t spot until he handed the document back to me. It tells the story of a young team of AI researchers who dropped estimation from their sprints, and how I bit my tongue, let the data decide, and learned something about empowerment. Apparently I needed to learn it twice.

And this isn’t a niche story about one unusual team. The entire professional software engineering community is being utterly disrupted by the advent of agentic coding. Token costs for coding are now budgetary line items. Software engineering jobs, possibly less so. The change is profound, it’s still accelerating, and it arrived within weeks of me typing the conclusion below. I’d written my masterpiece just in time for it to historically cease to be the crucial ingredient in creating software. No wonder I called my later article The Bitter Lesson of Agentic Coding.

So why publish it at all? Two reasons. First, as a time capsule. This is my best description of how durable human teams coordinated to build software, written at the last moment when that was the whole game, and I think it holds up as a record. Second, because more of it survives than I expected. Read “sprint” as “turn,” “definition of done” as “acceptance criteria,” and “retrospective” as “the handoff artifact,” and long stretches of this document describe an agentic coding loop with the timescale collapsed from weeks to minutes and the team roster swapped for a fleet. The ceremonies were never really the point. The feedback loops were, and those came along for the ride.

What follows is the document as I finished it in November 2025, lightly edited for length and voice (the original claimed a reading time of about an hour, and read in places as if a committee wrote it; it was all me).

What This Is

This is a practical guide to Agile-based product development: what the practices are actually for, and how teams can make high-quality choices about customizing and growing their own internal practice to increase velocity, improve communication, and hit their customer objectives. If you’re reading it, you’re probably already familiar with many of the concepts, either from experience or from the thousand other things written about Agile. What I’m offering is the subset that has proven out over many years of building and scaling tech products, along with opinions about which variants work best.

There is no one-size-fits-all approach to software development practice. There are, however, methods that have held up over time, and modern Agile practice has converged enough that a person moving from one high-performing team to another will find more similarities than differences.

A note on the word “team.” Throughout this document I mean product teams: durable groups of roughly 4 to 15 people (software engineers, dev leads, AI researchers, technical program managers, quality and infrastructure engineers, product managers, designers) who are focused on, and measured by, customer outcomes. Jeff Bezos dubbed these “two-pizza teams,” on the premise that a team executing on customer goals should be able to share a full meal with no more than two large pizzas.

“Durable” is doing real work in that definition. These teams aren’t assembled for a single engagement or feature set. They’re structured to persist as cohesive, mission-oriented units that build deep domain expertise, ownership, and accountability for their product area. Rather than disbanding after a release milestone, a durable team evolves its scope as customer needs change, carrying forward the lessons, context, and trust that make iteration faster and decisions better. Progress compounds instead of resetting.

Large software products usually involve several product teams plus a lot of other important functions (executive sponsors, marketing, sales, and so on). The product team is the unit this document cares about.

Where Software Methodologies Came From

Building software products is a young field. Construction has roots going back to antiquity; organizing large-scale software efforts doesn’t have a complete playbook yet.

In the early days of computing, programming teams were small. Where larger-scale organization was needed, people copied structures that already existed: military hierarchies, surgeon-and-assistants models. As the PC revolution created demand for something tailored to the complexity of large software in a brutally competitive industry, the early “methodologies” for organizing software projects emerged.

One book from that era is still worth reading today: “The Mythical Man-Month” by Frederick Brooks, written in 1975. It’s dated in spots, but it originated the then-radical idea that software engineering is a fundamentally human process, not a mechanical one, and that traditional management assumptions about productivity and scaling don’t work for creative, collaborative work.

There’s a story I love about Microsoft’s first Program Manager, Jabe Blumenthal. He joined Microsoft in 1981 as a software developer, and while working on Excel for Macintosh, which was struggling under the weight of its own complexity, he started taking on responsibilities beyond coding: coordinating feature decisions, writing specifications, serving as the bridge between engineering and user needs. Bill Gates recognized the hybrid role and formalized it, with Jabe as the first person to hold the PM title. These days there are so many definitions of “PM” that you need a conversation just to establish which one is meant (Jabe’s version is closest to what’s now called a Technical Program Manager). But there was something special about that original role, and at Microsoft it shaped how software development was organized for decades.

There are many methodologies for organizing software projects: Waterfall, Agile, Spiral, Rapid Application Development, and so on. Some people date the modern era to right around Jabe’s story, because it marked a shift in how software was conceived: away from rigid, sequential processes and toward a collaborative, iterative, user-centered model. The recognition that someone needed to bridge customer needs, technical feasibility, and delivery reality in a flexible way foreshadowed most of what Agile would later advocate.

What Agile Actually Is

Agile isn’t a software methodology. It’s closer to a philosophy, and the specific methodologies (Scrum, Kanban, and friends) are implementations of it.

If you’ve never actually read the Agile Manifesto, it’s worth a moment. It was written in 2001 as a response to the frustrations and failures of the heavyweight, plan-driven approaches that dominated the industry through the 1980s and 90s, Waterfall above all.

To say the Agile mindset took off is an understatement. Thousands of books and articles later, the simple point remains: empower the real product development team, the engineers and designers and product managers doing the work, to make decisions, adapt quickly, and deliver value to customers at high velocity. Remove the bureaucratic bottlenecks. Emphasize customer focus, collaboration, feedback, and autonomy. Teams that truly embrace this see every iteration as a way to learn through building.

Agile was never designed as a tool for managers to control teams. It’s a framework for teams to self-organize, respond to change, and deliver through continuous, iterative progress. And while it’s hard to quantify, Agile done well makes the work more enjoyable for the participants, which has subtle but real effects on morale and productivity.

That all sounds great. How do teams actually apply it? The most common answers are some form of Scrum or some form of Kanban, and after a couple of decades of industry-wide experimentation, the usage patterns are fairly mature. The rest of this document walks through them.

Anti-Goals

Agile is remarkably powerful when applied with intent and critical thinking. It can also devolve into ritual theater: a set of motions that look productive without producing meaningful progress. The purpose of Agile is to create rapid learning loops that drive customer value. Anything that gets in the way of that should be examined and discarded.

Agile anti-patterns tend to emerge when teams confuse activity with progress. Long stand-ups, overly detailed story-point debates, and mechanically filled-out templates can make a team feel organized while actually slowing it down. A sprint that delivers no customer learning is just a two-week waterfall.

This guide is also not meant to turn Agile into a management control system. When Agile becomes a mechanism for top-down reporting and compliance, it loses its soul along with its effectiveness. In the worst case it becomes window dressing for top-down planning, sometimes called “Scrummerfall.” Product teams must stay empowered to decide how to achieve outcomes. Leaders should measure results (product quality, customer adoption, learning velocity), not how precisely a team follows a prescribed framework.

Finally, Agile isn’t static doctrine. Teams should feel free to question every element, stand-ups and estimation and backlog refinement included, and keep only what demonstrably helps them deliver customer impact. The anti-goal of this document is to prevent Agile from becoming a checklist. The real success metric is whether the team is learning faster and delivering more customer value sprint over sprint.

Scrum, Mostly

Scrum is a complete software development methodology, and today Scrum and its variants are the most commonly adopted Agile approaches. You can adopt it in its entirety, but what I see more often, and what I recommend, is product teams choosing the Scrum practices that suit them and evolving them over time. Teams making their own choices about their own process is the essence of Agile; the philosophy and the outcomes matter more than any specific ritual or tool.

Below are the elements I’ve seen lead to great customer and product outcomes. There are variants of each; I’m deliberately describing the versions that have worked best over time.

Sprints

A sprint is a timeboxed iteration, typically 1 to 4 weeks, during which the team produces a usable, testable product increment. Unless you have a specific reason to choose otherwise, start with 2-week sprints.

A sprint is a focused work cycle: the team commits to a set of goals, builds something tangible, then reflects and improves before starting the next cycle. The reason this works so well sounds simple but is actually quite powerful: a short span of work with a clear entry and a clear exit lets teams learn fast, adapt fast, and deliver continuously. Contrast Waterfall-style planning, where by the time the team learns there’s a significant mistake in the design, the customer approach, or the technology selection, months of development may already be sunk.

The typical phases of a sprint:

Each in turn.

Sprint Planning

Ideally every sprint has a simple theme that everyone understands and agrees to: “implement end-to-end single sign-on for the home page,” say. It isn’t always possible to get a tagline that clean, but it’s worth some effort, because a theme makes it easy to tell at retrospective time whether the team accomplished what it set out to do, and it helps everyone operate autonomously in the same direction. The least interesting theme is “finish the top n items in the backlog,” so anything that ties the planned work together better than that is encouraged.

Backlogs are central to planning, and the term has layers. The basic definition: a prioritized list of work items (features, bug fixes, enhancements, technical tasks) representing everything the team might build. In practice this often means a set of Jira issues (or Trello, or Linear) sitting in the backlog column of a board (more on boards below). But at a higher level, the product backlog is a living, ordered list of everything that could be built for the product, owned and maintained by the product team.

The most important input to good sprint planning is an overall roadmap for the product, from inception through launch and beyond. Roadmap development is iterative, and there’s rarely a complete roadmap before development starts (in an Agile process, anyway; Waterfall completes the plan first, which is more or less the opposite of Agile thinking). In Scrum-speak, the decomposition flow is:

Large theme (“Epic”) → individual function (“User Story”) → implementation steps (“Task”)

When those elements exist, sprint planning is the team deciding which tasks to take on for this sprint, informed by technical needs (“build the infrastructure first so the features go faster”) balanced against business needs (“the CEO needs a prototype for a key customer, so rough out the UI now and refactor later”).

Early in a product’s life, teams are often still writing technical design docs, debating key features, and roughing out the roadmap. Here the Agile move is for the team to behave in an empowered way: call the shots as they see them, and be accountable for those calls. This is why empowerment is so central. In a planning meeting, a disempowered team is at a loss for what the sprint is even for, and ends up executing arbitrary tasks or pulling in incompatible directions. An empowered team reasons over the key customer goals and makes the best choice available (“we know for sure we’ll need user management and telemetry, so let’s start there while we refine the roadmap with our partner teams”).

Estimation

Sprint planning usually includes an estimation phase: a quick, dynamic conversation about who’s taking which items and how big each one is, with items assigned to individuals in whatever tracking system the team uses (they can be traded later; see stand-ups).

The main failure mode is false precision. If someone estimates a task down to the hour (“this will take me 1.25 hours”), either that task should be folded into a larger one or, more likely, the estimate is just wrong. The opposite failure is the same problem at the other scale: “this task will take me 3 sprints” is non-Agile in its construction. I’ve personally been on the receiving end of this pushback (“but folks, that’s how long it will take!”) and benefited from being made to decompose the work, both because I understood it better afterward and because smaller units are simply a more Agile way to approach a problem. Yes, some items, particularly infrastructure, genuinely take months. Decompose them anyway.

The classic Scrum approach uses story points instead of time: points express how big a piece of work is relative to other work, keeping the focus on comparative effort rather than exact duration. I’ve seen both story points and time-based estimates succeed. If you use time, pick a minimum granularity, one day for example. Some teams require Fibonacci numbers (1, 2, 3, 5, 8, 13, 21) specifically to fight false precision: how do you know your task will take exactly 10.5 days? You don’t. Pick 8 or 13.

Another technique worth knowing is “schedule poker”: everyone, including the person picking up the task, chooses a card with their estimate and all cards are revealed at once. The value is in the conversation it forces. If I played a 1 and everyone else played 5 or higher, either I’m dramatically more efficient than my teammates (possible, unlikely) or the group understands the task differently than I do, maybe around integration difficulty or actual scope. Now we can talk about it.

Some teams skip the ceremony entirely and have members enter estimates into the tracking system offline, without discussion. That’s fine too. The only genuinely important thing is that enough information exists for a meaningful retrospective later.

I once led a young team of very capable AI researchers and engineers, strong academic backgrounds, little industry experience, and taught them these techniques. After a few experimental sprints, they came back and told me they’d decided to drop the estimation phase from sprint planning entirely. My first response was mild shock and an instinct to explain that this simply isn’t optional. Then I remembered that our goal together was to learn and embody an actual Agile approach, not my Agile approach. So I bit my tongue, and all I asked was that they keep an eye on how their output progressed sprint over sprint (which they were measuring by counting completed tasks). The data showed their choice was working. And later, as the scope of their work grew, they organically decided to add a simple, effective estimation step back into their planning. They found their own way to the practice, which is worth more than being handed it.

Working in Order, and Cutlines

Be intentional about working tasks in priority order. The backlog should be a numbered list where lower number means higher priority, and generally speaking, individual tasks should be done in that order. Why do a lower-priority task before a higher-priority one?

For a given sprint, it’s also good practice to draw a “cutline” (literally a row of hyphens, or whatever your tool supports) between the last item committed for this sprint and, by implication, the first item of the next.

Since the product team owns the ordering, changing it as new information arrives is trivial. The value comes from the act of noting the change and thinking about relative priorities, which forces a balance of customer, technical, and business inputs. And to be clear, thoughtfulness matters more than perfect adherence; even updating the ordering mid-sprint is optional (stand-ups communicate what’s happening day to day, and as long as the list is trued up at the next planning session, the discipline holds).

The discipline pays off in two places:

Internal communication. At a stand-up, it’s completely reasonable for a teammate to ask why I’m working several lower-priority items ahead of higher ones. There are good answers: we discovered a dependency on something we’d thought was low priority, so I’m doing it first. I found a simplification that knocks out several small items at once and I’m taking the opportunity. We learned something that changes relative priority and I’m just working the smarter order without renumbering mid-sprint. Or, sometimes, the question is a useful reminder that I should deliver the urgent things first. Every one of those is a conversation worth thirty seconds.

Fewer arguments. Teams get pressure, internal and external, about delivery urgency. An ordered list with a cutline tends to minimize, sometimes completely eliminate, those arguments. Suppose a business stakeholder shows up at my desk excitedly demanding we prioritize a key new feature. Rather than pushing back, I can show them the ordered backlog with the cutline (ideally for the next sprint) and ask which committed items they’d postpone to make room. The discussion shifts from a single task to the overall program. Maybe they look at the list and realize the committed items really are more critical and the feature can wait. Maybe they make the case that we should postpone something, with an actual argument about relative priority attached. Either way the team has captured a stakeholder’s insight in a usable form, instead of having a hallway argument.

Not a panacea, but a strong sense of prioritization plus the discipline of working in order has proven to be one of the most useful tools I know.

Sprint Execution

For most of the sprint, the team develops, tests, and integrates work toward the sprint goals, collaborating continuously and using whatever implement/test/deploy pipeline it has chosen (CI/CD or similar). Three things are worth calling out inside execution: broken sprints, spikes, and the definition of done.

Broken sprints. Occasionally an interruption is significant enough to stop a sprint outright. There are usually two ways this happens. One: the team discovers a technical dead end, anything from a failed hypothesis on a high-invention-risk problem to a key vendor going out of business, and continuing the planned sprint makes no sense. Two: a customer or business change lands that must be addressed immediately. Ordinarily, stakeholders outside the team know that the right time for input is the next sprint planning meeting (“yes, of course, first thing next sprint”), and short sprints make that an easy sell. But sometimes the event can’t wait: a serious security incident, or a strategic pivot that changes the fundamental nature of the product. Then you stop the sprint.

Broken sprints should be rare and consequential. If they’re happening regularly, something is significantly wrong in the organization or the operating model, and that’s the thing to analyze and fix. If they’re happening casually, no post-mortem, no weight, that’s a sign the Agile process isn’t really being followed or the team is disempowered, which is also an organizational problem.

Spikes. A spike (the term comes from Extreme Programming; it’s the software equivalent of driving a spike into the ground to see what’s below the surface before building on it) is a timeboxed research or exploration task, used when the team needs knowledge before it can commit to building or estimating something. A spike should end with clear, actionable output: a recommendation (“use library X”), updated estimates, refined backlog items. Spikes can be planned in the backlog (“we’ll need this to make a later choice”), planned during sprint planning (“none of us can estimate this, so let’s prototype a piece of it first”), or purely reactive (“why are logins failing? Are we under a denial-of-service attack?”).

Definition of Done. It may seem surprising, but a team can hold many simultaneous, incompatible ideas about what “done” means. Too often someone reports they’re done with an item… except for the unit tests. Oh, and it hasn’t been deployed. Also the documentation isn’t finished. This isn’t laziness; it’s a reflection of how many things are on the mind of a busy product developer. The fix is for the team to write its own Definition of Done checklist and politely self-enforce it. Example entries:

Those are examples; the mechanism is what matters. The key property of a done item is that it exits all active tracking, meaning the card leaves the board. With an agreed DoD, if I claim an item is complete, it’s polite and reasonable for a teammate to check that it actually meets the definition, and having that be a normal, friction-free part of the process adds real efficiency.

Stand-Up Meetings

Stand-ups happen during the sprint, as often as daily (2 or 3 times a week is also common; start daily unless there’s a good reason not to). Aside from sprints themselves, this is the most widely adopted Scrum technique, used even by teams that aren’t otherwise into Scrum.

They’re called stand-ups because a meeting the whole team takes standing tends to be much shorter than one taken sitting around a conference table. No, you don’t literally have to stand. Honestly though, it helps.

I’ve seen plenty of hour-long meetings called “stand-ups” that wander across every topic a team has. Schedule whatever meetings you need, but those are not stand-ups and shouldn’t be called that. The format of a well-run stand-up is nearly fixed, and teams that change it tend to lose the benefits. Each team member speaks in turn, then the meeting ends. Each turn is:

  1. “This is what I did since the last stand-up” (a sentence or two about their current tasks)
  2. “These are the tasks I’m planning to do next” (usually just the task names)
  3. “Here’s where I’m blocked” (if applicable)

For a team of ten, the whole thing should take less than fifteen minutes. The format is powerful because of how efficiently it coordinates the sprint. If everyone reports progress and plans with no blockers and no comments, almost no time was spent on status. If someone is blocked, this is the moment to inform the team and recruit help, though not to actually solve it in the meeting; the correct phrase is “let’s sidebar this after stand-up,” so only the necessary people spend the time. Same if someone disagrees with another person’s next task (say they’re waiting on a different item and want it first): raise it, then sidebar it. The temptation to problem-solve on the spot is strong. Even as someone who teaches this technique, I’ve caught myself starting to debug some status item mid-meeting, only to be told, politely, “let’s sidebar this.” Being on the receiving end of your own training is humbling, and the meeting stayed short, which was the point.

Sprint Retrospective

The retrospective is the final event of a sprint: the team reflects on how the sprint went, across people, process, and tools, and identifies concrete improvements for the next one. It’s a continuous-improvement meeting, not a blame or reporting meeting. Importantly, it’s for the product team only, no external stakeholders. There are many ways to report status outward, and this is emphatically not one of them (though a separate meeting afterward to publish committed metrics to stakeholders is common and fine).

An effective retrospective requires a high degree of trust among participants. The internal learning loop is a big part of what makes Agile work, and the retrospective is where that loop closes. Teams customize this phase more than any other, but the recurring elements I’ve seen work:

Generate insights. Discuss patterns, and how the sprint felt: how well it was planned, how understandable the tasks were, how the team dynamics played out.

Completed versus estimated. This is a nuanced internal metric, and, to repeat, not for outside reporting. It’s common for a team to push itself on up-front goals and regularly land, say, 60% of them. That’s not a failure to be fixed; it’s information for planning. If the completion rate sits at 60% sprint over sprint and everyone’s happy with the arrangement, fine. What’s interesting is when the rate moves significantly in either direction, because that opens good internal questions: are we getting more efficient? Are we being too optimistic, or not optimistic enough? “Why did this change?” matters far more than the absolute value. This is also a good moment to verify that completed items actually meet the Definition of Done.

What to do better next sprint. Identify a few actionable improvements and track them, possibly as backlog items. Some teams use a start/stop/continue format for this.

Demos

Distinct from retrospectives, post-sprint demos for interested parties are a great practice. Invite anyone from external stakeholders (sales, marketing, business development, executive sponsors, legal) up to the whole company where practical. In my experience these are usually very well attended, and the show-and-tell format is invigorating for presenters and audience alike, on top of the cross-team communication it buys you. Done well, they’re genuinely fun.

The typical format is a few team members demonstrating output from the sprint. For UI-heavy products, showing new functionality is an obvious win: it shares visual progress and gets people thinking about the customer experience. But code-heavy output (internal tools, new APIs) demos well too. Something as simple as a team member running the unit tests in a terminal while explaining the new functionality is meaningful even to non-technical stakeholders. It shows what’s under the hood, builds understanding of the team’s priorities, and tends to generate enthusiasm and outside ideas.

The common thread: demos shouldn’t require much preparation, if any. If the Definition of Done is being honored, any completed item is a demo candidate. Most teams still gravitate to the coolest recent work, and it’s worth being democratic about it so everyone gets a turn to show off.

The First Few Sprints

For teams that already have an Agile practice, I hope this document is a source of refinements. For teams that are new to it (or experienced teams starting a brand-new program), a few observations about booting up.

A “sprint zero,” a practice run with expectations set low, is a good way to start what is ultimately a journey. Unless there’s a reason to do otherwise, begin with the Scrum-flavored process described here (Kanban, below, is also a reasonable starting point). The important part of any early sprint is the team understanding that this is their process, and its care and feeding is what they’re empowered, and expected, to do.

The first few sprints of a new team tend to be… pretty rough. Skepticism about the whole approach is common, debates over the techniques are typical (“why should I do this meeting standing up?”), and early retrospectives are often depressing (“we really only achieved 20% of our goals?”). Persistence pays. A lot of the early work is really people figuring out their teammates. It varies, but in my experience, by sprint 3 or 4 the team is seeing the value, and a few sprints after that they’ve forgotten there was ever friction. Even if the team eventually settles on longer sprints, stick to 2 weeks initially (or even 1, where practical) to speed up adoption and ownership.

Kanban

Kanban is an Agile methodology focused on visualizing work, managing flow, and continuously improving delivery. It originated in Toyota’s Lean manufacturing practices in the 1940s and was adapted for software as a lightweight, flexible framework for making work visible and optimizing how it moves from start to finish.

Some people look down on Kanban as “Scrum lite.” I’ve found it scales to surprisingly large development efforts, especially when customized with other Agile concepts like sprints and stand-ups. You can teach a software team Kanban in fifteen minutes and significantly upgrade their productivity over an ad-hoc or no-process approach.

Boards

A Kanban board is a visual system for managing workflow. It shows all the work the team is currently doing as “cards” moving left to right through columns representing stages of work:

A whiteboard and post-it notes is a perfectly good Kanban board (though most teams use software: Jira, Trello, Linear). Each card is a single unit of work, a feature, bug fix, task, or research experiment, and every card moves rightward as it progresses. This simple visualization gives everyone a shared, real-time picture of what’s being worked on, who’s doing what, and where things are stuck.

The board’s effectiveness comes from managing flow. Because it’s updated in real time, it exposes bottlenecks, dependencies, and idle work instantly. If the Review column keeps filling up while In Progress runs empty, the review process is the constraint, and the team can decide whether to adjust staffing, simplify review, or rebalance. A well-maintained board is a living reflection of the team’s operational health.

Work-in-Progress Limits

Most teams add WIP limits: caps on how many cards a column can hold at once. The limits prevent multitasking overload and push people to finish existing work before starting new items. Digital tools also track cycle times and throughput automatically, which feeds retrospectives.

The subtler benefit is that WIP limits make invisible workload pressure visible. When the In Progress or Testing column hits its limit, that’s a clear, data-backed signal that capacity has been reached. Instead of a developer having to explain that they’re overloaded, or push back personally on new requests, the board communicates it objectively. Managers and stakeholders see the constraint as a shared, visible fact rather than a negotiation. WIP limits shift the conversation from “work harder” to “let’s improve how work flows,” and they protect focus and trust while doing it. Presumably Toyota assembly-line workers in the 1940s appreciated the same property: the board pushes back on the hierarchy so the workers don’t have to.

Kanban vs. Scrum

Unlike Scrum, Kanban has no fixed-length sprints and no formal roles. It’s a continuous-flow system: work is pulled in as capacity frees up, rather than planned in advance for a timebox. This makes it especially effective for operational or research-oriented teams where priorities shift frequently or work items vary a lot in size. Over time, teams use Kanban’s metrics, cycle time (how long an item takes to cross the board) and throughput (items completed per period), to find and fix inefficiencies.

Since true Kanban has no sprint boundary, the Done column gets emptied either periodically (weekly, monthly, or when it exceeds some count) or on a rolling window (say, keeping the last 30 days of completed work visible, which gives a quick visual sense of velocity). In Scrum, Done is typically emptied at the end of each sprint, ideally with a Definition of Done check on each card on its way out.

Scrum Boards

Scrum boards are descended from Kanban boards but usually have more stages (which is why post-it notes give way to digital tools). Example columns for an online-service team:

Does Agile Work with AI Research?

The short answer is yes, and in my experience properly aligned Agile sprints can actually accelerate the invention velocity of AI research. But the orchestration is tricky, and it requires adjustments on both sides: to the typical sprint process, and to the open-ended, hypothesis-driven cycles that define AI experimentation.

[July 2026: this whole section is about AI as a component of the product. The disruption came from the other direction, AI as the builder of the product, and I never saw it coming from inside my own document.]

Invention Risk vs. Execution Risk

Invention risk is inherent to experimental work: the outcome is uncertain, the path is non-linear, and success often depends on discovering something that has never been done before. Execution risk arises when the idea is sound but the challenge is delivering it: building, scaling, and operationalizing within time, budget, and quality constraints.

Software products without an AI component are mostly about execution risk (for the implementation, anyway; market risk and customer risk are their own topics). Software methodologies are, at heart, tools for managing execution risk.

Add AI components and you add invention risk, especially when new research or beyond-state-of-the-art models are needed. Invention risk shows up even in applied research with off-the-shelf models, because there’s still uncertainty about whether they’ll perform adequately in a new context, integrate cleanly, or generalize to real-world data. Most applied work also involves adaptation, direct fine-tuning, in-context learning and prompting, RLHF, RAG, which raises the invention risk further. Every application of AI introduces unknowns about model performance, data quality, and emergent behavior that can only be resolved by experiment.

Managing product design under invention risk is beyond this document’s scope, but the core insight is to design the product so that flexibility absorbs uncertain experimental outcomes. If your computer vision product wants 95% accuracy, how would you design it so it still delivers customer value if 75% turns out to be the ceiling under real product constraints?

Integrating Research into Sprints

Research timing can’t be estimated the way user stories and bug fixes can. If the team is working on beyond-state-of-the-art experiments, nobody knows when, or whether, the breakthrough happens, and a softer version of the same is true of applied research and integration. This doesn’t mean research can’t live inside sprints. It means creativity is required to harmonize invention-risk work with execution-risk work.

During planning, it makes no sense to ask a researcher “how many units of research this sprint?” It makes complete sense to estimate the delivery of an initial model to integrate against (even one far from its accuracy targets), or to track the start, progress, and end of specific experiments. At retrospective time, a failed experiment deserves as much celebration as a successful one: the null hypothesis held, the data spoke clearly, and the team learned something real instead of chasing an assumption. Everyone roots for the experiments, but visibility into actual research progress is what informs the team’s intuitions about how the AI components affect schedule, design, and testing.

Researchers benefit from the arrangement too. Research is often done against carefully curated data, with goals like matching published numbers for a given architecture. That matters, but so does how the product behaves in heterogeneous, real-world conditions, and an Agile product team is a machine for discovering exactly that. Building prototypes, creating test infrastructure, and learning how the product feels automatically shines light on gaps in data diversity (poor lighting, weird camera angles, unexpected hallucinations) and keeps research goals blended with customer-experience goals.

For teams pursuing frontier research, success depends as much on stewardship of the research process as on technical execution. As in an academic lab, the culture should have experiments shared transparently, iterated with purpose, documented carefully, and retired without blame when the results invalidate the hypothesis. The most effective pattern I’ve found is researchers maintaining their own internal stewardship process, with its rigor and continuity, while staying aligned with the broader team’s Agile rhythm.

Conclusion

Agile, at its core, is a philosophy of learning through doing. The goal was never to “be Agile”; the goal is to be effective, and to continuously improve how the team turns ideas into customer impact. Every sprint, every retrospective, every iteration is a chance to get a little better at that.

Over the years I’ve watched Agile succeed in environments as different as enterprise software delivery and cutting-edge AI research. What separates high-performing teams isn’t adherence to any particular process. It’s clarity of purpose, ownership, and trust. Teams with the autonomy to make decisions, learn from results, and adjust course without fear of failure consistently outperform organizations that put structure and central planning ahead of adaptability and customer focus. The practices in this document, sprints, retrospectives, backlogs, boards, exist to support that autonomy, and the best teams keep reshaping them to fit their mission while staying true to the spirit of transparency, feedback, and continuous improvement.

Empower small, durable teams to learn quickly, deliver value often, and grow their capabilities over time. That principle holds whether you’re launching a new software product or exploring frontier AI research, and it’s the closest thing to a universal law I’ve found in thirty years of doing this.

That’s where the document ended in November 2025. Reading the conclusion back now, “empower small, durable teams to learn quickly, deliver value often,” it still sounds right to me. You just have to let the word “teams” drift a little.