Agile Framework Comparison: Scrum vs Kanban vs Lean vs XP

If you are new to Agile, it may hard to wrap your head around the concept. That is because Agile is just a set of abstract principles that are void of any particularities on how to turn them to life. Hence, there are all sorts of practice-oriented frameworks, the most popular among which are Scrum, Kanban, Lean, and XP.

While this is a comparison post, analyzing these frameworks is still a bit like contrasting apples with oranges, because some of these methods piggy-back on or complement one another (especially when they apply to different parts of the development lifecycle).

Scrum

Scrum could be called the framework for Agile software development. Once, I met with colleagues from a previous job and told them that we were “doing Agile” at my new job. The first thing I got asked was, “Oh, so are you doing Daily Scrum and stuff?” In many people’s view, Scrum is synonymous with Agile.

Scrum is, first and foremost, a managerial framework. It’s about things developers do when they’re not writing code. Scrum explicitly prescribes a model, according to which developers plan their work, update their plans, and analyze how things went in retrospect. The framework introduces the role of Scrum Master, a dedicated person whose task is to facilitate the process and make sure it’s being followed.

Artifacts

The main Scrum “artifacts” (information disseminators) are:

1. User Story. A small piece of functionality that the team is going to work on during a time-boxed period known as Sprint. The usual format is: As a [user role], I want [the system to do this and that], so that [such and such business value is delivered]. It must have a “Definition of Done” that will be used to determine if the story has been implemented properly.
2. Task. It can be related or unrelated to a User Story. For example, setting up a new development environment or investigating a CPU memory issue are tasks that are unrelated to User Stories.
3. Backlog. A list of User Stories and Tasks for future Sprints.
4. Sprint backlog. A list of User Stories and Tasks (aka “work items”) picked from Backlog for the current Sprint.
5. Product increment. A potentially shippable piece of functionality delivered at the end of the Sprint.
6. Extensions. Reports like Burndown Chart, Velocity, etc. used to keep track of the team’s progress.

Roles

1. Development Team. It includes developers, QA engineers, UI/UX designers, business analysts, and anyone else you need to deliver the new functionality. Scrum teams normally have three to nine members. When nine people is not enough, the team is split into two.
2. Scrum Master. They host Daily Scrum meetings, planning/grooming/retrospective meetings, and help team members solve communication issues. Scrum Master is not a team member, so they can work with several teams at once.
3. Product Owner. A stakeholders’ representative who communicates the vision (which serves as a basis for User Stories) to the Scrum team, prioritizes User Stories, and accepts/rejects them at the end of each Sprint.

Values

1. Commitment (to goals in the sprint)
2. Courage (to do what you think is right)
3. Focus (on the work items in the current sprint)
4. Openness (about any challenges you face)
5. Respect (trust that everyone is doing their best)

Kanban

The Kanban framework was invented by a Toyota engineer Taiichi Ohno. In the late 1940’s, Toyota representatives observed how supermarkets restock their good based on what’s been picked off the shelves. This lead Toyota to create a supply system where production plans would be driven by actual consumption.

One of the key ideas of Kanban is to refrain from producing surplus. Kanban achieves this by using Kanban cards and a Kanban board to visualize how resources move through the production cycle. This gives everyone involved maximum insight into the process and helps managers address surplus/shortage in real time.

The Kanban system also introduces the notion of “pull” over “push,” meaning that workers pull in work according to their capacity, as opposed to work being fed to them on a conveyor belt or in the form of a to-do list.

In software engineering, Kanban means there’s a limit on the amount of work one can have in progress at a time. In other words, there could be a cap on the number of cards the team can have inside the “In Progress” column on the Kanban Board. This is done to increase focus and decrease context switching.

Another aspect of Kanban development is that activities are always tied to customer needs and that there is ongoing communication with the customer. Nothing is produced unless it economically benefits the customer.

Principles

1. Focus – reduce multitasking
2. Decrease waste
3. Customer needs come first (i.e. their business needs – ROI)

Practices

1. Visualization
2. Limiting work in progress
3. Flow management (can be done either by managing queues or by limiting work in progress)
4. Making policies explicit
5. Using feedback loops
6. Experimental evolution

