Agile, lean, TQM, design thinking—there is no shortage of management methodologies promising to revolutionize the way we work and achieve results.
There is little doubt that each of these methods has contributed to improved organizational performance across many industries. But when organizations apply tools without a clear understanding of the problem they’re meant to solve or are used rigidly for their own sake, they can quickly lose their effectiveness. Dogmatic adherence to a process, rather than thoughtful adaptation, can turn what was once a powerful solution into an empty ritual. The key to lasting success isn’t in the blind use of a tool, but in critically assessing its fit within the unique context of your organization, and then shaping it to solve real challenges.
In this month’s Design Brief, we explored the state of agile—the preeminent management method in software—with deeply experienced and respected tech leaders and practitioners. In short, they have grown more than a little concerned with how it’s practiced today. Empty rituals, meaningless, arcane jargon combined with questionable applications pushed by overinvested consultants have devolved agile practices into a lifeless figment of what they were intended to be. Consequently, many in the development community have grown frustrated and disenchanted and have started a journey of experimentation and discovery in an honest attempt to find a better way. This is good. It is very good.
But the problem is not with agile per se. Remember, agile (and extreme programming) was a brilliant countermeasure to the soul-crushing and ineffective waterfall process that came before it. It is with the thoughtless and often overly dogmatic approach many take toward implementation that is the real culprit here. They approach it as either an over-air update to download into the organization, or a cult demanding an oath of lifelong allegiance. Frankly, the same can be said about methodologies previously mentioned, such as lean, TQM, design thinking, and any number of powerful new technologies. When they are pushed by people overly invested in a single set of practices, who often have little to no design, development, or manufacturing experience and have never led others in these endeavors, there is a significant risk of the method becoming both the means and the end. Perhaps worse, overly dogmatic approaches to these methodologies can actually reinforce silo walls, exacerbate differences and inhibit the enterprise-wide collaboration and communication essential to great product development.
For me, it’s all a bit like the Bruce Lee quote (perhaps borrowed from Buddhism) in the movie Enter the Dragon: Lee tells his student as he swats him on the head, “It’s like a finger pointing away to the moon. Don’t concentrate on the finger or you will miss all that heavenly glory.” Even the best teachers and teachings are but fingers pointing the way. It is the practitioner who must carve their own path.
A little less dogma and a little more thinking just might keep you from getting your ass kicked.
Please excuse me for continuing to draw from martial arts. But much of the commentary I read from zealous proponents of various methodologies these days reminds me of the pointless arguments about which martial traditions were best for defeating an opponent in hand-to-hand combat when I used to box as a kid. One would say karate, the next boxing, still another wrestling, or Muay Thai. And since wrestlers seldom fought karate practitioners, etc., the arguments were as endless as they were pointless. Then came UFC and the Gracie family, who had been practicing Vale Tudo (no holds barred) fighting in Brazil, a truly competitive test of a fighter’s skills. So, when they faced opponents whose skills were limited by their dogmatic beliefs in early UFC fights, there was no contest. Royce Gracie regularly finished off larger, stronger opponents. Where no one cared about your fighting lineage, or that you were a fifth-degree blackbelt. All that mattered was how well you could perform in the most competitive environment.
Fortunately, fighters eventually learned that they needed to be able to fight in all sorts of situations. Standing and striking, takedowns, or grappling on the ground. And they developed a set of skills and a system that were situationally flexible and a fit for their own physical and mental attributes. A slower, 250-pound fighter will need a different strategy than a superfast lightweight. The best fighters did not just copy the Gracies but learned from them. Then, they adapted what they learned and added best-fit methods from others and made it their own.
And in Industry
The first time I ran into something like this was as an engineering director at Ford. I was fresh from three years of research into Toyota’s product development system and many more years as a senior leader at a tier-one supplier. I was brimming with ideas about how to improve Ford’s performance. That’s when I first heard, “That Toyota stuff won’t work here.” I just assumed it was a version of “that’s not how we do things” or a “not invented here attitude.” But after lots of self-reflection and a few failed experiments, I understood that we would need to adapt these powerful ideas to fit this situation. That has been my approach ever since. I realized this work was not cut-and-paste or a software download. Adapting these concepts and implementing them in a truly effective way in this specific organization at this time was the real work and, interestingly, the real learning as well.
As COO at Rivian, I experienced something similar, if more nuanced. We were fortunate enough to recruit brilliant people from many different organizations, such as Apple, Tesla, Ford, Toyota, and McClaren, to name a few. And since we had very limited operating infrastructure, we had no clear or standard way of doing pretty much anything. Naturally, people began to fall back on what they used to do at their previous organizations. This created chaos. It would have been expedient to just pick one. After all, these were all successful companies. But I knew from previous experience we needed to resist this. Even though it would take longer, we had to return to first principles. To let our previous experiences inform our way forward, but to develop the Rivian way. That started with critical thinking about who we were and who we wanted to be.
Critical thinking, experimentation, and learning
An effective improvement plan starts with a “study period” to deeply understand your current situation. What is the gap between this and where you want to be? Thorough evaluation, contrasted to your vision of what’s possible. This leads to a preliminary diagnosis that must certainly come before the prescription. Then, use this knowledge to inform your initial plan. Then, by all means, look outside your organization. Read, study other organizations and methods, and reach out to teachers who you think can help. Work to fill your knowledge gaps. The knowledge and guidance you and your team will surely need on this journey.
Like our MMA competitors, don’t just copy—learn. Learn from others outside your organization, but more importantly, learn from the experiments inside your organization. What works for your team? What creates the best new value for your customers and the best possible environment for your people? In other words, what is the best-fit strategy for your organization given the challenges you face? What will produce the best possible solutions for you and your team?
One last thing: it may be obvious, but I feel obliged to point out that this is not a one-time thing. It is ongoing. You must continuously evolve and improve to stay competitive. As a wise person once said to me, “The thing about this continuous improvement stuff is that it never seems to end.” Indeed.
The wide-ranging and insightful discussions I have had with this month’s design brief contributors have been amazing. My career was spent in hardware engineering and development, so discussions with these software development experts were quite educational. I hope you enjoy their contributions as much as I did:
- Pierre Masia, PhD, former CIO for Toyota Motor Europe, explains how the Toyota Production System applies as much to software development as it does to automotive manufacturing.
- Sandrine Olivencia proposes that software companies must think beyond just the product and adopt value-stream thinking to design a complete customer experience.
- Regis Medina shares his journey from agile evangelist to emerging Lean Product and Process Development leader after growing disillusioned with agile’s limitations.
So, I guess I will wrap this piece up with another Bruce Lee quote that applies as much or more to what I teach as anyone else. A quote I have long used at the end of my talks “Adapt what is useful, reject what is useless, and add what is specifically your own.” This month’s challenge is to figure that out. To envision your own way, learn from others, and experiment with proven principles and practices, but in the end, create something that is truly your own. As my colleagues mentioned in the opening, embark on a journey of honest inquiry, experimentation, and learning.
Make it your own! And good luck!
Download the latest issue of The Design Brief
Accelerate Innovation and Optimize Product Development with LEI’s LPPD Consulting and Learning Group Collaboration”
Transform your product development process with LEI’s Lean Product and Process Development (LPPD) coaching services. Our expert coaches help you design and deliver innovative products faster, reduce costs, and optimize workflows. Join the LPPD Learning Group to collaborate with leading companies, share insights, and learn from real-world experiences. Whether you’re just starting or looking to deepen your lean capabilities, LEI is here to guide your journey towards sustainable growth and competitive advantage.
Designing the Future
An Introduction to Lean Product and Process Development.
