ValueShepherd.com: Thoughts on R&D Management

 Commentary

 Home

Commentary
Skunkworks

About

Contact

R&D Archaeology: The Lockheed Skunk Works

Relief

Relief at last!

That's been my reaction to the whole agile methodology movement. For 25 years I have struggled with what one of my business school professors called "the conflict between planning and discovery". That was his phrase for the uncomfortable tension between managers who ask how much a project will cost and product developers who stoically evade the question because they just don't know the answer.

As many of us know from experience, a project team's attempt to predict cost and schedule can engulf their project, sending it into a spiral of frustrating, value-destroying confusion. I've been there, so I've welcomed the agile approach to planning, which suggests that project teams should defer not just decisions but also estimates until a time when they really know the answers.

Predictability Makes a Comeback

But, suppose there were a team of people who delivered ground-breaking products based on cutting-edge technology. Suppose they made commitments up front for the schedule, cost, and functionality on all of their projects. Suppose the technologies they used were so new that they had to design, from scratch, fundamental components of their products (like literally nuts and bolts, for example).

What if their products were startling in their performance, ready ahead of schedule, and cost less than expected?

Finally suppose they did this over, and over, and over again.

How would such an organization make you feel about giving up on committing to cost, schedule, and functionality, and adopting an agile approach instead?

I know how it makes me feel.

Like a wimp!

The team existed - it was the Lockheed Skunk Works of the 1940s, 50s, and 60s. Consider just some of its products:

• The XP-80, the U.S.'s first jet fighter, and the genesis for the Skunk Works. Kelly Johnson, founder of the group, committed to a first flight 180 days from contract signing (he recalls asking what time the clock would start - minutes counted). That seems courageous enough. But when the contract was signed there were no engineers, floor space, or equipment to build the plane, so finding a building and creating an organization had to happen within those 180 days, too. But they delivered in 143 days, not 180, and the plane was the first fighter to exceed a 500 MPH air speed. They followed up with the second version, the YP-80A, in another 132 days.
• The F-104, the U.S.'s answer to the high-flying Soviet fighter aircraft of the Korean war. The Skunk Works delivered it in a year and a day. It was the first plane to break Mach 2, and set the world altitude record in 1958. It was so versatile that later versions flew with additional components and attachments that doubled the planes' weight.
• The U-2. This time Johnson committed to building 20 airplanes with spare parts in 8 months at a fixed price ($22 million). They delivered on time, refunded $2 million to the customer, and delivered six extra airplanes.
• The SR-71. This very famous and amazing plane flew at speeds well over Mach 3, cruised at Mach 2, flew at altitudes well over 85,000 feet, and could out-maneuver any missile fired at it. It was the first plane to use stealth technology. Lockheed delivered the plane less than 2 years after contract signing [1].

Hardware is Easy, Right?

Recently I attended a web seminar conducted by a software development tools company in which they described the latest thinking on agile practices, team-building, and process. There was a type-in box for questions during the seminar, so I used it to ask how the vendor explained the disparity between the software community's preference for deferring decisions and the Skunk Works' success at making commitments up front and then meeting them.

Their answer to my question revealed thinking that is common in our industry. They responded that the Skunk Works created hardware products, and that hardware people have had many years to define standard components and interfaces, and therefore hardware product developers are better able to plan and predict than software product developers. In other words, the developers at the Skunk Works had fewer risks to cope with.

As I said above, the agile approach is a relief to me, and I like this particular vendor's products and services in many ways, so I don't mean to single them out with what I am about to say about them:

Wimps!

All of the projects I listed above included technology risks that would make even the most aggressive software person blanche:

• The XP-80 encountered and dealt with compressibility, which is the buildup of air on the leading edge of a wing moving at high speeds. The engineers expected compressibility, but no one really knew how it would affect this particular plane. On the XP-80 it caused the ailerons to buzz at Mach .8, and the team solved the problem with hydraulic dampers.
• The F-104's engine was entirely new and not available early in the project, so the team tested with one engine and then integrated the new one late in development. They also had no mach-2 wind tunnel. They solved that problem by instrumenting rockets, launching them into the air with assemblies attached that would simulate a component of the final plane, and taking their measurements.
• The U-2 was so secret that Lockheed couldn't use any of its usual facilities to test it. Yikes, no airport! So, the team created a new airbase in the desert.
• The SR-71 used titanium for many of its components. The team had to solve problems with purity, precision machining (titanium doesn't compress much, so tolerances are brutal), and testing of that material. The high operating temperature of the plane required newly invented lubricants, fuel, bushings, o-rings, plastics, wiring, and insulation. The heat buildup due to air friction fried normal wiring. The paint for the insignia was also an innovation - all other paints charred on the skin of the plane [1].

Not convinced that the Skunk Works pushed the envelope? Here's what a Soviet pilot had to say:

"Chasing the SR-71 along the Siberian Coast in a Mig-25, I could not match its speed. One flight in the Mig-25 and we had to change our engines. I could not believe that such technologies existed" [Italics added] [2].

Finally, consider that all of these planes carried people who occasionally died in crashes that were due to defects or oversights.

I can't think of analogous risks in software development, can you?

The Skunk Works responded to challenges that were just as enormous as those we have in software. Perhaps their challenges were even more daunting. They also created innovative products that required innovative, not standard, components.Yet, they succeeded at predicting cost, schedule, and features. What can we learn from the Skunk Works? How did they predictably deliver such advanced products?

The Skunk Works Process

Kelly Johnson summarized his approach to managing the Skunk Works in his famous 14 Points of Project Management. In the absence of more information, I'll use the 14 points to deduce what some of the Skunk Works practices were. Here they are, from Kelly Johnson's book Kelly: More than My Share of it All [1].

"The basic operating principles of the Skunk Works are:

1. The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
2. Strong but small project offices must be provided both by the military and industry.
3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10 percent to 25 percent compared to the so-called normal systems).
4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.
5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don't have the books ninety days late and don't surprise the customer with sudden overruns.
7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract work on the project. Commercial bid procedures are very often better than military ones.
8. The inspection system as currently used by ADP [Advanced Development Projects , AKA the Skunk Works], which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.
9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.
10. The specification applying to the hardware must be agreed to in advance of contracting. The ADP practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
11. Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.
12. There must be a mutual trust between the military project organization and the contractor, with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
13. Access by outsiders to the project and personnel must be strictly controlled by apropriate security measures.
14. Because only a few opeople will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised."

