What GM and Toyota can teach us
WHAT GM AND TOYOTA CAN TEACH US
The age of heroes is over. Here's how to get your organization up to speed on agile and lean processes.
BY NATE McKIE
Organizations aren't always the most flexible entities.
Over the last five years, our software development consulting firm has been using agile and lean methodologies for internal work and client projects. While the processes themselves are fairly straightforward, we found that there are significant cultural and organizational challenges that must be addressed when transitioning large corporations and government agencies from waterfall or spiral methodologies to agile and lean processes. The reason is not hard to see: A move to an agile culture, where trust, empowerment and team accountability are paramount, requires a major shift.
The issue is best illustrated through the creation of New United Motor Manufacturing Inc. (NUMMI), a joint venture in the mid-1980s between two auto industry giants: General Motors (GM) and Toyota.
Toyota agreed to show GM the way it was manufacturing quality cars that were popular with buyers. In return, GM would teach Toyota how to collaborate with U.S. workers, and specifically unions.
It actually worked: The plant began creating cars that were significantly higher in quality than what was coming out of other GM facilities, and doing so with unionized workers.
However, even though GM had learned these lessons from Toyota (and in fact witnessed results firsthand in their plants), it still took almost 30 years to implement these ideas across the corporation.
Our Own Struggle
The difficulties GM faced and the mistakes made are a cautionary tale for large organizations that want to see real change.
At my company, before we learned about agile, we were guilty of “hero-based” project success. Having a software development background, I was put in the position—even as the project manager—of making those last few late-night fixes or implementing that final screen so the software could get out the door on time.
The impetus for making the switch to agile was an integration nightmare that took a client's project four weeks past deadline. This occurred despite the team having great technical specs that told them exactly what to do. We needed more discipline and a better process to keep the last-minute surprises from hitting us so hard.
Because we are a small company, change came easily for us. All it took was a decision by upper management, buy-in from our development team and a customer who was willing to try something new. We made lots of mistakes and stumbled at first, but there were so many obvious benefits from the outset that it was worth the pain.
Once we had gotten better, we were able to expand what we had learned from one team to another throughout the company, bringing that improved process to every project we took on. Teams still messed up from time to time, but the organization had undergone a complete paradigm shift in very little time.
We have created a predictable process that puts surprises where they belong: as early as possible. Now our customers, who generally have their own in-house developers, often want us to teach them our project management techniques. You'd think that we could just have one or two of our developers show their teams how we develop software, give them a push and see great software come rolling in.
But of course it doesn't work that way. Just as in the case of Toyota and GM, many organizations aren't built for change.
A commitment to empower teams and constantly improve quality and efficiency are more than just a checklist of to-dos.
>> PMI IS LAUNCHING A NEW AGILE CERTIFICATION. LEARN MORE AT PMI.ORG/AGILE.
They require early buy-in from top to bottom and a near-religious belief in doing processes the right way regardless of the perceived cost. Note that I say “perceived”—as is true in many aspects of life, long-term gain is achieved by discipline, not by taking shortcuts.
Resistance to Change
Following are the two issues I‘ve most commonly seen working against a true quality culture in a large organization:
■ The appearance of speed is valued over accuracy. Team members who are supposed to be producing results in a typical large organization are measured primarily by how fast they can go. This is why the “stop the line” concept was heresy at GM; the very idea that any employee could halt factory floor “productivity” over a defect was laughable (even though the result was a huge pile of broken cars at the other end).
Managers and executives love to get reports that show how many tasks and milestones have been completed. This concept of “quantity over quality” is so embedded that the norm for software projects is to have two to three months of testing and bug fixes when development is over!
However, Toyota had discovered that taking more time to get it right the first time and creating a culture that did not tolerate defective products made the process more predictable and created a higher quality car.
■ Heroism is highly rewarded. Every large IT department has them: gurus, masterminds and heroes. They are the above-average developers who come in and save the day when a project is failing by cranking away in a room by themselves somewhere for hours on end. These are the employees who receive the accolades and the recognition from management and end-users. Unfortunately, this creates a culture that can never be taught to others or used to help an organization improve, and soon projects become permanently dependent on these individuals to save at-risk initiatives.
Conversely, there are no heroes in the Toyota manufacturing line. There are only trusted employees who are empowered to find the best way to do their jobs and create the least waste. Having one line worker who is much faster and more productive doesn't help the whole; it just creates bottlenecks. The right way to produce quality products is for such a person to teach everyone else, which means making every process highly visible. A hero culture motivates employees not to share and to take sole credit for success. That's a sure road to nowhere for an organization.
Slow and Steady
So what does it take to change? First of all, don't give up after the initial project, and don't expect everything to be fixed right away. It took GM 30 years; it's probably going to take your organization more than a few months.
Second, it takes commitment to quality. Don't be tempted by the short-term gains, unless your company's future is on the line. Recognize that even though it may seem painfully slow, doing it right is almost always the best way in the end. PM
Nate McKie is cofounder and CTO of Asynchrony Solutions, an IT consulting firm in St. Louis, Missouri, USA. In his role, he drives the technical aspects of the company and teaches agile techniques to clients.
RAISE YOUR VOICE No one knows project management better than you, the practitioners “in the trenches.” So PM Network launched its Voices on Project Management column. Every month, project managers will share ideas, experiences and opinions on everything from sustainability to talent management, and all points in between. If you're interested in contributing, please send your idea to [email protected].
APRIL 2011 PM NETWORK