What is Agile?

If you've ever been part of a project that spent months building something, only to discover at launch that the market had moved on or customers wanted something completely different, you'll understand why Agile exists. I've seen this happen more times than I'd like to admit, and it's painful every single time. (I've written about and how my thinking has evolved over the years—from following frameworks religiously to finding what actually works.)

Agile is fundamentally about learning fast and adapting quickly. Instead of betting everything on one massive release, you break your work into smaller chunks that you can actually ship and get feedback on. Think of it as having multiple checkpoints where you can course-correct, rather than driving blindly toward a destination that might not even be there anymore.

Here's what I find most interesting: Agile isn't really a set of rules you follow. It's more like a mindset. There's no Agile police coming to check if you're doing your standups exactly right. What matters is whether you're getting quick feedback loops and continuously improving based on what you learn.

Companies turn to Agile when they realize they can't predict everything upfront. Markets change, customers change their minds, and new competitors emerge. Agile lets you respond to all of this without throwing away your entire plan. You plan just enough to get started, ship something small, learn from it, and then decide what's next.

But here's what really makes Agile work—and this is the part that gets overlooked too often: it's about people first. The puts it beautifully: real conversations matter more than following processes, working with your customers beats negotiating contracts, and actually delivering something useful is more valuable than perfect documentation.

When I've seen Agile teams thrive, it's because they own their work. They decide what "done" means, they set their quality bar, and they figure out their own pace. Sure, it can feel scary at first to give teams that much autonomy. But what I've consistently observed is that when you trust a team and give them the space to work, they usually exceed what anyone thought was possible.

Scrum

Agile vs. scrum

I get asked this question all the time: "Wait, isn't Scrum the same as Agile?" Not quite, and understanding the difference actually matters.

Think of it this way: Agile is the philosophy—the "why" behind how we work. It's the belief that we should iterate, adapt, and continuously improve. Scrum, on the other hand, is one way to actually do it—the "how." It gives you specific practices, roles, and ceremonies to follow.

You can't just flip a switch and become agile overnight. It requires your whole team to rethink how they deliver value to customers. Scrum helps with this by giving you concrete practices to start with. It's like training wheels for building an agile mindset—you follow the framework while you develop the underlying thinking patterns.

Now, here's something I appreciate about Scrum: it's structured but not rigid. You can adapt it to fit your team's reality. There are plenty of opinions out there about the "right" way to do Scrum, but in my experience, what really matters is keeping clear communication, transparency, and continuous improvement at the center. The rest? You figure out what works for your context.

The spells out the core values beautifully:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Scrum builds on two big ideas: empiricism and lean thinking. Empiricism basically means "learn by doing"—you make decisions based on what you observe, not what you assume. Lean thinking is about cutting out waste and focusing on what actually matters.

What I love about Scrum is that it admits upfront: we don't know everything at the start, and that's okay. You're going to learn as you go. The framework is built around this reality. Short cycles, frequent reprioritization, constant learning—it all adds up to a system that bends without breaking when circumstances change.

The scrum team

A Scrum team is intentionally small—usually around 10 people max. It's small enough that everyone knows what everyone else is doing, but large enough to actually get meaningful work done. You need three key roles: product owner, scrum master, and the development team. And when I say "development team," I don't just mean developers. I mean everyone who builds the thing—testers, designers, UX folks, ops engineers, the whole crew.

The scrum product owner

Think of the product owner as the team's connection to reality—to customers, to the market, to what actually matters for the business. They're the ones constantly asking "what should we build next?" and making tough calls about priorities. Good product owners:

• Keep the backlog clean and prioritized (trust me, this is harder than it sounds)
• Make sure everyone understands why we're building what we're building
• Give the team clear guidance on what's most important
• Decide when things are ready to ship (usually pushing for "sooner rather than later")

Here's something that trips people up: product owner ≠ product manager. They might be the same person, but they're different jobs. The product owner is laser-focused on making sure the dev team delivers maximum value. And critically, you need ONE product owner, not three. I've seen teams get whiplash from conflicting priorities when multiple people try to fill this role.

The scrum master

