Skunk Works Rules (Kelly Johnson's Rules) Agile Style

#	Skunk Works Rule	Agile Interpretation
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.	Control is delegated to teams. Direction is owned by business/product team leads who report at the business stream level.
2	Strong but small project offices must be provided both by the military and industry.	Leaders are strong and few.
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% to 25% compared to the so-called normal systems).	Keep teams small.
4	A very simple drawing and drawing release system with great flexibility for making changes must be provided.	A very simple process to integrate, validate and release the full deliverable must be provided.
5	There must be a minimum number of reports required, but important work must be recorded thoroughly.	Process is minimal and simple, and yet records all important work.
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 90 days late, and don't surprise the customer with sudden overruns.	Process is iterative. Achieved and validated results are systematically compared against projected iteration estimates. Consolidated project estimations are updated with learning from discrepancies observed within estimates of iterations.
7	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.	External dependencies are delegated (not remote controlled) to meet defined requirements that make sense from that external view.
8	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.	There is just one way to validate that deliverables meet their requirements. This may include multiple categories of criteria (e.g. acceptance criteria, definition of done, test suites, ...). Don't duplicate validation work.
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.	Components delegated to external parties can be finally validated within the full (functioning) deliverable.
10	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.	Validations process is communicated and accepted by all before work starts.
11	Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.	Manage budgets "outside" of teams.
12	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.	There must be mutual trust between those that say what the product does (e.g. product) and those that build it (e.g. engineering).
13	Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.	Communicate your innovation inwards, not outwards.
14	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	Reward performance, not the role.

Explanation

The table above is a short analysis of the "Skunk Works Rules". As this is about innovation, I chose to express each rule from an agile perspective.

I love the engineering of the Lockheed Skunk Works. A few years ago, I enjoyed very much listening to Ben Rich's book on the subject (Skunk Works:...), Ben Rich having been the second director of the Skunk Works, (he succeeded its founder Kelly Johnson). In this book, and in many sources, Kelly's management approach and "rules" are mentioned, but not "deconstructed". I made a note to do so, which I do today, and I share that above. Comments are welcome, I took a very direct approach here, and am happy to hear how else to look at this.

Remarks

3 - Size of team

Size of team too big when it can no longer absorb new information from individuals (e.g. learning), or when individuals no longer stay aligned with changes of direction of team.

5 - Reporting work

Too many documents kill productivity. Recording work is ideally done in something as close as possible to what is the work. Yet to be a record of work, there must be more than work, there must be a record of some context of the work. In software development, text that describes work tends to age much too quickly.

7 - Delegating towards specific requirements

How to delegate work and still be agile? How to capture just enough of the future for the teams to be independent within the right amount of dependence? (Think distributed algorithms to answer that!).

14 - About rewarding people

Long term company stability may depend on stability of certain roles and people. Sometimes you need to pay key individuals to ensure that stability.

All original content copyright James Litsios, 2019.