When Agile “Doesn’t Apply”

With the popularity of Agile frameworks like Scrum growing among project managers, I find myself confronted by more and more people who assert Agile is only suited for solving certain types of problems, and inappropriate for others. Like dealing with any change, we invariably see resisters move from saying something will not work at all, to couching their resistance with qualifications. While this is a good step, conditionally applying an adaptive, Agile approach is a dangerous game. The purpose of this blog is to help you identify these traps when you see them, I’d like to highlight the two most common qualifications I see.

Agile May Not Work in Very High Risk Situations

“Agile is good and can be very useful in some highly creative situations where we can afford a little failure, but in high-risk, zero-fault situations, we need the control of a traditional project regimen.”

To this day, we still see many people associate control with risk management. This seems to be predicated upon the idea that Agile may offer efficiencies, but it also introduces serious risks or ambiguity that can be better managed by a traditional waterfall project. I can understand the seduction of this line of thinking — that, in a high-stakes, complex situation, we need careful planning and forethought. This outlook mandates that we must control and measure our progress carefully along a pre-defind path if we are to ensure success.

Sadly, reality does not vindicate this perspective. Indeed, history is littered with examples where too much forethought led to a failure to assess a complex, changing situation, ending in calamitous results. As Ian Ousby succinctly described the historical assessment of the Maginot line, the “impenetrable” fortifications the French built along the German border prior to WWII, which the Germans promptly ignored by invading France through Belgium.

“Time treats few things more cruelly than the futuristic fantasies of past generations, particularly when they are actually realised in concrete and steel. Hindsight makes it abundantly clear that the Maginot Line was a foolish misdirection of energy when it was conceived, a dangerous distraction of time and money when it was built, and a pitiful irrelevance when the German invasion did come in 1940. Most glaringly, it concentrated on the Rhineland and left France’s 400-kilometer border with Belgium unfortified.” (Ousby, Occupation: The Ordeal of France, Pimlico, 1997, p. 14)

Why can’t we plan well enough to deal with situations like this? Well, first of all, there is a lot of experience showing that we’re not as good at planning as we’d like to think we are. We focus far too much on predictive planning over experimentation. A perfect example of this is encapsulated in Tom Wujec’s debrief of the Marshmallow Challenge. He measures different teams’ abilities to build a freestanding structure of spaghetti, tape, and string holding a single marshmallow. One of his big insights is that teams who spend the bulk of their time planning and designing consistently perform worse than teams who build, tinker, and experiment as they go. Humorously, the groups falling victim to the planning trap generally had MBAs, while those in the tinkering group were recent graduates of kindergarten.

Even if we can plan perfectly, the idea that we can lay out a detailed plan and manage to it fails to account for the fact that we exist in a complex system. One that is ever-changing over time and in response to our very actions. Any high-stake project like the ones we’re talking about would invariably run over a period of many months, if not years. What’s the likelihood that circumstances will not change over that period of time? If the act of doing analysis further pushes out the time for our project, doesn’t that only exacerbate the risk that the situation will change?

Several teachers laid out this challenge in an evolving set of videos known as “Did You Know?”. In it they show—quite impact-fully—just how quickly change is occurring around us. The key point I would highlight is where they show the changing rate of adoption within a market place.

Imagine for a moment that you could kick off a major new product development that was going to take two years. Your competitor who just launched could have a market of 50 million users by the time you go live. This is the other challenge of complex environments, they respond to what you are doing. Going back to the example of the Maginot line, I’m sure the German generals adapted their plans, focusing more on rapid strikes and air power, in direct response to the emerging French strategy of a fortified static line of defense. Likewise, if you pursue a long-term strategy with a carefully telegraphed goal, what’s the likelihood your competition will see and respond accordingly?

I should add one other caveat here about Agile and high-risk domains. Many people see Scrum teams that are operating in areas of relatively low risk, like some great new web start-up, and presume that those exact behaviors are what we mean when we talk about Agile. They imagine trying to develop a medical tool or avionics system by developing new requirements every two weeks and limiting written specifications—that is not my point. When I talk about an Agile project, I mean one based on the concept that we can’t predict the precise outcome, and that we are running our project in a manner to inspect and adapt based on what we learn. Such a project may have massive amounts of discipline using engineering practices like automated testing, continuous integration, and test-driven development. In fact, those practices are great for Web development too. However, a detailed project plan with precise milestones or complex designs and interdependency charts will only give us a feeling of control and most likely make us blind to any opportunities that may emerge throughout the project. Thus, in the perfect plan, the best we can hope to do is exactly what we planned, and most likely far short of that.

Agile Isn’t Necessary in Simple Situations

“Sure, I can see an Agile approach being useful when there is a lot of uncertainty and risk, but what about something that’s really straightforward and known to us? Wouldn’t it be more efficient to simply lay out a plan and follow it?”