The scrum master is your process guardian. They're not your project manager (common misconception). They're more like a coach who helps the team get better at working together and removes obstacles that slow everyone down.

Great scrum masters really understand the work the team is doing. They can spot when things are getting stuck and help get them unstuck. They organize all the Scrum ceremonies—planning, standups, reviews, retrospectives—and make sure everyone has what they need to participate effectively.

The scrum development team

This is where the magic happens—the team that actually builds stuff. The best Scrum teams I've worked with are tight-knit groups of 5-7 people. You've probably heard of Jeff Bezos's "two pizza rule"—if your team can't be fed with two pizzas, it's too big. There's wisdom in that.

What makes these teams work is that everyone has different skills, and they teach each other. No one becomes a bottleneck because multiple people can pick up the work. They're self-organizing, meaning they figure out how to tackle problems together rather than waiting for someone to tell them what to do.

The team plans each sprint themselves, estimating how much they can realistically complete based on what they've done before. Keeping sprints the same length is important—it gives you consistent data on how you're estimating and delivering, and you get better at forecasting over time.

Scrum artifacts

Artifacts sounds fancy, but really these are just the key pieces of information your team needs to stay aligned. There are three main ones: the product backlog, sprint backlog, and the increment (with your "definition of done"). Think of them as your team's shared reality.

• Product Backlog - This is your master to-do list. The product owner owns it, and it's constantly evolving. Features, bugs, enhancements—everything lives here in priority order. What I love about a good backlog is that it's alive. The product owner is always grooming it, reprioritizing based on what they're learning from users and the market. Items that seemed critical last month might become irrelevant this month, and that's fine. That's the whole point.

• Sprint Backlog - This is what the team commits to building right now, in this sprint. During planning, the team picks items from the product backlog that they think they can finish. Now here's an important nuance: the sprint backlog can shift a bit during the sprint if new information comes up. But the overall sprint goal? That stays locked. You don't change what you're trying to achieve mid-sprint.

• Increment (or Sprint Goal) - This is what you actually built and can potentially ship. Some teams ship every sprint—their "done" literally means "live in production." Others, especially if they're working on enterprise software with quarterly releases, might work in 2-week sprints where "done" means "ready for the next release." Neither approach is wrong, but here's the catch: the longer you wait between actual releases, the higher the risk that you've built something the market doesn't actually want anymore.

Scrum ceremonies or events

Scrum has a handful of regular meetings—what we call ceremonies. I'll be honest: some teams love them, some teams find them tedious. My advice? Try all of them for a couple of sprints and see what actually helps your team. Then adjust. You'll know pretty quickly which ones are valuable and which ones feel like box-checking.

Here are the main ceremonies you'll encounter:

1. Organize the backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner's main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time.

2. Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific user stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint. At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.

3. Sprint: A sprint is the actual time period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment. Dave West, from Scrum.org advises that the more complex the work and the more unknowns, the shorter the sprint should be. But it's really up to your team, and you shouldn't be afraid to change it if it's not working! During this period, the scope can be re-negotiated between the product owner and the development team if necessary. This forms the crux of the empirical nature of scrum. All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the development period. This helps the team learn from past experiences and apply that insight to future sprints.

4. Daily scrum or stand up: This is a daily super-short meeting that happens at the same time (usually mornings) and place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that's just a guideline. This meeting is also called a 'daily stand-up' emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. The stand up is the time to voice any concerns you have with meeting the sprint goal or any blockers. A common way to conduct a stand up is for every team member to answers three questions in the context of achieving the sprint goal: What did I do yesterday? What do I plan to do today? Are there any obstacles? However, we've seen the meeting quickly turn into people reading from their calendars from yesterday and for the next day. The theory behind the stand up is that it keep distracting chatter to a daily meeting, so the team can focus on the work for the rest of the day. So if it turns into a daily calendar read-out, don't be afraid to change it up and get creative.

5. Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now 'Done' to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released. This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.

6. Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn't work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.

Scrum values

Commitment

Because scrum teams are small and agile, each team member plays a significant role in the team's success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in stand-ups.

Courage

Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays, and so on.

Focus

