This is an old one (rooted in the 40ies) Kelly’s 14 Rules

Well in a nutshell, there are The Agilists (and as they are very smart people they already noticed themselves)

Anyway, I came across these rules by some pointless surfing and was struck by the resemblance and the difference to what I know about Agile. So I began dissecting them in my mind and to help myself putting some order into it - and to share it with you - I am writing something down

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.

I participated in a projevt manager training long time ago. The beginning was to define what a project and a project manager actually is. The trainer did this in a Q&A style: he asked a question and wanted us to answer. The pattern was simple: All questions were supposed to be answered with “Yes” - In case of a “No” the reply was invaribly: “Then this isn’t a project” or “then you aren’t a project manager”. I took mental notes and knew after 30′ minutes (of a full week’s training) that I won’t ever be a project manager in my organization and that I’ll learn here for my next job and for managing my manager. Later my organization - in a reckless attempt to create more positions for middle managers introduced a matrix organization. This turned out to be very effective: I had been asked to join another division and the middle managers haggled 6 weeks if I can go and under which conditions. As they couldn’t agree, I had to stay. Not for long, I quit the other month.

2. Strong but small project offices must be provided both by the military and industry.

Most of us might not work for the military, but you need as well a clear and efficient chain of command on your customer side. Time wasted hurts at any stage of a project and you can be well organized - it won’t help you much when your customer isn’t. Such projects are doomed to fail and imply a high risk for you.

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).

It is gospel that smaller teams are more efficient than bigger teams, but as well try to keep the perimeter close! The more people are brought in the more endless (and numerous) the meetings. The art is to find the optimal x for getting 100-x% of the relevant input where the effort approches infinity when x goes to 0.

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

This is a no-brainer: automated builds, unit tests, automated deployments - computers are cheap and the effort of setting this all up pays back the longer the project goes on. In other words: Saving on this is planning for failure. Note that the “drawing” in software is in many cases the product already. Refactoring must be the norm of implementing a new requirement. It is not tolerable to declare a module as frozen, if so you failed already on rule 3.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

Almost a corollary to rule 1; if you report to someone high enough in the hierarchy, lengthy reports won’t be read anyway. Pathological reporting would be excessive reporting to hide critical information- for you to decide. The lower in the hierarchy your reports aim, the higher the likelyhood that you’ll hit some half-bred expert (see 14) that will require a process review because some module has only a test-coverage of 70% when your average is 80%. The impact of good management can be exaggerated ($50M bonus), but the harm from bad can’t. Or as my physics teacher put it: You can’t accelerate a car by wildly turning on the steering wheel, but you can crash it that way.

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.

Track your progress. This is perhaps the only documentation you’ll ever need during the project. The surest way to annoy your boss and your customers is to delay reporting overruns in time and or budget. They have to take this as evidence that you can’t be trusted and need “tighter” management - there go rule 1 and 5 for you (and some other will domino in turn).

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.

Another refinement to rule 1, but the details count: You have a small team which naturally will feature some idiosyncrasies - do not neglect them. Choosing the “Best Webserver Ever” won’t help you if no one in your team is an expert with it - if the sales-guy is a good buddy of yours, it isn’t that helpful neither. I am not sure how military bidding procedures work in US - I only encountered one from the Bundeswehr and our boss decided to skip on that bidding - the effort was ridiculous. Luckily in software finding a vendor is much easier than in industry: How can you stand for their manfuacturing quality of the piece designed by you? On the contrary support is as well an issue for software and off-the-shelf hardware(There is a reason why some people still buy IBM)

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.

Follow best practices, stick with them, refine them. When testing, design your tests  intelligently, it is very easy to test over and over the same thing. If you can afford it, don’t try to chase standards like CMMi for the sake of getting an accreditation, this will help the next project, but might end yours

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.

Thanks to Waterfall the customer could lay back after signing the contract and wake up his legal departement after the product shipped. I once developped a module “in the dark” and even debugging was “offline” (the error messages by FAX!).  This isn’t so anymore (hopefully -  beware of the exceptions from the rule). Rephrased in Agile this means that you have actual users in your project team. It is more than the immediate, qualified feedback, you also learn about them and their culture and this will speed up your design.

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.

Make it right, then make it fast … but how fast? In software performance is often tuted as a non-functional requirement - in some organizations like consultancies this is as well understood as “non-critical” requirement. Your customer might tell you otherwise - time is money. We had once a requirement that a “basic contract” can be entered and calculated in 45” - they really employed stop-watches during the acceptance test. Today proper data-management (encrypting personal data and credit card numbers) is as well important - be clear there what and how you do it (and make sure that the log-files won’t spew out the login to the DB).

11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.

Money makes the world go around. Strictly speaking No Money doesn’t imply Full Stop, but it comes pretty close. No one wants to put resources where the financials are uncertain (unless very desperate) so you’ll loose at least time if not even your (carefully selected - see 3.) team. If the financial side is not stable, don’t waste your time. You’ll add a failed project to your track record, no one asks later why it actually failed. In these times apply this as well to the funding from within your organization; as you’ll represent the project, you’ll be asked these questions from the customers, contractors and vendors

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.

A corollary to 1 and 5? No, this is the precondition. Normally trust is something earned, but all sides have to give the other some credit to get started. You only think that you can do without cooperation. As soon you hit the first wall, you’ll discover the contrary - or that nobody gives a damn (e.g. the project had been canned already and nobody bothered to tell you).

13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

When I write now that this is for a good reason one of my favorites, some people will snap on me because they know why. Well, even if not working in a military project, keep a low profile. It is not uncommon to work with contractors and after a couple of years you have met a lot of people and some became a friend. Chances are that many of them work often in the same domain and you keep the contact for professional or social reasons. Make very clear that even among contractors there is an “in” and and “out”. Trust me, projects can fail because of indiscretion.

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.

As many of the rules are today more or less understood, this one still has a hard time. Many organizations don’t have any “career-path” for engineers. There might be something like “team-leader” (you have to sign the absence forms) or some so-to-say promotion to “architect”, but all this doesn’t count much outside your organization. The real problem is that unless you are happy with your job or a contractor, engineering is a dead-end or in the best case a golden cage. You might get some decent pay because you are highly valued, but by job description you’ll have to start from zero at a new job. A bit dangerous in times of big lay-offs.

The common alternative is to introduce middle management. The sink of Peter’s Principle: The best engineers will be put into well labeled positions where their skills start to perish away.

Sofar Kelly’s 14 rules, while googling I found a specialization of 12:
15. Never deal with the Navy.

Some customers are incurable resistent to facts. Even if prestiguous - they will turn out to become a net loss. As most of these class are rather big, do your best of talking your sales people out of tricking them. Will - fire -back. Good indicators for Navy-class customers are:

• Some more fitting competitors already dropped out
• The RFE goes into ridiculous details (”indentation style of scripts”)
• “Challenging” roadmap
• Mails inquiring details from you contain more recipients from their side than from yours (cc doesn’t count here, but you might want to put a question mark on rule 2)

Conclusion

After writing all this I find that rules 1, 3, 5 and 9 are the most important ones - just  like with Beethoven’s symphonies