There’s A Critical Lesson Hidden in Well Known Agile History
In my career, I’ve had to teach the history of agile quite a few times. And I’ve learned how to share a bunch of different stories that are relevant and helpful for people just learning about the agile mindset. I may even start way back with Taylorism and the concept of Scientific Management. It started in the late 1800s and was focused on labor efficiencies, measuring minute changes in things like the arrangement of workers and large machinery to be more efficient as high volumes of goods were being manufactured. This is one of the historical references people learn about when they first hear about Lean processes and eliminating waste through building smarter process designs.
I’ll also tell the story about the 14 guys who were sick of the state of the industry in the late 1990s with big, long projects running late and over-budget. The guys met up at Snowbird Ski Resort in Utah in 2001 to talk about finding a better way to write software and invented the Agile Manifesto which has largely become the values and principles that we build upon to this day in all agile delivery.
Most people know something of the origins of Lean and the Manifesto. But just recently, something occurred to me. There’s a huge lesson right in one of the biggest stories we tell about how agile came to be. I’m talking about the Toyota Production System.
There are many great agile lessons to be taught while recounting parts of the Toyota story. Taiichi Ohno invented the multi-piece flow system that optimized the ability to create variations in car production (as opposed to the Henry Ford innovations that came before and produced millions of Model T’s, all black, all the same).
Ohno introduced many concepts to the world through his innovations at Toyota: Value Stream Mapping to optimize end-to-end value creation and the sequence of steps a product goes through from concept to delivery; Kaizen and Continuous Improvement with great focus on process and the flexibility to change as needed; the Kanban system itself to help visualize and optimize the flow of work, focusing on just-in-time processes, only doing so much at once, optimizing the levels of parts inventory, as well as the concept of using visual indicators to guide the flow of work and keep others informed in real-time.
My favorite story, though, is about the Andon cord. Along the production line, every single floor worker was empowered to propose a change to the process and could pull the Andon cord which would stop the entire production process. Toyota was ingenious to create a culture that allowed those closest to the work to propose changes that would make their jobs easier or save valuable time in the production of vehicles.
The Toyota culture was of course inspired by the Japanese culture itself which is why I chose The Great Wave off Kanagawa image for this post.
When the Andon cord was pulled, a manager would run out to the individual and ask how they could help. Often an employee might suggest a minor improvement, like altering a tool or rearranging the supply piles to save a small amount of time. The manager would help quickly implement a solution with the employee and then restart the line. This trust was put in every employee. The human element of the TPS cannot be underestimated.
For a tremendous read and longer telling of the story, I highly recommend the first chapter of “Lean Enterprise: How High Performance Organizations Innovate at Scale” by Jez Humble, Joanne Molesky, and Barry O'Reilly. They tell the story how a US company attempted to replicate the Toyota Production System in the NUMMI facility in Fremont, CA but failed to incorporate this human element and a culture of empowerment. Even though they replicated the factory and its production lines exactly, the NUMMI experiment failed miserably. (The entire book is excellent, btw)
Hidden in this example of the Andon Cord and this lesson of empowering teams is the thing I want to share. Do you know why Toyota was inspired to this heightened level of innovation and inspired to improve their production lines? At the time, in the 1950’s they estimated they (Japan) were about nine times behind the pace of American car manufacting. And with some very quick math, they realized there was no way they were going to catch up by creating nine times the number of manufacturing facilities and expanding linearly. They knew they needed to be more efficient with the people and resources they had.
By creating a culture and a system that was designed to continuously improve, they had crafted their best chance at increasing production, building higher quality cars, with the increased variability of options and complexity required to be competitive.
Master classes are taught on the value produced and the innovations within the Toyota Production System. But what lessons are in here for you and your team? The obvious lessons are to focus and control your work in progress limits. Toyota expected everything to change, so they didn’t build up an inventory of doors to put on cars in case they figured out a better way to build doors! They created transparency in the work with Kanban boards and Information Radiators. This enabled a new style of management and the phrase “go to the work”. The term Gemba walk means the manager physically goes to where the team works to see for themself how they’re doing (and therefore don’t need to ask for status reports anymore). And they built a culture of process improvement and a culture of trust to allow those closer to the work to implement improvements for their own good. All of these things should be an inspiration to any agile team looking for ways to improve their work.
The not so obvious point of the Toyota stories is embedded in the inspiration for why Taiichi Ohno invented the Toyota Production System in the first place. In order to deliver more value sooner, we have to be aggressively lean and efficient in our ability to think iteratively. What’s the smallest thing we can validate today? How do we know that’s the right feature to build? What can we not do and still deliver the same amount of value? What’s the least amount of work we can do to satisfy the outcomes of this user story? How do we know we built something that truly satisfied the original perceived need?
All too often, I see teams writing user stories like they are lifting lines out of a project plan spreadsheet and rearranging them in JIRA and calling it a backlog. If you want to reap the benefits of being agile, please consider changing the way you think. We are not writing requirements in user stories. We are asking questions and seeking answers to know that we are truly solving the right problems, producing the right outcomes, and taking the smallest steps possible to confirm or deny those assumptions. When you start thinking that way, you will absolutely end up being more lean and efficient. You stop building stuff that doesn’t matter and start spending your time and energy on things that absolutely do matter. Mix that with a culture of empowerment and a team that is fully on board with speaking up and challenging anything and everything about what you do that is not necessary to produce value in a meaningful way, then you have a system focused on continuous improvement and a chance at building real products that truly matter to customers.
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
