Agile Concepts Applied to the C2 Environment

Agile concepts are desperately needed to revolutionize C2 industries because the world we live in has the evil force of entropy disguised as over-regulation, over-documentation and over-complication lurking behind every corner to devour good intentions of having swift command and control.  Let’s take the C2 or Command and Control environment, or even better the C4 (Command, Control, Communications, Computers) environment.  Certainly, the military, national disaster headquarters, security agency headquarters and NASA’s classic “Houston Control” types of centers would do well to look at how the following Agile principles MUST be used to ensure continual evolution of C2 structures.

The Agile Manifesto came out in 2001 and was drafted by 17 independent software developers who came together around some common values.  These software developers said “enough is enough” and they wrote down PRECISELY what it takes to perform solid programming by putting barriers aside and they wrote and signed the Agile Manifesto.  The principles behind the Agile Manifesto are fabulous as well, which I’ll talk about in later articles.  For C2, let’s take the 4 main values of Agile and look at how they might apply to command and control centers to improve performance when entropy (disorder) is constantly waiting to attack our C4 methods.  We must not allow forces such as legislation and regulation to be entropy’s agents.  The first of the Agile values is: “Individuals and interactions over processes and tools.”  How often has access to a database, server or red tape to input data taken precedence over interactions?  I remember a time in the Air Force when we were all stuffed in a 25-square foot room and heads-down at our computers, buried in 15-20 chatrooms, scanning for the critical information.  Suddenly, a Tech Sergeant said across the room, “Hey, let’s make a chat room for THIS room!” with a huge grin about his great idea.  Chuck, a wide, Asian-American man with the type of southern accent which seems to go with a toothpick sticking out of his teeth, whether it’s there or not, stood up suddenly.  Chuck yelled across the room “We’re in the same bleep-ing room!”  It took a few seconds…but then we all laughed and realized what we had almost done!  In this instance, we had smart and intelligent people tempted to halt interactions in our work-room to decrease communication in favor of increased processes and tools—the exact opposite of Agile value #1.  Interactions with face to face, voice to voice comms are WAY more valuable than all our tools combined.  We know this when we see teenagers texting their friends at the same tables at McDonalds and we know it in our C2 centers.  But we don’t apply this knowledge.  We need to wake up and look at how we’ve succumbed to the temptation to bury ourselves in fancy devices.  Second, the Agile values state that “Working software takes precedence over comprehensive documentation.”  This is another great value for us to adopt in our massive towers of infrastructure, doctrine and policy.  Does documentation DO anything in a crisis?  If it did, we wouldn’t need all these checklists and C2 technicians and operations centers.  Documentation might be good for obtaining contracts and funding, loans and lawyers, but it’s not useful for handling crises—which is what a C2 center’s primary function is!  Third, the Agile value says “Customer collaboration over contract negotiation.”   I’ve seen some instances where Primes and Subs interfere with getting the job done in order to undercut the other and enable “supposedly” increased market…no, no!  What we need is increased communication to enable better service to the client.  In serving the client through better and better ways, BOTH the prime AND the SUB will increase their ability to solve greater client needs and move into new business areas.  But the slippery slope to focus on contracts is a classic tease.  It is only accurate information about the current C2 problems, immediate information needs, timely/accurate information that has not decayed through the “telephone” game over network to database to network that enables contractors to truly understand the workspace and meet the C4 needs swiftly.  Fourth, “Responding to change over following a plan” is an excellent Agile value.  This emphasis on responding to change is the heart of the NEED for the existence of a command center.  All these values highlight that, while C2 centers start out with the loftiest of goals, that entropy in terms of contracts, obscured information and disguised or diminished relationships degrades the very goal of effective C2 itself.

Three ways that your C2 function can implement Agile are workspace design, communication flow and communication rules.   First, remember that the workspace-office furniture environment DOES make a difference.  One time I worked in an office where everyone’s cubicle was only 4 feet tall, which meant that you could make eye contact with people all day long, plus see and hear exactly what they were doing throughout the day.  I know I couldn’t get much done.  I turned into a pain in my coworker’s side, because I bugged him all the time.  Honestly, I just wasn’t comfortable with having his desk facing mine, with about 5-6 feet between us.  I only realized a few years later that I had talked to him frequently to handle my frustration with the office set-up.  I had been too ashamed to deal with it directly.  Not a great move.  In another area of the “wide open space”, one of the men chose to put earplugs in to send the message “leave me alone.”  I wish I had tried that.  It was too easy to bother people and interfere with their work. There was no clear good or bad time.  Don’t let your office environment in your C2 center degrade your objectives.  Use an anonymous survey if you must to fix the problem.  Build both collaboration space and private space into the work environment, where people can focus.
The second thing you can do to apply Agile to the C2 environment is to establish communication rules and values throughout the organization that enable the critical information to flow as fast as possible to the right decision makers.  Map out types of information “work-flow” diagrams.  Ensure that “bosses that want to be all-knowing” are not standing in the way of “hot” information getting where it needs to go.  Run drills to ensure that you time information speed and accuracy and drive information latency and decay to zero by focusing and measuring this value.  After you have this mastered and become consistent with timing in the organization, make sure that the diagram clearly labels who the decision makers are for which types of decisions.  Create a format for communication transfer such as: information, time in, decision maker, time to decision maker and barriers to information flow.  Much of this methodology on how to communicate in various contingencies can be done via checklists.  However, checklists can turn in to that evil documentation mentioned above.  We are much better off starting from scratch, drawing out the diagrams and getting people involved.  Remember, interaction rules before documentation.
Third, remember that information is not always accurate and changes rapidly.  Waiting around for process, procedure and documentation in a C2 center is probably necessary at times, but make sure decisions are made rapidly and the paperwork follows afterward.  Here are two Apollo 13 Movie quotes that epitomize the need for quick, agile, documentation-light, information-heavy, and accurate information that gets to the decision-maker at light speed.

Gene Kranz “Let’s work the problem, people.  Let’s not make things worse by guessing” and “I don’t care what anything was designed to DO, I care about what it CAN do!”  In our C2 and C4 systems, we must constantly work to ensure the fancy and high-priced systems drive us to information successes, brilliant solutions and teams that solve problems as if someone’s life depends on it.  Most of the time, C2 centers exist for just that reason.

If you liked this and want more, look up the Agile Alliance’s 12 Principles of Agile Software development.