Well, the 14 points don't spell out a process, and they're more general than practices, but here's my attempt at a condensation into ideas that are closer to being practices:

• Invest in people. Hire the best people. Create clear and demanding delegation that permits failure for an individual. Require that people and teams know their role and subject matter, inspect their own work, and deliver a working product, i.e. "done" must mean done. Trust their results. This applies to project members and also the customer and subcontractors.
• Make clear agreements. As part of that, stating what you won't do is just as important as stating what you will do.
• Use small groups. If people must work in groups, make them small groups, whether on the project, at the customer, or at subcontractors.
• Facilitate change with a lightweight change control process. Don't tax changes by requiring costly approval procedures.
• Likewise, don't require project documentation that isn't absolutely necessary.
• Simplicity.
• Use intermediate milestones.
• Test early.
• Leverage expertise. Kelly Johnson consulted with each of his projects nearly every day. He spread his, and I suspect others', expertise over multiple projects.

Because the Skunk Works was a government contractor, it's safe to assume that they also practiced the following:

• Heavyweight requirements analysis and specifications.
• Contracts.

Finally, these next ideas aren't practices but they come through loud and clear in the 14 points:

• Be vigorous and rigorous. Do what works, even if it makes you seem a little mean.
• Think about the intent of a process and do just enough to meet that intent.

A Practice Map for the Skunk Works

The following practice map arranges the practices that I condensed from the 14 rules by whether they reduce the cost of change or the probability of change.

Here are some ideas I derived from the map:

• Many of the practices in the map focus on making change inexpensive. The Skunk Works was agile.
• Most of the practices focus on improving judgement of boths teams and individuals.
• Of the practices that improve judgement, three of them imply personal responsibility. Kelly Johnson, as I noted above, put faith in people but also demanded that they perform. I suspect that those who did not perform were very unwelcome at the Skunk Works, and that was probably true for customers and subcontractors as well as employees.

Those are interesting observations, but to extract the greatest lesson from the Skunk Works I think we have to guess at what motivated Kelly Johnson's choice of practices.

Fear Motivates Process, but Fear of What?

In an excellent article about customizing process, Alistair Cockburn quoted Kent Beck regarding what motivates process:

"'All methodology is based on fears,' quipped Kent Beck in a methodology discussion. Although this sentence appeared merely dismissive at first, I have found it to be largely true. Each element in the process or methodology can be considered a preventative against a bad experience some project has had." [3]

I agree, but I think there are two kinds of fear that motivate process.

Quite commonly, there's the fear that project team members will do something wrong. This fear leads to prescribing engineering practices that are heavy on inspection or that defer decisions until answers become clear. In other words, both predictive and agile practices address this fear.

But, there's another kind of fear that may be even more important to address. That is the fear that some external influence will prevent really great team members from doing a good job. Interestingly, a thoughtful manager can use both predictive and agile practices to address this fear, too.

So, what fears motivated the process at the Skunk Works? Kelly Johnson's 14 rules focus primarily on the second fear. Johnson hired the best, and then he made absolutely sure that no one, not even a high-ranking customer or company executive, would get in his employees' way. With a good work environment as a foundation, his other rules could reinforce individual and team responsibility.

I think these are the lessons of the Skunk Works:

• if your process is motivated by fear of mistakes, then your best first step is improving your hiring, training, and education. In other words, first build an organization of people who are so good that your greatest fear is that someone or something will get in their way. Then create a process.
• once you've hired strong performers, then select practices that fend off interference. Create a good work environment for developing products. The practices might be agile, or they might be predictive. Johnson required close contact with a customer representative who could make binding decisions - an agile practice that speeds problem solving. But, he also used up-front contracts and specifications, both predictive practices, to get his customers and managers to delegate to him.
• finally, select practices that facilitate good individual and team performance within a good work environment. Again, these practices might be agile or predictive. Johnson used lightweight change control, an agile practice. He also required that people meet the contract schedule, cost, and functionality - a predictive approach.

Kelly Johnson was probably the first agile methodologist. But he was also successful at exploiting predictive practices to establish the role of the Skunk Works and create a good work environment. He used them to set clear goals for his employees and to set boundaries for his customers and management. And, while he committed to his customers and his management, he demanded payment in faith for that commitment - faith that the Skunk Works, if left alone, would deliver.

 References

1. C. L. Johnson, M. Smith, Kelly: More Than My Share of it All, Smithsonian Institution Press, Washington, 1989.

2. Clarence L. “Kelly” Johnson Biography, (accessed 12 October 2002)
< http://www.wvi.com/~lelandh/kelly1.htm>

3. A. Cockburn, “Selecting a Project’s Methodology,” IEEE Software, vol. 17, no. 4, July-August 2000, pp. 64-71.

Copyright 2002, Peter Bradshaw. All rights reserved.

The right to download, store, and/or output any material on this Web site is granted for viewing use only. Material may not be reproduced in any form without the express written permission of Peter L. Bradshaw. Reproduction or editing by any means, mechanical or electronic, in whole or in part, without the express written permission of Peter L. Bradshaw is strictly prohibited.