The key difference between Kanban and Scrum is that Kanban is continuous, while Scrum is iterative. Kanban is better suited for teams that have a lot of unplanned work coming up (support issues, emergency fixes, urgent feature requests) during the Sprint. This way, instead of waiting until the end of the Sprint, the team can start working on items as they appear and re-prioritize tasks on the fly.

Lean software development

To help you understand the essence of this approach, it’s best to tell you the story of its author Mary Poppendieck. In the 80’s, Mary found herself in a predicament. She was an IT manager at a large videotape plant where scheduling was done using the then-popular MRP software. The plant was in a precarious economic situation because their competitors from Japan were making higher-quality video cassettes faster and cheaper.

This had gotten Mary Poppendieck to consider adopting the “just-in-time” approach used by their competitor. Armed with a poorly-translated copy of the book written by a Toyota manager, Mary got down to work. As a result, almost immediately upon making the changes, the plant went from producing 60% of planned weekly pack-out to producing 95% of it.

The tremendous success Mary Poppendieck experienced with the plant and in her further career lead her to write Lean Software Development (co-authored with her husband, Tom Poppendieck). Because Lean borrows heavily from Kanban, you’ll see many similarities between the two approaches.

Just like Kanban, Lean strives to reduce waste and maximize value to the customer. Waste could be building the wrong feature, waiting/multitasking/switching, wasting time doing something that will never be used, or starting anew. There’s also the “pull” concept that comes from Kanban, as well as the idea that you should trust that your workers are making their best effort (i.e. have respect).

As for the differences, unlike Kanban, Lean has some prescriptions regarding engineering practices (TDD, for example). At the same time, Lean is less prescriptive on delivery time-boxes, with the team potentially being ready to deploy at any time.

Some other concepts frequently associated with Lean are the Minimal Viable Product, which is the version you release as soon as you can – often even ahead of writing any documentation – failing fast, and making binding commitments (such as main architectural decisions) as late as possible.

XP – Extreme Programming

Extreme programming started as an experiment by Kent Beck, who was working for Chrysler at the time. The idea was to take cherry-picked programming practices to the extreme and see what happens. For instance, instead of code reviews, you do pair programming, technically reviewing code non-stop. Later, as more companies began adopting this approach, certain rigid rules started to be omitted – such as daily integration tests.

Nowadays, one can see XP practices used by teams that utilize Scrum, Kanban, and other organizational Agile methodologies to squeeze the most out of the developers’ potential.

Contrary to conventional belief, XP does not simply equal pair programming. While pair programming is one the twelve practices used in XP (scroll down for the full list), it’s not the only one there is. XP offers an algorithm for process management, too.

Another thing to note is that ideally, all XP practices should be used together, or else they won’t work – because of this, critics have compared XP to “a ring of poisonous snakes” and “a house of cards,” where extracting one element renders the entire process ineffective.

The managerial aspects of XP have received some criticism from project managers. For instance, the customer being constantly present is considered a source of stress. Besides, having no requirements and designing the system on the fly may be very ineffective.

Values

XP values very much correlate to those in Scrum. See the table:

Just like Kanban and Lean, XP also sees to it that no waste is produced, focusing on writing the code you need today instead of thinking about tomorrow, next month, etc. This is called the YAGNI (You Aren’t Gonna Need It) approach. There’s also the planning game that is done together with the customer.

Practices

1. Planning game
2. Test-driven development (“write unit tests first”)
3. Pair programming
4. Whole team (customer / actual user of the program is available for feedback)
5. Continuous integration
6. Refactoring of design improvements
7. Small releases
8. Coding standards
9. Collective code ownership
10. Simple design
11. System metaphor (naming things something programmers, customers, and everyone else understands)
12. Sustainable pace (no overtime)

In conclusion

In this post, I tried to clarify the differences between the four popular Agile methods: Scrum, Kanban, Lean, and XP. Like I wrote in the beginning, it’s not always possible to pin a particular practice to just one framework, and teams often use hybrid methodologies to organize an Agile development process.

Do you use any of these frameworks in your company? How is it working out for you? We invite you to share your experience in the comments!