Skip to main content

Lean, Scrum, XP, Agile: What's what and how does it fit together?

A member of the Agile-Swiss  Linked in Group recently asked, "I've read about Scrum, XP, and Lean. What are the current Agile frameworks available for software development? What are the advantages and drawbacks of each of them?" Since the discussion is not world readable, I decided to republish my answer here.

A quick overview of top agile processes

The Lean and Agile approaches are far more complementary than they might seem at first glance. All of these approaches are built on principles and values which emphasize people, communications, quality and continuous improvement.

If we think of Lean as first and foremost a set of principles for thinking about producing value for customers, then these principles can be applied to many (all?) situations and are very helpful for understanding why Scrum and XP work.

If we think of Lean as a set of 'best practices,' then Lean can be quite counterproductive. Why? Best practices are only 'best' in a particular context. Lean evolved originally in a Manufacturing context and many of its practitioners are not aware of how Software Development and Manufacturing are different from each other.

XP and Scrum emphasize empowered, self-organizing teams (think special forces, not infantry) and are especially suitable for creative environments, like new product development.

Scrum is a simple framework for organizing teams to solve complex problems (e.g. creating software, changing organizations). Scrum places a strong focus on systematically identifying and eliminating impediments. Therefore Scrum is primarily a mechanism for introducing change into an organization.

XP stands for eXtreme Programming. The name comes from taking good values and practices to the extreme, to make them even better. XP is primarily known as a set of engineering practices for producing high quality software. Despite being the foundation for fast time to market with quality product, engineers have had difficulties gaining acceptance for their preferred practices, because management has difficulties understanding them.

Scrum is Lean...

with a Turbo Charger! Scrum perfectly complements a Lean strategy, provided that management 1) understands the nature of Scrum, 2) understands the context of their environment and how it is different from other environments, and 3) is truly committed to improving their organization.

Scrum enables XP Engineering Practices

Scrum delineates responsibilities clearly and enables (without explicitly requiring) XP and other practices. "If you are not doing pair programming, you're not doing XP. If your team is not allowed to do pair programming, you are not doing Scrum."-- Andreas Schliep.

My experience with Scrum is that it encourages management to do the lean thing without explicitly invoking lean principles, and Scrum enables development teams to use the best practices for their situation. Because of the rhythm of iterations, improvements in performance come quite rapidly.

Are there alternatives?

Kanban Software Development is derived from lean principles in general, and Value Stream Mapping and the Pull Principle in particular. It focuses on visualizing flow and reacting to blockages in the flow. Although some people believe Kanban is less intrusive than Scrum, it is actually a change management process. Like Scrum, it assumes that if intelligent people recognize they have problems, they will take appropriate action.

Kanban is controversial because it rejects a number of established agile practices. Kanban does not specify iterations. It does not talk about engineering practices. It it not 'in-your-face' about change nor does it explicitly delineate responsibilities. It is however compatible with frameworks that apply these practices. For instance, there is also Scrum-Ban, a fusion of Scrum and Kanban.

Despite the concerns, Kanban is the first new approach since Scrum and XP to get much mind-share in the community.

As a coach, I like to start by helping management to see the various inconvenient truths about their organization. Lean gives them the tools to understand the impact of those truths. Scrum gives them and their staff the ability to do something about it. And for teams developing software, XP is a collection of the best engineering practices available, and these are probably appropriate for your software development (and your developers should make that call!).

[Update 21-Jun-2010: thanks to Jens Meydam for his insights into XP and Kanban - I've updated the article based on his feedback on the LinkedIn discussion.]


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…