As readers of this blog are probably aware, I’ve been thinking a lot about Lean Thinking lately. (see Lean Thinking category on this blog).
The cause is natural: as agile moves across the chasm to the large (and really large) enterprise, which is where I spend most of my time, impediments to further enhancing productivity and delivery pace move from the team to the department level and across to other organizations such as data farm operations, IT, packaging and distribution, support and the mother ship of potential agile impediments, the Project Management Office (PMO).
Once you get past the boundary of the team’s who define, build and test the software, our agile principles and practices, from Scrum, XP and the like, along with the agile manifesto, start to lose their impact. Most of these key outside stakeholders could care less about the manifesto, empowering development teams, user stories, agile estimating, and all the other seemingly odd practices and cultures of agile development.
In other words, it’s hard to “agilify” a PMO, IT shop or data farm. While many of the principles still apply, the practices and tools, and the organizations themselves, are quite different. Moreover, they have been getting along without us just fine prior to our conversion, (after all, every larger enterprise has been, by definition, successful) and they aren’t particularly interested in our new learnings, no matter how enthusiastic we might be.
[Here’s a thought experiment: a newly-converted-to-agile dev VP/Director walks into the IT shop, (substitute data farm ops, distribution, support, etc) and says “I’m here from software development and I’m here to help you make your operations more agile”. Note: do not try this at home!]
Indeed the main reason I’m participating in the LeanSSC consortium is to participate in the development of a set of trainings, tools and practices that we can apply effectively outside of the software team to help make the entire enterprise more agile. To accomplish this, we need different forms of supra-agile thinking, along with the management training and inculcation necessary to for such a significant change program to take root in the larger enterprise.
For many reasons, which I won’t elaborate here, the answer for me to this next set of challenges comes from the history and practices of Lean Thinking. I have some personal background in lean, starting with actually running a small manufacturing enterprise with lean and theory of constraints back in the 80s, to serving as a director and advisor to a lean manufacturing software systems provider (Pelion Systems, later acquired by DemandPoint) in the early 2000s. I have always seen agile as an “instance of lean thinking for software development” and that’s why I’ve resonated so heavily with the agile movement.
For some time, I’ve been meaning to put my lean thoughts down on paper, but I’m distracted by my consulting work, book projects (Next: Agile Requirements) and life in general.
Recently, I got a note from Craig Larman, describing a new whitepaper he and Bas Vodde have published on line at www.leanprimer.com. It’s really well done and covers a lot of territory I now won’t have to write about. I recommend it highly. (And it’s free!)
In it, they describe the general background and philosophies of lean and build a big picture of lean for the reader. As you may know, I love these big placemat-sized graphics that attempt to tell a long story in executive summary/gestalt form. When I saw theirs, I thought, that’s the starting point, but of course I was compelled to try to improve it.
Here’s my attempt at the House of Lean Thinking graphic.
However, for an explanation, I refer you to the whitepaper above.
This graphic is based heavily on the Toyota Way and as such, is not software specific. I expect to blog more extensively on agile-as-an-instance-of-lean in the future, along with some derivations for “the house of lean software”, but no promises, because I never know quite what direction the enterprise agile ship will take me next.
Also, on a side note, anyone interested in Lean Software Development should familiarize themselves with the excellent works of the Poppendiecks as well.