Add to Google
Are Scrum and XP Lean? (Part 1)
Posted on October 2, 2009 by Dean Leffingwell in Lean ThinkingAs I mentioned in my last post, I’m working with a number of large-scale agile transformations, most deploying Scrum. However, while Scrum drives agility and efficiency for the software development team, Scrum (or XP) doesn’t have so much to offer to the line managers, directors and VPs engaged in managing development, project, program, and product management and all the other surrounds that are necessary in the larger enterprise. And we all know that a set of agile teams, by themselves, does not assure an agile enterprise.
To address these larger issues, I’m using the principles and tools of lean – value stream analysis, flow, pull, kaizen mind, limiting work in process, etc. – because these principles apply equally well to a program office processing incoming requirements as they do to manufacturing lines. In addressing this larger problem, you have to consider the value stream in total, from the sales office where an order originates – to the development team – to production and distribution. As you know, that can be a long and arduous process in the enterprise, resulting in unacceptably slow time to market, even if the teams themselves are agile.
So the question arises, do we have two different, complementary or even competing philosophies at work – lean for the enterprise and agile for the teams? Or is agile really a “software instance of lean”, making the philosophy of approach, and language of discussion, one harmonious construct, where agile is the lean development practice subset of an overall lean enterprise approach.
Based on my personal experiences with lean manufacturing a decade or so back, I’ve always seen agile development in lean terms, and it certainly seems to be a “lean instance” to me. Many others do to. For example, Ryan Martens recently blogged on the topic at Agile and Lean Software Development – an Oxymoron? However, some of the experts comments he received back were not so simpatico.
With respect to XP, Kent Beck commented on Ryan’s post:
“I think that Agile and Lean are strongly related, but that they are two different ideas. Lean aims to achieve efficiency through eliminating waste and respecting people. Agility is a by-product in lean as rapid cycles are required to identify and eliminate waste. Agile software development aims to meet the evolving needs of customers through the early and continuous deployment of valuable software.
The values, principles, and practices of the two approaches are different, even though complementary.”
Now personally, I’ve never considered the elimination of waste as the primary driver behind lean (I rather think of flow, pull, kaizen, reduced wip, faster cycle times – which of course tends to happen when you reduce waste!). However, in the popular book Lean Thinking: Banish Waste and Create Wealth in Your Corporation (Womack and Jones), eliminating “muda” (waste) is the primary theme, so that there can be no doubt of the objective from their expert perspective. Larman and Vodde however, disagree in noting “the pillars of lean are not tools and waste reduction”.
No matter whether elimination of waste is or isn’t the primary objective of lean, it’s clear that Kent Beck does not see XP as a subset of lean, as they have “different values, principles, and practices”. And who would argue with Kent on the philosophy and roots of XP?
As for Scrum, however, which is the primary method being use in the enterprise projects I’m involved with, its roots are quite different, as you’ll see in my next post.
Dean,
Good context on the discussion. Your ability to make these type of abstract discussion concrete us unique. I am anxious to see your proof. I think Kent’s argument says agile is the small, batch fast cycle part of lean and since agile is only at the team level the philosophies and principles can be different.
I am always too fast to describe agile in fractals; team, program, organization. (way too geeky) When I do that I am quick to state to groups that you add practices as you go up to manage the scale through more discipline. Seems to me Lean is the large scale version of many agile team practices, in addition it provides other key disciplines that work at all three dimension of scale and complexity. (size, scope and distribution)
I look forward to your dissection of the problem.
Ryan
Hi Dean,
Interesting topic and I agree. I go way back with JIT, so I think the Agile community needs to learn the long lineage and results of Lean – ie Lean goes much further back than the “Agile brand”, and has very impressive results that the business easily identifies with. I have launched a blog to address this very issue. We refer to the notion of “SDLC 3.0″. It is intended to induce the notion of post-Agilism in a way described by Gartner and their recent Hype-Cycles – namely to emerge from the trough of disillusionment, “focused experimentation and solid hard work by an increasingly diverse range of organizations leads to a true understanding of the technologies applicability, risks and benefits”. Our perspective is that Lean, like Agile and the Unified Process all come from a long lineage of patterns, and SDLC 3.0 is focused on leveraging ALL past experience in context through a system of patterns – with Lean being the centroid.
With respect to your post, I recall a post by Martin Fowler suggesting that comparing XP/Scrum to Lean kinda misses the point – they are synergetic in his view. My take is that product delivery dynamics have differing spatial and temporal contexts – receive value from differing practices at differing times and locations. Therefore, as an example, timeboxed iterations as a WIP limiting practice makes sense at one point in the product delivery value stream, but is less optimal than Digital Kanban at other points in time.
Mark
Hi Mark,
I agree on the hype cycle comments. Lean is far enough past hype to be proven, and people generally understand that 1) it is hard, and 2) you can never be too lean. Sometimes agile teams “get it” somewhat and then get sloppy about kaizen. I suspect lean organizations do to, but it’s a little more obvious since its a pillar, not just a retrospective.
I agree that it’s a continuum, especially with respect to Srum which has its roots in lean and the New, New Product Development Game. It’s both true and a convenience for us involved in big transformations. When line managers come to understand their key role in “leaning” the software enteprise, they also understand the context for scrum – and more importantly, their direct responsibility to help improve it.
In that context, they are a pig, not a chicken.
–Dean