Today’s Project Management Blueprint: A Comparison of Lean, Agile, Scrum, and Kanban

Over the past three decades, Agile-inspired frameworks such as Scrum, Kanban, Extreme Programming (XP), and Lean-Agile have come to dominate software development. While they share a lineage, each offers a different approach to managing software development projects—and each has distinct advantages and limitations.

In this project management blueprint, I discuss the Lean and Agile philosophies and trace their discursive evolution and applied practice from auto-manufacturing in mid-20th-century Japan to their present-day use by software teams worldwide, followed by a close examination of Scrum and Kanban, the two most prevalent Agile-inspired frameworks in the industry today.

Lean Philosophies

The term “Lean” evolved from the Toyota Production System (TPS), a manufacturing model developed by Sakichi Toyoda, Kiichiro Toyoda, and Taiichi Ohno. The system revolutionized manufacturing from the 1950s to the 1970s by focusing on eliminating inefficiencies from the production process. Toyota identified three broad sources of inefficiency:

1. Waste: Waste (known in Japanese as muda) arises due to defects, overproduction, waiting, transport, inventories, motion, and excess processing. (Many companies now recognize unused talent as an eighth type of waste.)

2. Overburden: Overburden (muri) applies to personnel and machinery and manifests as burnout, absenteeism, or safety issues. To prevent muri, Toyota distributed production activities evenly across the assembly line.

3. Unevenness: Unevenness (mura) can result from fluctuating customer demand or variations in operator speed or product completion times. It increases the risk of overburden, creating waste. Training workers on multiple machines for increased flexibility and forecasting demand can help reduce unevenness.

To remove these impediments, Toyota established its production system on a core concept known as “just-in-time.” This approach minimizes the retention of excess stock prior to production. Instead, the company replenishes materials as products are completed in what’s known as a “pull system.”

Toyota recognized that quality control must be ingrained in the production process, requiring both automation and human intelligence—a combination called jidoka. Toyota designed machinery to stop automatically when a problem occurred. The company also empowered workers to stop production when they noticed irregularities.

TPS emphasizes the necessity of continuous improvement, on-the-ground observation, and respect for people through teamwork and collaboration. Toyota’s philosophy and practices were further popularized in the 1990 book The Machine That Changed the World by James P. Womack, Daniel T. Jones, and Daniel Roos, which cited TPS as the model for “Lean production.”

Lean Developments

Lean principles began entering software development in the 1990s. At that point, the industry was in desperate need of new approaches. A 1994 report by the Standish Group found that fewer than one in five software projects were an unqualified success. These deficiencies were partly due to traditional Waterfall methodologies, which defined requirements at the beginning of multiyear projects and resulted in late or over-budget software delivery. In some cases, the deliverables were obsolete due to market changes that had happened during a project.

Early improvements to Waterfall included rapid application development, which emerged at IBM and spread with the publication of James Martin’s 1991 book Rapid Application Development. This strategy focused on waste reduction via techniques such as rapid prototyping. Software developers also moved toward incremental development, adding features in a continual iteration of small projects. While these ways of working helped, they did not solve the core problems associated with Waterfall.

Another significant development occurred within the realm of business management. In 1996, authors James P. Womack and Daniel T. Jones followed up on The Machine That Changed the World with Lean Thinking. The book outlined the principles of Lean management, distilling the core Lean values of continuous improvement and respect for people into five prescriptive principles that could be used to eliminate waste and improve continuously. These ideas would inform the development of Lean-Agile methodologies in the decades to come.

Meanwhile, software developers began to independently develop new Lean-inspired methodologies and frameworks, including Scrum, XP, Crystal, and Adaptive Software Development. These often originated from in-house efforts to improve efficiency, but developers had also begun to share their ideas through publications and presentations.

Agile Approaches

In February 2001, a group of software industry leaders met in Snowbird, Utah, to devise a solution for efficiency problems in software development. The attendees included several people already credited with launching Lean-inspired methodologies, including Jim Highsmith (Adaptive Software Development); Jeff Sutherland, Ken Schwaber, and Mike Beedle (Scrum); Kent Beck, Ron Jeffries, and Ward Cunningham (XP); and Alistair Cockburn (Crystal).

The meeting resulted in the Manifesto for Agile Software Development (often called the Agile Manifesto), in which the attendees laid out 12 Lean-inspired principles for software development. The principles emphasized the importance of adapting to changing requirements and customer needs, minimizing waste, and delivering working software faster using an incremental approach. The core values of the Agile Manifesto are widely known today but worth reiterating. These values prioritize:

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

