Lean lessons are everywhere. You just have to pay attention, be curious, and ask questions.
I have just arrived at the Nashville Opryland hotel to speak at Agile 2013, a conference with more than 1700 software developers, product developers, and program/project managers from around the world, focused on learning how to practice iterative development using the PDCA cycle. (Agile is a close cousin to Lean, having evolved from the same principles over the past two decades).
My day begins early in the gym, where I strike up a conversation with John, the fellow on the next machine. I ask John why he’s here. He tells me that he runs a neuroscience lab in Arizona, researching how to heal brain injuries. He’s attending a brain trauma conference also at the hotel. Cool, I think to myself, a real brain surgeon.
He asks what I do. While huffing and puffing on the exercise bike, I give him a one minute briefing on Lean: Deming, Toyota, healthcare, etc. I explain to him that everything we do involves learning, whether it’s building automobiles, delivering services, or executing complicated projects in conditions of uncertainty. We break large tasks down into small ones, and the PDCA cycle helps us learn with each iteration, creating a continuous measurement and feedback loop, delivering with high quality, on schedule, within budget, and aligned with customers’ expectations.
He gives me a puzzled look and asks, “Doesn’t everyone think that way?” He shares a one minute summary of the scientific method: formulate a hypothesis, understand where you are and where you want to be, discuss the situation with colleagues, do the research, then conduct the experiments. Never, he says, batch experiments. Why would you stop to recalibrate the equipment after every batch? And never mix variables, otherwise you can’t establish cause and effect relationships. Throughput, doing one thing at a time, he explains, is key to rapid results.
Easy for you to say, I reply, you’re a scientist; you naturally think this way. I then ask him if the administrators within his organization practice the scientific method and encourage experimentation. You can guess his response.
Scientists intuitively understand uncertainty, emergent learning, and the power of experimentation, when coupled with an environment that cultivates curiosity and collaboration. They work with limited resources and a need for progress toward results–conditions also found in every business setting. But in the business world, we want certainty. A C-Level executive, about to sign on the dotted line for a long-term, multi-million dollar initiative really wants certainty: time, budget, outcomes. Failure is not an option. Contrast this with my new friend John, who says he wants his staff to fail often, learn from every experience, and apply that learning in continuing experimentation toward the goal.
How, then, in the business world (also the public sector and nonprofits) do we turn large, complicated, risky projects into catalysts for learning and innovation, rather than mechanisms for the kind of risk-averse, controlling behavior that stifles it?
The moment we talk about the scientific method, insists Dan Jones, “we naturally think about the left brain, the analytical side, and that turns some people off.” But PDCA and innovation are just as much about creativity as science. A balance of both is needed to drive real innovation. Go to the gemba, observe what your customers are doing, what they really need (even if they don’t know it themselves). Gather ideas, formulate hypotheses, and start testing. Large enterprises can, indeed, learn to act like lean startups, but they must start by changing the way they approach uncertainty and risk.
The problem with mental models, said Peter Senge, is when you don’t know you have one. If a C-Level executive is really interested in creating a culture of innovation, he/she must understand that by trying to force certainty into the project approach, they are virtually guaranteeing it will fail. Leaders must create space for inspiration and innovation through careful attention to the customer, along with thoughtful and flexible planning, budgeting, governance, and portfolio management.
Of course you need a budget along with appropriate controls and governance, but you also need to allow for cycles of experimentation, keeping your options open so you can pivot when you learn something new. In the larger picture, time spent learning will speed the innovation-to-value cycle and reduce overall cost of development. This sort of thinking in only learned through practice. Helping leaders to think and lead this way is the role of a lean coach.
And don’t forget gemba and its vital role in our continuing learning. Gemba is found everywhere, with our customers and potential customers, among our team members throughout our value stream and across functions, in the virtual world (what I call virtual gemba) and even in the most unlikely places… like striking up a conversation with someone completely outside your usual circle of colleagues and friends. How often do we actually do this though? I guarantee you, you will learn!
A video of my presentation at Agile2013, Agile + Lean = Speed, Customer Satisfaction, and Disruptive Innovation” can be found here.
