Kelly Johnson worked at and was one of the driving forces behind Lockheed Martin’s Skunk Works group. As part of an upcoming project management book I’ve been writing (it’s called SWARM, is meant for managers of small teams of software developers, and has a picture of bees on the cover), I’ve been reading up and thinking about the business processes which are in place at technology-but-not-software business, including the Skunk Works.
Aside from the success the team had building aircraft, I think they were rather innovative in their organizational management as well, and I was inspired to write this post when I ran into this gem - Kelly’s 14 Rules.
Reading over this list, I think that Lockheed’s Skunk Works might be the agile developers of the aerospace defense world—from 60 years ago. I’ve reproduced the list here with an identification of a modern software development rule or business practice that it corresponds to..
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.
When we bid on a project for clients we explain that they are hiring us for a purpose and because of our expertise. As a result: the more control they can give us, the better the solution that we deliver.
Strong but small project offices must be provided both by the military and industry.
We have yet to do military work, but we do send people on site, and when we can get them in a small group with the client stakeholders, a lot can happen. 1.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% to 25% compared to the so-called normal systems).
Too many cooks ruin the soup, and too many developers or managers ruin the software. A small talented team will consistently out-produce an average team many times it’s size.
A very simple drawing and drawing release system with great flexibility for making changes must be provided.
Design driven development, with rapid iteration.
There must be a minimum number of reports required, but important work must be recorded thoroughly.
Invoice based on trust, not paragraph-long line items. Comment code only when it’s crucial to a future developer trying to understand the problem.
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.
Always keep the next milestone in sight, and always review whether you’re still focusing on the larger business goal of the project. Don’t spent 40% of development time and money on a feature used by 1% of the audience.
The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
We’ve gone one step further here - and we refuse to subcontract for another vendor, or to hire a subcontractor when we’re the primary vendor (we’ve learned our lesson on both fronts). Commercial bids are almost always better than non-profit bids (including those for government or quasi-government entities)
The inspection system as currently used by 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.
We attempt to maintain a set of code quality standards and development best practices which are literally the best in the industry. We want to consistently exceed, by a large margin, any standards or policies that a client has in place.
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.
You must have a staging server that accurately represents the production server. If you don’t maintain your test suite, you cannot work with confidence as change requests come in.
The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works® 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.
Implementation doesn’t start until design is done. Design doesn’t start until a contract is signed. A contract isn’t signed until the spec is done.
Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
Work on a milestone never begins if there is a past due outstanding invoice.
There must be 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.
Communication failures kill projects. Daily scrum style meetings, or at least regular communication via an online tool is absolutely critical to project success.
Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
Honor your NDAs.
Because only a few people 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.
Hours worked, meetings held and emails sent are not metrics for success. Quality produced, milestones completed, and profit made are.
Finally, according to wikipedia, there’s an unwritten-but-sometimes-spoken 15th rule…
Starve before doing business with the damned Navy. They don’t know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy.
I’ll leave that one as an exercise for any reader who has done client work to negotiate for themselves.