In 2002, Jim Highsmith expounded on Agile principles in Agile Software Development Ecosystems. The book described the earlier Lean-inspired methods like Scrum and XP as techniques for achieving Agile software development.

In the years following the Agile Manifesto, additional frameworks and methodologies emerged, putting the philosophy’s values and principles into practice. Mary and Tom Poppendieck published Lean Software Development: An Agile Toolkit in 2003. Their approach uses the seven forms of waste in Lean manufacturing as a jumping-off point for Agile software development. In 2010, David J. Anderson, a software engineer at Microsoft, formally outlined Kanban, another Lean-inspired methodology, in his book Kanban: Successful Evolutionary Change for Your Technology Business.

Today, the two most prominent Agile-enabled frameworks are Scrum and Kanban. I discuss these two frameworks in the following sections, showing the similarities and differences between them.

Scrum

Scrum has proven to be the most popular Agile-enabled framework, used by 87% of respondents, according to the 2022 State of Agile Report. (Many participants used more than one framework or methodology.) The term “scrum” originates in rugby, where it describes a tight formation of players around the ball. It was introduced in a manufacturing context by Hirotaka Takeuchi and Ikujiro Nonaka in a 1986 Harvard Business Review article. They used the term to describe the teamwork required to move a project “downfield.”

Scrum entered the software industry in 1993 when Jeff Sutherland began implementing Scrum processes with colleagues at the Easel Corporation. Two years later, Sutherland and Ken Schwaber presented a paper on the Scrum development process at a software industry conference. Schwaber then worked with Mike Beedle to detail the method in their 2002 book Agile Software Development with Scrum. In that same year, the Scrum Alliance was formed by Schwaber, along with Mike Cohn and Esther Derby; since then, it has grown to become the world’s largest Agile and Scrum certification and professional networking organization.

Scrum Overview

Scrum is an incremental and iterative framework for software development. Its principles and practices help teams work in short cycles, enabling rapid response to feedback and changing needs. The framework is prescriptive, with clearly defined team structures, workflows, events, and terms.

Scrum involves self-organizing, self-managing groups of usually five to seven team members. One member is known as the Scrum master: This servant-leader facilitates collaboration and enforces Scrum processes, but is not responsible for assigning tasks or product delivery. Another member, the product owner, defines the vision for the team, engages with other stakeholders, and ultimately accepts or rejects the team’s work. Teams are cross-functional; members work together and are not bound to distinct roles like architect, programmer, designer, or tester.

Work occurs in short, time-boxed iterations called sprints, typically one to four weeks in duration. The sprint focuses on work items from a prioritized “product backlog” established before the sprint begins. The team aims to deliver working software at the end of each sprint, enabling rapid feedback cycles.

Scrum Process

Before a sprint can begin, the product owner creates a product backlog. The backlog usually starts with development items called “user stories.” The stories define product features from an end-user perspective. Research and prototyping tasks are called “spikes” and are sometimes required before the team can begin a story. The product owner arranges the backlogged work in priority order.

Once a product backlog is created and prioritized, the ongoing backlog refinement process takes over. The Scrum team reviews a list of stories and other tasks. They meet with the product owner and Scrum master and discuss “acceptance criteria” for each story (i.e., the testable requirements specified by the product owner). They also evaluate complexity, risk, size, implementation strategy, and other factors. Once the participants establish a common understanding of each story, they estimate the effort required to complete the task by comparing it to a previous, well-understood piece of work and assigning size-based values called “story points.”

To officially launch the sprint, the Scrum master facilitates a sprint planning meeting with the Scrum team and the product owner. The team determines its sprint capacity, which is the number of story points it can handle based on the available time and resources. The product owner presents items from the product backlog, and the team discusses each story and breaks down the subtasks required for the story to fulfill the “definition of done” (DoD). They continue pulling stories from the backlog until reaching the sprint capacity. The stories are arranged on a table-style display called a Scrum board, where the team will track progress during the sprint. After reviewing the sprint scope, the Scrum team (but not the Scrum master or product owner) commits to completing the work (i.e., the “sprint backlog”), and the sprint commences.

At the beginning of each day during the sprint, the Scrum master facilitates a brief, 15-minute meeting with the Scrum team and product owner to plan and review progress. This short meeting is known as the “daily scrum.” Each person briefly reports on work done the day before, the work planned for the current day, and any impediments. When a team member identifies an obstacle, the Scrum master adds the item to an “impediments backlog,” providing visibility for the team. The Scrum master is responsible for addressing issues on the impediments backlog.