At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers. Usually the scrum teams address these questions:

• What did I work on yesterday?
• What am I working on today?
• What issues are blocking me?

This helps to highlight progress and identify blockers. It also helps to strengthen the team when everyone shares progress.

Respect

The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other's accomplishments and are respectful to one another, the product owner, stakeholders, and the scrum master.

Kanban

While Scrum dominates the conversation around Agile, Kanban has quietly become one of my favorite approaches, especially for certain types of teams. What's fascinating is that Kanban's roots go back to 1940s Toyota—way before anyone was talking about agile software development.

The story starts with supermarkets. They figured out they should only stock what customers actually buy, right when they need it. No massive overstock gathering dust. Toyota looked at this and thought, "We could apply this to manufacturing." So they created a system where workers would pass cards (kanban in Japanese) between stations to signal when more materials were needed. It was brilliantly simple: only make what's needed, exactly when it's needed.

Fast forward to today, and software teams are using the same principles. Instead of inventory, we're managing work in progress (WIP). The idea is to match how much work you have going at once to what your team can actually handle. When you do this right, you get more flexibility in planning, faster delivery, better focus, and way more transparency.

The beauty of Kanban for software teams is how low-friction it is to start. Unlike setting up a Kanban system on a factory floor—which requires physical changes and materials—all you really need is a board and some cards. And even those can be digital. You can literally start tomorrow.

Kanban boards

The work of all kanban teams revolves around a kanban board, a tool used to visualize work and optimize the flow of the work among the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.

Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.

The kanban methodology relies upon full transparency of work and real-time communication of capacity. Therefore, the kanban board should be seen as the single source of truth for the team's work.

Kanban cards

In Japanese, kanban literally translates to "visual signal." For kanban teams, every work item is represented as a separate card on the board.

The main purpose of representing work as a card on the kanban board is to allow team members to track the progress of work through its workflow in a highly visual manner. Kanban cards feature critical information about that particular work item, giving the entire team full visibility into who is responsible for that item of work, a brief description of the job being done, how long that piece of work is estimated to take, and so on. Cards on virtual kanban boards will often also feature screenshots and other technical details that is valuable to the assignee. Allowing team members to see the state of every work item at any given point in time, as well as all of the associated details, ensures increased focus, full traceability, and fast identification of blockers and dependencies.

The benefits of kanban

Kanban is one of the most popular software development methodologies adopted by agile teams today. Kanban offers several additional advantages to task planning and throughput for teams of all sizes.

Planning flexibility

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team's workflow – from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a bottleneck of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too.

In a kanban framework, it's the entire team's responsibility to ensure work is moving smoothly through the process.

Fewer bottlenecks

Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenet of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

Visual metrics

One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they're continuing to improve. When the team can see data, it's easier to spot bottlenecks in the process (and remove them). Two common reports kanban teams use are control charts and cumulative flow diagrams.

A control chart shows the cycle time for each issue as well as a rolling average for the team, while a cumulative flow diagram shows the number of issues in each state. The team can easily spot blockages by seeing the number of issues increase in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blockage in these states can increase the likelihood of massive integration conflicts when the work does get merged upstream.

Continuous delivery

Continuous delivery (CD) is the practice of releasing work to customers frequently. Continuous integration (CI) is the practice of automatically building and testing code incrementally throughout the day. Together they form a CI/CD pipeline that is essential for development teams (especially for DevOps teams) to ship software faster while ensuring high quality.

Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on precisely that: optimizing the flow of work out to customers

Scrum vs. kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another.

Agile Metrics

Let me tell you about metrics—they're complicated. I've been on teams where we tracked nothing, and honestly, it was like flying blind. Are we going to make the release date? Are we getting faster or slower? No idea. But I've also been on teams where metrics were used as weapons—pitting teams against each other or justifying why everyone should work weekends. Neither extreme is healthy.

The truth is, when done thoughtfully, metrics can actually help your team. They reduce confusion, show you where you're making progress, and highlight where you're struggling. The key word is "thoughtfully."

Know your business

Here's something that took me a while to learn: shipping features on time isn't enough. You need to ship the right features at the right time for the right market. That's why you need to track both business metrics (is this solving a real problem for customers?) and agile metrics (is our process healthy?).

