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…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…