Adopting Lean Product Development of Lean Production is a commitment to turn your organization into a learning organization.
In the Harvard Business Review article, Decoding the DNA of the Toyota Production System (October, 1999), Steven Spear and H. Kent Bowen attribute western car makers' failures to replicate Toyota's successes to not misunderstanding the unspoken essence of the Toyota's nature and the TPS: Toyota is a learning organization.
The authors describe Toyota's organization and culture as a "community of scientists," from the assembly worker to the executive suite. Western manufacturers vainly attributed their inability to apply what they had learned from visits to Toyota City in Japan to cultural differences between Japanese people and western people. The root problem was indeed cultural difference, but likely not cultural differences rooted in national identity or heritage.
Martin Fowler loosely asserts that is lean is agile and vice versa. For the most part, and within the bounds of the essay, the assertion holds up. I tend to see Martin's analysis more specifically as something like, "The set of qualities that comprise Agile are also present in Lean." The inverse of the assertion, "The set of qualities that comprise Lean are also present in Agile," isn't as resonate, and possibly not very accurate - at least not from the perspective of a mainstream understanding of agile as it lives and breathes here and now.
Billy Hollis, a Microsoft community personality, recently complained that pair programming, the most visible approach to cross-training in agile software development, is an "inefficient way of mentoring." In this observation, Billy is absolutely right. Unfortunately, Billy is talking about agile from a non-practitioner's perspective of a vision of agile as it has become in the mainstream, years into the detrimental effects of the monetization of Scrum training on agile practice, culture, and lore, and the outright hostile disinformation efforts of tooling vendors that initially couldn't move fast enough to meet agile's uptake.
Pair programming isn't an effective way of mentoring, but pair programming isn't a whole mentoring practice, regardless of whether the nascent, disproportionate mid-part of the bell curve continues to assert it as such. But then, even outside of agile, and in the software world at large, meaningful mentoring is usually pretty shoddy at best, and mostly absent or just naive. Pair programming could be a component of a mentoring practice, but it's far too limited to be thought of as mentoring in its entirety, and I seriously doubt that experienced, veteran practitioners see it as such.
Scrum thought leaders have always stated that Scrum works when it's approached as an organizational transformation. And while the organizational transformation terminology is often pretentious posturing found in talk bubbles hovering above boutique consultancies, the spirit of the advice is sound. Unfortunately, it's usually this part of Agile adoption efforts that gets disposed of and disregarded first, dooming Agile efforts to the mediocrity of the mere western style process improvement efforts that Steven Spear and H. Kent Bowen called out when reflecting on the Lean Manufacturing adoption failures of the 80's and 90's.
Despite what is apparently a much better recent track record of companies in the west in adopting Lean, Toyota continues to out-perform it's western counterparts - as is evidenced quite dramatically in the effects of the global economic systems failures on car makers. A good part of its success is due to it's community of scientists organization. Toyota is a learning organization built around and to support a learning culture.
While what has become colloquial Agile asks for a few organizational tweaks - embedded customers, team rooms, adaptation, emergence, etc - it rarely goes so far as to insist that remarkable and lasting success is predicated on the forming and support of a learning culture within a learning organization.
A learning organization marches to a different drummer. It's protocols and processes are built to not only accommodate learning, but to support it and enable it.
A manager's mandate in a learning organization is to see to the advancement of the people he is responsible for. This isn't a secondary responsibility in a learning organization, it's a responsibility amongst the organizations highest priorities and imperatives.
You might imagine that the productivity and accounting models for an organization that doesn't let any opportunities for learning slip by may be quite different than your own organization's models. When every failure, accident, and oversight is dealt with as an opportunity for learning - for the betterment and advancement of a worker and the organization - our traditional western obsession with efficiency management would likely work at odds with the imperatives of continuous improvement.
Learning in a learning organization like Toyota isn't predicated on ad-hoc pauses to accommodate expressions of remorse for breaking a build. It's not a trivial commitment to workers to give them at least two weeks of company-paid training or conference attendance each year. Learning at Toyota is rigorous and scientific. And if a manager or leader can't demonstrate the proper way to perform a task to expectations, then that person would likely not be in a leadership position.
A learning organization doesn't just pause for bi-weekly retrospectives. It methodically seeks improvements. It uses scientific method to plan and execute experiments and measure outcomes. It learns from the rigor of experimentation, and it only experiments on work that has already been standardized and harnessed with standard measures.
If a worker in a learning organization has an idea about how to improve his work, his manager or leader has an obligation to teach the worker how to formulate an experiment that proves the workers ideas, capture the lessons learned, and communicate results to the rest of the organization. The manager or leader must not only know the worker's responsibilities, but also must be able to perform them so that he can guide the worker toward observable improvements that allow the worker to perform to new expectations.
I doubt that Billy Hollis had the Toyota DNA in mind when he offered his criticism of pair programming, but it's a good jumping-off point to start thinking about what it really means to have "mentoring" in software development. So far, we're failing quite dramatically in this area.
The Toyota DNA provides a basis for the establishment of not only a solid mentoring practice in software development, but if we adopt as naively into the software industry as western car manufacturers did before us, we should expect the same failures.
To Billy Hollis' astute observations about mentoring, Agile methods indeed don't necessarily provide guidance for "mentoring", but the entire foundational layer of beliefs about producing software and managing production remain seriously flawed and not just a little antiquated and culturally isolated.
There's nothing that I see in the software development industry that suggests that we're even close to realizing the potential and promise of the learning organizations in our midst. Scrum and agile aren't making the case strongly enough and these approaches aren't really coming to the table with the mature organizational disciplines that might make such change possible.
Agile can't be an answer to the mentoring problem. Agile's focus is much to limited - and necessarily and purposefully so. If we are going start the necessary changes at an organizational level that allow us to really take advantage of a culture of scientists, then we should be looking to methodologies that address organizations as a whole, and maybe even that have decades of experience behind them.
Scrum is arguably a whole-organization methodology, but it's not colloquially known or practiced that way. Lean is an organizational methodology, and if it's not introduced and practiced as such, it's prone to lackluster and possibly even detrimental results. As Martin says, you can practice Agile Development and Lean together. However, if you're committed to the Toyota-like results that come from learning organizations, you might find your best guidance from the methodology that Toyota created to shape its own success.
You can practices Lean and Agile together, and if you're a software organization, you probably should. But understand that the extent of your results will inevitably be a reflection of how far Lean has spread throughout your organization, and understand that Agile has more to say about how software is done rather than how accounting, marketing, logistics, and customer service are done.
Optimize across organizations. Do this in a whole learning organization. Situate your software effort in the midst of such an organization and culture. See the holistic system and organization that effectively addresses mentoring; uses the scientific method as a core practice; sees failure as a trigger for improvement; doesn't resort to recrimination in the face of failure but accepts readily accountability; and is driven by customer value first and foremost - no excuses or spin, and no allowance for the petty, self-interested, entitlement and bureaucracy typical of organizations that aren't yet learning organizations.
Think about what your company could do if its people were truly motivated and organized to success above and beyond the expectations of the surrounding, unprepared market. Can your company be the Toyota of it's market? What's holding you back from wholeheartedly applying what we know about systematizing an enculturating a pusuit and achievement of excellence?