For each major initiative, I recommend setting up a few key performance indicators (KPIs) that actually matter to your business. And for each feature, define success criteria upfront—maybe it's adoption rate, or test coverage, or whatever makes sense for you. These feed into your agile metrics and create a feedback loop where you're constantly learning and adapting.

How to use agile metrics to optimize your delivery

Sprint burndown

Scrum teams organize development into time-boxed sprints. At the outset of the sprint, the team forecasts how much work they can complete during a sprint. A sprint burndown report then tracks the completion of work throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the sprint.

A team that consistently meets its forecast is a compelling advertisement for agile in their organization. But don't let that tempt you to fudge the numbers by declaring an item complete before it really is. It may look good in the short term, but in the long run, it only hampers learning and improvement.

Anti-patterns to watch for:

• The team finishes early sprint after sprint because they aren't committing to enough work.
• The team misses their forecast sprint after sprint because they're committing to too much work.
• The burndown line makes steep drops rather than a more gradual burndown because the work hasn't been broken down into granular pieces.
• The product owner adds or changes the scope mid-sprint.

Epic and release burndown

Epic and release (or version) burndown charts track the progress of development over a larger body of work than the sprint burndown, and guide development for both scrum and kanban teams. Since a sprint (for scrum teams) may contain work from several epics and versions, it's important to track both the progress of individual sprints as well as epics and versions.

"Scope creep" is the injection of more requirements into a previously-defined project. For example, if the team is delivering a new website for the company, scope creep would be asking for new features after the initial requirements had been sketched out. While tolerating scope creep during a sprint is bad practice, scope change within epics and versions is a natural consequence of agile development. As the team moves through the project, the product owner may decide to take on or remove work based on what they're learning. The epic and release burn down charts keep everyone aware of the ebb and flow of work inside the epic and version.

Anti-patterns to watch for:

• Epic or release forecasts aren't updated as the team churns through the work.
• No progress is made over a period of several iterations.
• Chronic scope creep, which may be a sign that the product owner doesn't fully understand the problem that body of work is trying to solve.
• Scope grows faster than the team can absorb it.
• The team isn't shipping incremental releases throughout the development of an epic.

Velocity

Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations–the more iterations, the more accurate the forecast.

Let's say the product owner wants to complete 500 story points in the backlog. We know that the development team generally completes 50 story points per iteration. The product owner can reasonably assume the team will need 10 iterations (give or take) to complete the required work.

It's important to monitor how velocity evolves over time. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time, and can confirm that a particular process change made improvements or not. A decrease in average velocity is usually a sign that some part of the team's development process has become inefficient and should be brought up at the next retrospective.

Anti-patterns to watch for:

When velocity is erratic over a long period of time, always revisit the team's estimation practices. During the team's retrospective, ask the following questions:

• Are there unforeseen development challenges we didn't account for when estimating this work? How can we better break down work to uncover some of these challenges?
• Is there outside business pressure pushing the team beyond its limits? Is adherence to development best practices suffering as a result?
• As a team, are we overzealous in forecasting for the sprint?

Each team's velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn't mean that team B has higher throughput. Since each team's estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team's unique interpretation of story points.

Control chart

Control charts focus on the cycle time of individual issues–the total time from "in progress" to "done". Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

Measuring cycle time is an efficient and flexible way to improve a team's processes because the results of changes are discernable almost immediately, allowing them to make any further adjustments right away. The end goal is to have a consistent and short cycle time, regardless of the type of work (new feature, technical debt, etc.).

Anti-patterns to watch for:

Control charts can appear fickle at first. Don't be so concerned with every outlier. Look for trends. Here are two areas to watch out for:

• Increasing cycle time - Increasing cycle time saps the team of its hard-earned agility. In the team retrospective, take time to understand an increase. One exception: if the team's definition of done has expanded, cycle time will probably expand too.
• Erratic cycle time – The goal is to have consistent cycle time for work items that have similar story point values. Filter the control chart for each story point value to check for consistency. If cycle time is erratic on small and large story point values, spend time in the retrospective examining the misses and improving future estimation.

