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.
Whoever is in charge should be in charge, free from outside meddling. Additionally, that person should have juice politically. Obviously, such delegation is risky, but project failure is always a risk regardless of how much gets delegated. If a project fails, it is better to know who is accountable than to fault a system or a committee.
2. Strong but small project offices must be provided both by the military and industry.
s/military/customer/. Agile development methodologies have a lot to say about the role of the customer, but one thing the agile literature often seems to gloss over is the importance of having good developers. You can't plug bad developers into a good methodology and expect success; put another way, you can't fix stupid.
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).
To a large extent, this reiterates rule #2. OpSec certainly plays a role in limiting the number of people involved in a project, but I think this rule anticipates Brooks's Law. The potential communication channels increase as the square of the number of people involved in a project and, as manager, it's vital to confront this reality, "in an almost vicious manner." One of the qualities about using good people is that they need to put fewer bits on those channels (i.e. a lot more goes without saying) or, if you assume that the communication rate is fixed, they can often talk about issues at a higher-level. Having a small number of good people attacks communication overhead from two fronts.
4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.
Managing change is central to innovation. If you were an aeronautical engineer in the 1940s, then you were drafting a lot of parts and components. In order to collaborate with your fellow engineers, you'd have to file your drawings. The analogue to this in the software world is the source code version control system, and the natural evolution of popular systems--from the relatively brain-dead CVS and SourceSafe, to Subversion and Perforce, to the new hotness of git, Mercurial, Bazaar, and BitKeeper--shows that software developers select on "great flexibility for making changes."
5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
XP has reports: CRC cards, project velocity measurements, release plans, iteration plans, user stories, and the corkboard on the wall. They capture important work, but minimize extraneous information and high ceremony. This cuts down on the effort expended creating yet-another-spreadsheet and focuses the team on the essence of the project.
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.
With XP and Scrum, you should periodically meet with your customer and go over the work done to-date, the work remaining, and the estimate for when the project will be complete. This is possible because you've been tracking the velocity of the project, including the error estimation rate, and you have estimates for the work remaining. If the release date is fixed, the customer must choose what ships, and what doesn't (although this doesn't absolve developers from providing sound advice).
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.
Subcontracting is less of a worry in the software development world as our project are often smaller. Still, you need to have a customer that trusts you to choose the right parts and suppliers. If there's a piece that should be written in Haskell, so be it. More generally, the conversations you have with your customer should focus more on what's required and less on how it will be developed. You must take responsibility for the how.
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.
This is a harder one to find an analogue to in the agile world. However, the intent is to discourage pathological behavior and developers are nothing if not pathological. Yes, you should unit test your code and have acceptance tests for your deliverables. However, unit testing malloc() is dumb. Your vendors and subcontractors, i.e. the technologies you're using, had better do their jobs. If they don't, fire them. Focus your OCD-addled developers on testing their own code, not on everything else around them.
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.
There's nothing more powerful than a good developer who can stand in for the customer. Strapping into your own plane for its first flight is just another [scary] way of eating your own dog food. Testing in the initial stages and testing the final product map nicely to unit tests, acceptance tests, continuous integration, and small releases.
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.
I love this. Yes, yes, agile is all about the customers not knowing what they want and helping them along the way, and not needing a big waterfall-ish spec. As I said, these rules are of a time (60 years ago) and place (building experimental aircraft for the United States military). But telling the customer upfront what you won't do, and why, is a great example of communication, feedback, respect, and courage, from an industry that's not often associated with those values. And, to a large respect, knowing the basic hard requirements upfront is as central to software development as to aeronautics, and you'd better get them down as user stories quickly.
11. Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.
This applies to all businesses. One piece of advice I've heard oft-repeated to startups is that the most important thing about customers is that they pay you money and the corollary is, if they're not paying you money, they're not a customer. If you're not getting paid, you don't have a customer, and having a customer is one of the central tenets of agile development.
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.
The customer is always available.
13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
Again, this is obviously important for OpSec, but it also reinforces the focus on having a minimum of communication overhead.
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.
Posts