In addition to maintaining the Scrum board, the Scrum master monitors progress with a burndown chart. The chart shows the amount of work completed, measured in story points. The remaining story points are shown on the Y axis, and the remaining time is shown on the X axis. The Scrum master updates the sprint burndown chart as the team completes stories.

At the end of the sprint, the Scrum master facilitates a sprint demo meeting at which the team presents each completed story using the working software. The product owner will approve the story if all the acceptance criteria are met. If a story is rejected, the product owner identifies the shortfalls, and the story returns to the product backlog in its priority order. Often, the rejected portion of a story is converted into a separate story, and the original is closed.

After the sprint demo, the Scrum master facilitates a final meeting known as the sprint retrospective. The team reflects on the sprint and evaluates what went well and what did not. This process generates a list of improvement action items, which may be added to the product backlog or cause changes to the team charter.

Advantages and Disadvantages of Scrum

Because Scrum teams prioritize backlog items and work in short iterations that always produce working software, Scrum allows customers to determine what they like (and don’t like) and request changes during product development. The overhead costs for process and management are lower, leading to quicker, cheaper results.

However, Scrum is not the best project management process in some situations. Organizations should understand issues that can arise from this framework:

• Transparency: Scrum increases transparency and accountability. Although transparency is advantageous, it can be uncomfortable when problems and poor performance are exposed, leading to resistance if not appropriately handled within the Scrum framework of continuous improvement.
• Team experience and commitment: Inexperienced or uncommitted Scrum teams or Scrum masters can cause serious problems by misapplying the Scrum framework. Because team members do not have defined roles, all members must possess relevant technical experience. Scrum also benefits from commitment coming from other parts of the organization.
• Scope creep: One of the main advantages of Scrum is that teams and stakeholders can adjust priorities and scope along the way, but this can also be a disadvantage if discipline isn’t used. Scope creep is a special concern for projects without a defined end date, as stakeholders may continue adding work items.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum prioritizes developing working software over documentation, the product owner must clearly communicate criteria and expectations.
• Scaling: Scrum functions best with smaller teams. Large teams require a different approach.

Scrum is an excellent framework for projects with requirements that are uncertain or expected to change. It is best-suited for experienced, motivated teams, as it empowers them to organize their work and evaluate progress and problems. Scrum teams often improve and become more productive over time.

Kanban

Kanban is an Agile management process that focuses on visualization, workflow, and limiting work in progress. The concept emerged directly from the TPS, in which the term kanban (or “signboard”) refers to tags on products and materials. When a Toyota worker removes the kanban and sends it down the production line, a new order is initiated.

Software developers began to adopt Kanban following David J. Anderson’s 2010 book Kanban: Successful Evolutionary Change for Your Technology Business, which outlined techniques used at Microsoft. In recent years, its use has expanded rapidly. The 2022 State of Agile Report found that 56% of Agile teams use Kanban, making it the second-most popular methodology following Scrum.

Kanban Process

In software development, Kanban resembles a lightweight and less regimented version of Scrum. The team uses a Kanban board to visualize work in progress. The board is similar to a Scrum board, but the workflow doesn’t advance in time-boxed sprints. Instead, Kanban allows for a continual flow of work but limits how many items occupy each status at one time based on team capacity. The team cannot pull new work until existing work advances.

Because Kanban teams are not required to work in sprints, the teams do not follow a prescribed course of meetings for planning, product demonstrations, retrospectives, and so forth. Continuous improvement is accomplished by tracking and analyzing the flow of items and making incremental improvements as issues are uncovered.

Kanban doesn’t prescribe specific roles for team members, although a project manager often facilitates activities and ensures that work items are prioritized and clearly understood. A single Kanban board can even be shared across teams.

This table is an overview comparison of Kanban and Scrum:

Overall, Kanban is a highly adaptable methodology that is well-suited for teams making incremental improvements to a product. It requires less training than Scrum and is more flexible. Kanban can be combined with other frameworks and can even be implemented at enterprise scale.

Beyond the Blueprint

According to the Standish Group, projects that implement Agile frameworks and methodologies are approximately four times more likely to succeed than those using more traditional methods. The most popular Agile-inspired project-managed blueprints used for software development have their historical roots in Lean manufacturing and TPS and have transformed the software industry over the past three decades.

A good understanding of Lean, Agile, Scrum, and Kanban is fundamental to the field of project management and having them all explained in one place enables further continuous improvement and growth as teams and companies scale using Waterfall, DAD, SAFe, and other hybrid approaches.

This article has recently undergone a comprehensive update to incorporate the latest and most accurate information. Comments below may predate these changes.