Cumulative flow diagram

The cumulative flow diagram should look smooth(ish) from left to right. Bubbles or gaps in any one color indicate shortages and bottlenecks, so when you see one, look for ways to smooth out color bands across the chart.

Common issues:

• Blocking issues create large backups in some parts of the process and starvation in others.
• Unchecked backlog growth over time. This results from product owners not closing issues that are obsolete or simply too low in priority to ever be pulled in.

Even more metrics

Good metrics aren't limited to the reports discussed above. For example, quality is an important metric for agile teams and there are a number of traditional metrics that can be applied to agile development:

Quality Metrics:

• How many defects are found:
  • during development?
  • after release to customers?
  • by people outside of the team?
• How many defects are deferred to a future release?
• How many customer support requests are coming in?
• What is the percentage of automated test coverage?

Delivery Metrics:

Agile teams should also look at release frequency and delivery speed. At the end of each sprint, the team should release software out to production. How often is that actually happening? Are most release builds getting shipped? In the same vein, how long does it take for the team to release an emergency fix out to production? Is release easy for the team or does it require heroics?

Finding the right balance

Metrics are just one part of building a team's culture. They give quantitative insight into the team's performance and provide measurable goals for the team. While they're important, don't get obsessed. Listening to the team's feedback during retrospectives is equally important in growing trust across the team, quality in the product, and development speed through the release process. Use both quantitative and qualitative feedback to drive change.

Using Improvement Kata

Here's a concept that changed how I think about solving problems: Improvement Kata. If you've ever studied martial arts, you know what a kata is—it's a pattern of movements you practice over and over until it becomes second nature. Improvement Kata takes that same idea and applies it to how we tackle challenges at work.

The concept comes from Toyota (yes, them again—they really figured some stuff out). Mike Rother documented it in his book , and it's basically about developing a habit of scientific thinking when you're trying to improve something.

What is Improvement Kata?

The idea is simple: instead of winging it every time you face a problem, you follow a consistent pattern. Do it enough times, and it becomes automatic—you don't even think about it anymore. The methodology uses experimentation to break down big, scary goals into smaller targets you can actually hit.

Here's the four-part pattern I use:

1. Understand the direction or challenge - Where are we trying to go? What's the big goal?
2. Grasp the current condition - Where are we actually at right now? (Be honest here)
3. Define the target destination - What's the next step? Not the final destination, just the next milestone
4. Move toward the target iteratively - Run small experiments to get there, overcome obstacles as they pop up

What I've found is that this approach is gold when you don't have a clear path forward. You know where you want to end up, but the route is fuzzy. That's when experimentation becomes your friend—each attempt teaches you something, and you adjust based on what you learn.

What are the benefits of Improvement Kata?

Today's technology landscape presents unprecedented complexity and dynamism. Improvement Kata provides a scientific, objective-driven working methodology that equips individuals and teams to address these challenges effectively. Mastering this technique yields benefits extending far beyond mere operational structure.

Teams aligned toward a single goal

Shared success definitions foster collaboration, clarity, and productivity. When team members understand their contributions to larger objectives, they develop stronger work ownership, deeper vision commitment, and more proactive decision-making oriented toward goal achievement.

Experimentation leads to results

Knowing your destination without understanding the path creates initial paralysis. Embracing regular experimentation dissolves uncertainty and propels progress. Formulate hypotheses about potential approaches, then test them. When experiments fail, course corrections come without penalty—each attempt refines your understanding of the correct direction. Experimentation fundamentally concerns learning and problem resolution.

Reduce waste significantly

Concentrating on incremental, sustainable improvements minimizes time and energy spent on non-contributory activities. When reviewing backlog tasks, ask: does this advance my next milestone and ultimate objective? Push further: given remaining time and current knowledge, can I realistically overcome blockers and complete these tasks, or should I defer them? This tactic prevents wasting days or weeks on problems requiring significant detours to resolve obstacles.

