The OG of Agile
History shows how best to manage high performing teams
The term A-players is a way to describe high performers that are smart, take action, adjust quickly, and get things done. The first A-players I saw were on a TV show back in 1983:
“If you have a problem, if no one else can help, and if you can find them, maybe you can hire… the A-Team.”
A team of renegades, on the run from the government, managed to escape the most impossible situations with crafty thinking and execution at blindly fast speeds. Nothing stopped the A-Team.
Last week I wrote about Skunk Works, a team led by Kelly Johnson, chief engineer at Lockheed. While there were no death-defying stunts or cartoonish violence involved, what Kelly’s team was able to accomplish was amazing for its ingenuity and speed.
In the course of his 50 year long career at Lockheed, his team managed to produce the most cutting edge and iconic planes ever created. This included the Electra, P-38 Lightning, Constellation, P-80 Shooting Star, F-104 Starfighter, C-130 Hercules, U-2 Dragon Lady, Jetstar, A-12 Oxcart and the SR-71 Blackbird strategic reconnaissance aircraft, which still holds the record for fastest air-breathing manned aircraft.
While recognized as a brilliant engineer, perhaps Kelly’s most impressive accomplishment was how he led his team of renegades. He had 14 principles known as “Kelly’s Rules” that defined his management practices for Skunk Works.
When you read through these, it reads like Agile. The Agile Manifesto and the twelve principles behind the manifesto seem highly aligned to Kelly’s focus on high functioning teams, strong customer partnership, and removing barriers.
Getting the right team in place was a critical element of Kelly’s success. These small, tight-knit teams collaborated freely among each other and with their military customers. Take the second and twelfth rules for example:
“Strong but small project offices must be provided
both by the military and industry.”
“There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.”
This sounds a lot like “customer collaboration over contract negotiation” where business people and developers work closely together daily on the project. The “face-to-face” and co-located teams elements of Agile was also important for Kelly to maximize effectiveness and avoid miscommunication.
One major criticism of the military and government organizations is the often excessive reporting requirements. Kelly realized this was a drag on speed as he writes:
“There must be a minimum number of reports required, but important work must be recorded thoroughly.”
In Agile, documentation and any work not actively contributing to creating working software is deprioritized. That said, the important stuff is still written down if valuable for the team.
Other rules are not directly analogous to the Agile Manifesto but reflect how many organizations have implemented Agile and Digital Transformation initiatives to be more successful. One area is that of motivation, often a huge cultural barrier slowing adoption of change, as Kelly noted:
“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.”
Not every engineer wants or is even suited to management. The only way to earn higher wages however is often to advance in the management track. Smart organizations offer career paths and pay increases that allows engineers to continue developing their expertise.
A huge barrier in most innovation initiatives is access to funding which Kelly recognized as a risk for fast product delivery:
“Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.”
Providing adequate funding that is carved out and sacrosanct, innovation teams do not have beg and borrow from the business to make big bets on bold ideas.
The other factor limiting big bets is the level of trust and agency granted to the team to swing for the fences. The very first rule states:
“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.”
Poor functioning teams are often dysfunctional because they are not given the trust, environment, and support to get the job done. This happens regularly in highly matrixed organizations without clear reporting lines or strong mandate backed by leadership. The best performing organizations grant their project teams greater latitude to make decisions.
While not explicitly stated in Agile, the idea of in person communications and self-organizing teams naturally leads to smaller teams. The concept of smaller teams was made famous by Amazon’s “two-pizza teams”, but Kelly saw the light many years before:
“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).”
I have seen teams of ten talented engineers that ran circles around slower teams of over 100 engineers. Large teams get bogged down in orchestrating and managing work over the work itself and are limited to the speed of their lesser capable team members.
As Agile approaches twenty years, it is important to recognize that many of the concepts espoused in that Snowbird conference are timeless. These are just smart ways of working and organizing teams. In many ways, Kelly Johnson was the OG of Agile.
What have been the successes you have seen in Agile adoption at your organization? Where have you struggled in your adoption of Agile?
Episode #4 — Reuben Athaide of Standard Chartered on Measuring Developer Productivity
Episode #4 Co-hosts Justin Arbuckle and Mark Birch welcome guest Reuben Athaide of Standard Chartered to discuss…
Co-hosts Justin Arbuckle and Mark Birch welcome guest Reuben Athaide of Standard Chartered to discuss measuring developer productivity.
Episode #3 — Ross Clanton of Verizon on DevOps Adoption and Challenges
Ross Clanton - Heretechs Episode#3 Episode #3 Co-hosts Justin Arbuckle and Mark Birch welcome guest Ross Clanton to…
Co-hosts Justin Arbuckle and Mark Birch welcome guest Ross Clanton formerly of Verizon and Target to discuss roadblocks and roadkill in DevOps adoption.
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.