Ralph Stacey created a matrix based on agreement and certainty to show conditional management approaches based on these two dimensions. You have probably seen this grid, simply referred to as the “Stacey chart”, used before.

The y-axis represents our level of agreement about a decision or problem to be confronted amongst the stakeholders who would work on a project. The x-axis represents our certainty around the technical details of the solution. Based on these two dimensions, you can plot what domain your project resides in: simple, complicated, complex, and anarchy. Stacey goes on to advocate that the more complex a domain in which your project resides, the more adaptive and flexible your approach must be. Here we see the exact opposite of the first qualification. My experience is that this perspective usually comes from the perceived value of efficiency and scaled operations indoctrinated into most corporate workers. We still have this mental model that we are working in a factory and if we can run things in a larger scale by doing all the requirements or the entire design at once, it will be more efficient. If we look at this chart, Stacey would agree. So, what’s the problem here?

This qualification is harder to dismiss, because it has a grain of truth. There probably are projects that are sufficiently simple that they can be done in a predictive manner with no adverse impact and minimal risk. However, there is one major risk, and once again it comes to the fallibility of our perspective. Humans love precision, in fact, we create the illusion of precision. In his book “Software Estimation: Demystifying the Black Art”, Steve McConnell shares an exercise he has run with a number of participants. In it he presents 10 questions to which people most likely don’t know the precise answer (things like the weight of a whale or the surface temperature of other celestial bodies), but that we should have some idea about. The game is very simple, the goal is to provide an upper and lower bound estimate so that you are 90% confident in each answer. Teams can provide as wide a range as they would like, the winner will be based on which team provides the most correct ranges including the correct values. Thus, in this challenge, there’s an easy way to win: simply offer incredibly wide ranges, ones so wide that you will get 9 out of 10 answers correct. However, what we see is that teams immediately impose a level of precision upon themselves that causes them to be wildly incorrect (see chart).

What McConnell finds is that when people are told to be 90% confident, they are actually only about 30% accurate. This begs the question, if something we believe is 90% correct is actually only 30% correct, what’s the likelihood that we can correctly assess the level of certainty we have in a domain? So my ultimate critique isn’t that Stacey’s concept of complexity is wrong, but rather that we will be too tempted to minimize the complexity of our project, convince ourselves they are simple, and fall into all the traps of predictive project management. The fact of the matter is that organizations need project managers to manage complex projects. If the stuff we’re doing was so simple, we wouldn’t be needed in the first place.

What to do When You Confront These Sources of Resistance?

While I have provided a very intellectualized argument here about why these two positions are untenable, I should acknowledge that these are, first and foremost, actually emotional responses. When resisting change, people frequently have an emotional concern, and then find an intellectual response to put that feeling to words. In these cases, if people don’t feel comfortable with something, there is no logical argument you can provide that’s going to dismiss it. The goods news about patterns like these is that they actually represent a retreat from a more extreme form of resistance. The person is conceding there is merit to the concept of Agile, but now they are arguing it just doesn’t apply to these circumstances. My experience is that these two resistant patterns really are related to sources of insecurity that have not been voiced.

When a project manager argues to me that Agile doesn’t work in highly complex environments, it’s usually because they see their role within a project as manager of that complexity. Thus Agile is a direct attack against their value, simply saying it can be distributed to the team and managed there. Generally, my perspective on this is that PMs are making the transition from actively managing this type of complexity to enabling, coaching, and training others to do it. The other cause I’ve seen of this concern may originate from distrust amongst team members or functional units. In which  case, they lean on detailed plans for the perceived certainty that they will not be held accountable if someone else messes up. Of course, I’ve never seen a project where someone says, “boy that was a miserable failure, but great job on the design!”

On the other end of the spectrum, I frequently see the argument of avoiding Agile in simpler domains tied to concerns about productivity and a mistaken belief that somehow the capacity of a development team is tied to the number of minutes developers spend with their fingers on the keyboard. This is an unfortunate perspective and the legacy of Fordism and scientific management, which treats a value chain as a closed system with a most efficient solution to be discovered by management and enforced upon workers. Incidentally, organizations like this also probably refer to people as “resources” and move them around from assignment to assignment in fractions.

In any of these situations, voicing the concern, acknowledging the legitimacy of people’s feelings, and talking through the source of their resistance is probably the best approach. That is an oversimplification and I could probably spend multiple blogs talking about just how to do that, but for now I guess, I just want to say that as much fun as it is to intellectualize and discuss the theory for why people’s sources of resistance are wrong, you’re probably not going to make much progress explaining to people how you think their feelings are incorrect.

Like this? You’ll love Agile Eats

Subscribe to Agile Eats
Stay on top of the latest Agile tips, trends and techniques with Agile Eats. Great for new Agilists eager to learn more about this industry! Subscribe now!