Improvement Kata reduces waste across development roles. Developers avoid building unnecessary features, focusing instead on intentional, milestone-aligned work. Managers and technical leaders practicing Improvement Kata principles actively remove impediments to immediate progress. Teams benefit holistically through enhanced communication, efficient feedback cycles, and continuous delivery.

Steps to implement Improvement Kata

Coordinating between what we think will happen to what actually happens and what is learned from the discrepancies is at the heart of Improvement Kata. While this may seem simple enough, the challenge is that not all of us are wired to think like this. Integrating Improvement Kata practices into your workflow takes consistent, mindful practice.

Find your North Star

The first step is to clearly understand the direction or challenge. This helps inform the planning and experimentation phases. If you struggle to identify what your North Star is, consider how your team might contribute to your organization's larger goals or how you can leverage your team's strengths to turn a particular vision into a reality.

Establish the current condition

Before you begin working towards your North Star, take time to document current processes and workflows, review where your team stacks up against appropriate metrics, and assess the team's existing knowledge infrastructure. Be honest about what your current condition is so that you can identify meaningful steps towards your ultimate goal.

Choose your next target

Once you have a clear understanding of current systems and processes, identify the next target condition, or where you want to be after your next iteration. The next target should be a single, tangible change that can be achieved in a matter of weeks/sprints and bring you closer to your North Star.

Conduct experiments until you reach your target

Now that you have a vision of what your next target is, form a hypothesis about how you can get there. Come up with ideas on where to start and what to try, and don't be afraid to fail!

Get to the goal the fastest way possible

Speed is necessary even if it means cutting corners and using clever hacks along the way. You'll either get confirmation early that it can be done, or you find unforeseen challenges to tackle. If it doesn't work, turn it into a learning opportunity.

Clean up the rough edges

Once you verify it works, move backwards to polish the corners you've cut, and smooth out any rough edges that need to be refined.

What are some examples of Improvement Kata?

Say you want to build a new service based on an idea, but you're not sure whether it will work. Rather than trying to get every layer perfectly worked out and incrementally expanding it until it's feature-complete, try picking a target that delivers some value and brings you closer to the system you envisioned. You'll probably have lots of unknowns, but you can learn a lot from challenges, and experiment with different ideas to find one that works. Once it does, reevaluate where you are, pick your next target, iterate, and reflect on your progress.

Another example is if you maintain an internal system that needs improvements. Pick one you are ready to tackle and brainstorm some ideas on how to solve it. Experiment with different approaches and try to complete it as fast as possible to start getting some feedback about it. Once things are good enough, move on to the next problem to solve.

What are the differences between Improvement Kata and lean?

Kata and lean are different, yet complement each other. Lean refers to processes to be implemented while kata refers to techniques to be practiced. Thus, kata became a mainstream business practice when Toyota adopted it into its lean production system. When combined into a unified approach, these concepts provide powerful results.

Both kata and lean principles focus on enabling faster progress, but slightly differ in their approaches. Kata is a set of habits that can be deployed at the individual-level and focuses on continual improvement and learning through experimentation. It is useful for tackling problems with uncertainty, while learning and developing skills to repeat the solutions faster and faster. It helps embracing the unknown, and teaches not to fear challenges and obstacles.

Lean principles help organizations and teams improve processes and workflows such that the greatest value can be extracted with minimal waste. Once a process is established, the focus is optimizing it to be as fast and efficient as possible.

How can you use Improvement Kata and lean together?

Improvement Kata are habits and techniques that teams can use to reinforce lean principles. While the two approaches focus on different things, they both came from Toyota originally, and can be used well together. For example, the lean philosophy hinges on eliminating wasteful activities so teams can extract and deliver the most value. Improvement Kata supports this goal by minimizing waste through routine experimentation. If one method does not yield expected results, then it is removed from the process.

The goal-oriented teachings of Improvement Kata encourage completing a task before moving to the next, so the process is continuously refined until it achieves intended results and thus achieves greater organizational efficiency, yet another pillar of the lean philosophy. Above all else, Improvement Kata offers tools that can be used in the present state to get to a lean future state. Breaking down larger objectives into smaller pieces means that each of those parts will be optimized for its intended purpose. Ultimately, this means that the entire system will thus be able to generate maximum value.