For an in dustry that prides itself on it s analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.
Imagine that you're in a subway, minding your own business, flipping through Facebook on your phone. As the bus starts lurching away from a stop, you see a figure out of your peripheral vision making its way towards the back of the bus, where you happen to be sitting. You don't make much of it until he reaches about where you're sitting, then says in a loud voice, “Excuse me, man, can I see your phone?”
Imagine that you're arriving at your desk at your office one morning, minding your own business, mentally preparing for wrestling with the codebase for the application that currently consumes your attention. In your peripheral vision, you see one of the other members of the team you lead make his way towars his desk, not far away from yours. You don't make much of it until he reaches about where you're sitting, then says in a loud voice, “Hey, I think we need to convert all of our user interface code over to Angular.”
Here are two different scenarios, which, on the surface, seem as different as the day is long. Would you believe me if I told you that in fact, the decisions reached are going to come out of exactly the same process, and that it's the same process that US Air Force fighter pilots were taught to win at air combat?
And that it's the same process that drives the heart of a truly agile process?
DADA
In the 1950s, a flight instructor for the US Air Force by the name of John Boyd took a close look at how fighter pilots act, think, and behave during a dogfight. His goal was pretty easy to understand: He wanted to see if he could figure out the relationship - the correlation, if not the actual causation - between how their actions or inactions determined the outcome of the dogfight. Put simply, he wanted to figure out why those who won, won, and why those who lost, lost. Discovering this could, quite literally, lead to the difference between life and death.
Fairly quickly into his analysis, Boyd discovered that most, if not all, decisions are broken into a four-step loop, which he called the OODA (Observe, Orient, Decide, Act) Loop. In more non-military parlance, this is often called the DADA Loop: Data-Analysis-Decision-Action. Fundamentally, they represent the same four steps: Collect data via observation of the enemy. Analyze by orienting yourself to the enemy. Make a decision. Based on that decision, take action. Data, Analysis, Decision, Action. Getting data leads to analysis; analysis leads to a decision; a decision leads to action.
Let me explain, using the subway scenario.
Data
Look for data: This individual's dress. His stance. His posture. His body language. The tone of his voice. His proximity to you. The number of additional people on the subway and their level of interest/engagement in this situation. The time of day. The proximity (or lack thereof) of law enforcement. The presence or absence of security cameras on the subway.
It may seem (particularly in the first case) that you're allowing first impressions to sway everything. Hold on. This step is about gathering data. Don't judge. Yet. That's literally the next step. Here, you're just gathering data, looking at anything and everything that might be of use in evaluating a response.
Analysis
In the subway, analyze the data: Based on what you can perceive, what are this person's intentions? Is this person asking for the phone somebody that appears to be trustworthy? What clues do you have that he'll give it back? What's the relative probability that he wants to use the handing over of the phone as a gesture implying that now he can keep it (and possibly pawn it for cash)? What's the relative probability that he wants to use the phone to call a loved one? What does his stance convey? Does it appear hostile or threatening? Does he appear aggressive? What's in the tone of his voice?
But it's not entirely about him - it's also about you. If this phone is lost, what's the cost to you? You'll be without a phone for a while, certainly, and that could be minutes (while they use it) or days (while you wait to obtain a replacement). How critical is that cost to you? Is your socioeconomic status such that purchasing a replacement will seriously hurt your budget? Could you live without it while your budget recovered enough to afford a new one? And what about the data on the phone - is it recoverable? Is it backed up into the cloud?
Most of this analysis will be made in a snap and a good chunk of it will be entirely subconscious, but that's OK. So far.
Decide
At this point, you make the decision: Ignore the request. Hand over the phone. Don't hand over the phone. Shout for help. Pull out the gun you're permitted to carry (if you have the appropriate permit) and start shooting. Even the choice to make no decision - or perhaps more accurately to do nothing - is itself a decision.
Action
This then, is the point at which you follow through on the decision.
But this isn't the end. In fact, you've only just begun.
The Loop of the OODA Loop
In a software organization, it's relatively easy to see these same four steps. In fact, it's fair to say that for almost any software project that's been run anytime in the last thirty or forty years, you can see these exact same steps: gather requirements, analyze those requirements, come up with an architecture/design, and then execute on it. Books as far back as the 1970s describe these four steps, in fact. It seems that there's nothing new here. Heavens, this was what they talked about when they talked about “waterfall” development, for pity's sake; how does this help with anything?
Recall that the original name that Boyd gave his acronym was the “OODA Loop”; although many who have since examined Boyd's analysis focused on the first word of the name (OODA), Boyd himself spent much of his time focused on the second (Loop). What Boyd discovered was that the pilot who won the dogfight was not the individual who gets through the loop the fastest (as many Air Force analysts later misunderstood), but how quickly a pilot can get through the loop and into the next one.
It's not about the speed of any one iteration, it's about the number of iterations themselves.
In the case of the guy on the subway, these iterations can happen in (literally) seconds. When the request/demand for the phone comes, you make a snap judgment based on a sub-second Data/Analysis/Decision/Action loop. But the engagement doesn't end there. The first decision might be to “ignore the request.” Then you see what happens next: Does the other individual repeat the request? Does he look around (possibly scanning for witnesses to what might come next, possibly to see if there's somebody else who'll be more sympathetic to their plea)? That, then, becomes data that feeds into the next iteration of the loop, which you can analyze even as the phone-requesting individual is considering his own next move. You can potentially get through a half-dozen loops in seconds.
In a dogfight (or some other kind of confrontational scenario), being able to move through this loop faster than your opponent leads to the ability to anticipate (based on what you can see them doing) what their response will be, and have plans in mind already for what to do in that situation. After Boyd's analysis made its way through the upper ranks, the US Air Force sought to minimize the time in the “action” portion of the loop by developing planes that could respond more quickly to the pilot's decision. This led to the development of the F-15 and F-16 fighter aircraft, two of the most successful dogfighting aircraft ever invented. But it also led to a reinvention of how the Air Force itself managed the design of new aircraft, and how the organization, as a whole, approached problems. The goal became not to race through the four steps, but to execute iteration after iteration, where the action of the previous iteration yields the data that starts the next.
This, then, starts to get to the heart of what an agile process means - it's not about the standups, or the user stories, or any of the trappings that normally go along with the phrase “agile software development.”
The Agile Loop
It's relatively easy to imagine how this process works for the Angular case: You gather data around the current user interface - its performance, its responsiveness, its bandwidth consumption, and so on. You gather data around the features being requested by users, and compare that against the features offered by Angular. You examine the ecosystem around Angular and compare it against the support you have for the current interface. You analyze that data, looking at the shortcomings and benefits of each. You look at others' analyses, such as benchmarks and articles. You make a decision, and act on that: Adopt Angular or not.
But seeing what Boyd realized about the OODA loop, you can adjust your approach. You don't need to gather all the data once - you can do just a simple pass to see what Angular supports, and based on that analysis, make a decision to toss out a quick prototype. Let's see what it can do, just the basics. Maybe a simple CRUD app. Then, after a short action cycle (say a day, or a week at most), examine the results, and use that data to make a second decision. Hmm. Angular seems to like doing things “this” way, so what happens if you try to do something that Angular doesn't really seem to support, something “out of the box” but necessary for your user interface? That's when you need another loop, one that provides more data. Let's see how Angular can talk to the rest of your system. Another cycle.
By the end of the month, you've prototyped out a half-dozen or so research spikes. This is probably enough for you to make a reasonable guess as to whether or not adopting Angular will be an organizational “win.” You didn't have to do standups or user stories, and you certainly didn't have to put unit tests in (although tests will often help give you a sense of how changes to one component will affect another). The key point to agile is that of the fast cycle - you learn a great deal from each pass through the loop, so would you rather have one-week cycles or nine-month cycles?
Summary
Without question, there are benefits to an agile approach beyond that of merely rapid iteration. But it's important to understand what agile ceremonies are important to what aspects of the process. Much of an agile process is designed to generate feedback, and now it becomes more apparent why that's important - that feedback becomes the data that you use in the next cycle of the loop.
To be sure, there will always be people who will insist that agile requires all of the basic trappings: user stories, unit tests, standups, and so on. The fact is that all of those ceremonies are just as easy to do on a nine-month cycle as they are on a one- or two-week cycle. As a matter of fact, many of those ceremonies were done as part of projects dating as far back as the late 1960s and 70s. I even interviewed for a job with Taligent (the joint Apple/IBM operating system company) in 1993 for a position as a Test Engineer, writing code specifically designed to test the operating system code. That was five years before “eXtreme Programming” (the book) shipped and four years before Erich Gamma and Kent Beck wrote “Test Infected,” the article that formalized their thoughts around unit testing.
You can use all the tools of an agile process and still not be agile. If you're not thinking about the OODA or DADA loop, you're just cargo culting.
