In my last post, I described some work I’ve been doing with lean thinking in some larger software enterprises – not so much for teams themselves, who generally find Scrum and/with/or XP to be adequate for their needs – but to other levels in the organization – project office, sales, marketing and distribution – where value stream analysis, reduction of waste and elimination of delays in time to market resonate better than the agile manifesto or the methods themselves. In addition, lean provides a broader set of both philosophies and practical tools to apply in making their departments and organizations more agile.
In that post, I noted that a bigger question naturally 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. “
XP and Lean?
I also quoted Kent Beck in noting that:
“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.”
With XP, the linkage is indirect – well correlated and complementary for certain- but it’s clear that Kent doesn’t see XP as being derived from, or based on, lean.
What About Scrum?
A few years back, I came across a presentation that Jeff Sutherland on the The Roots of Scrum. Jeff also pointed me to a video of his actual, physical presentation, which can be found on InfoQ.
In this presentation, Jeff notes that there are many roots of Scrum, including such things as the advent of OO methods (rapid development and less painful refactoring), process and productivity research (empirical methods work best when process is to complex to be predicted), and even evolutionary biology and complex adaptive systems(central command and control will kill it!), but right at the top of the list are some of the philosophies concurrent with, but not the same as, the development of lean.
Jeff notes that the “Godfathers of Scrum” are Takeuchi and Nonaka (authors of The New, New Product Development Game. This is my personal favorite, root philosophy, of all things agile and includes the first use of the words “Scrum”, “Rugby” and “Sashimi” in a software context that I am aware of (also see my earlier post). Takeuchi and Nonaka are also the authors of The Knowledge Creating Company and Hitotsubashi on Knowledge Management.
Just a few excerpts from these works:
From the New, New, Product Development Game:
“leading companies show six characteristics in managing their new product development process:
1. Built-in instability.
2. Self-organizing project teams
3. Overlapping development phases.
4. Multi-learning.
5. Subtle control.
6. Organizational transfer of learning. “
From Jeff’s presentation and Hitotsubashi on Knowledge Management:
Ba- the Zen of Scrum (shared “context in motion” and the energy that drives a self-organizing team):
- “Dynamic interaction of individuals and organization creates synthesis in the form of a self-organizing team
- The fuel of ba is its self-organizing nature a shared context in which individuals can interact
- Team members create new points of view and resolve contradictions
through dialogue
- New knowledge as a stream of meaning emerges
- This emergent knowledge codifies into working software
- Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively
- Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment
- Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development
- Time pressures will drive extreme use of simultaneous engineering
- Equal access to information at all levels is critical.”
Does this look like the good Scrum teams you know?
Of course, this background describes the roots of Scrum from certain philosophies, practices and authors perspectives contemporaneous with development of lean thinking and concurrent development, but does not specifically place lean in the roots of Scrum.
Additional Background
In my lean research, I’ve been going back to some of the earlier and quintessentially lean works, including: Lean Thinking from Womack and Jones, The Toyota Way by Jeffrey Liker, Lean Software Strategies by Peter Middleton and James Sutton (both founding members of Lean Software and Systems Consortium), to better understand both lean, and its application in the software development context.
In this review, I’ve been struck again and again by common principles – not just like principles or complementary principles – but virtually identical, fundamental, and immutable principles that provide the cornerstone values and philosophies of both lean and agile approaches. I’ve become more and more convinced that agile is a software instance of lean– purpose built for the unique challenges, intangibles and thought-based work of developing software as fast as efficiently as possible – but as lean as lean can be in that context.
Next Post
With respect to Scrum, in particular, the similarity is just too hard to ignore. I’ll describe that in my next post Scrum in the House of Lean?
Scaling Software Agility 