Agile is "The Best"!

I was asked to answer the Quora question, “Why is the Agile model the best”.

I’m not comfortable with the notion of “best”. Maybe “better”, “leading”, or “fit for purpose”. But most of this is so contextual and ephemeral, I tend to avoid the label “best”. That nit-pick aside…

Agility focuses on working in teams together with the customer to deliver high-quality working software in rapid cycles.

In another answer, the author mentioned that an agile approach works well for endeavors with “large amounts of uncertainty and ambiguity by incorporating rapid feedback loops”. I agree with him on this point. Collaborative, quality-focused, incremental delivery in rapid feedback loops allows the group to learn quickly and adapt rapidly to that learning. This is certainly helpful when you are trying to discover a niche or innovate in an existing market. It is also helpful when you are trying to figure out a solution to a specific aspect of an overall project such as which algorithm provides better results or which interface gets more positive interactions.

The same author stated that agile is not as fit for need when the efforts are clear and certain. That may be true. But, such clarity and certainty is an extremely rare situation. It is not rare that we believe the efforts are clear and certain. It is rare that such belief proves true. And when it does prove true, we are quite possibly wasting time coding it up as if it were a new and unique solution.

Let me explain a bit.

Clarity and Certainty

Let’s imagine that we are a team of integrators. Our company makes routing optimization software for companies with small fleets. These companies use our software for scheduling service appointments. Let’s also say that there are five popular service scheduling software options on the market. Our product works best when integrated with whichever service scheduling product the customer chooses. Our company charges a fee for the integration.

So our team performs “custom” integrations with these five software products over and over and over again. Every time we integrate with product A, we are essentially writing the exact same code. We’ve done it dozens of times. The same holds true for products B, C, D, and E. While the code for A differs from the code for B, the majority of it is the same and the code for every A implementation is effectively identical.

THIS is work where the efforts are clear and certain. This is also work that we don’t need to be doing. Once we know the patterns, we can automate. Rather than writing the same software over and over again - package it into an installer. Work where the effort is truly clear and certain is typically work that can be automated away.

Ambiguity

Now, along comes a new service scheduling software product - Product F. A big customer is doing a change over to product F and wants us to do the integration.

How do we approach it? We’re going to need to learn. We’re going to want to get feedback quickly as we learn. While we have a good idea of what needs to be done, there are specifics we simply don’t yet know. We have uncertainty and ambiguity. And we’ve already agreed that agile works well here.

Cost, Schedule, and Complexity

A point was made that when clarity and certainty are high, then agile actually increases cost, schedule, and complexity.

I think this statement is misleading. When, as in the example provided here, there is true clarity and certainty, then any approach that treats the work as new will cost more, increase the schedule, and increase the complexity. Agile, waterfall, or ad-hoc - if we’re not leveraging the artifacts of prior work, we’re introducing waste. If we are reinventing the same solution, we’re introducing waste.

The only case under which I’ve seen an agile approach increase cost, schedule, or complexity over other approaches is when the team is not experienced in agile approaches and is not provided training, support, or the slack to learn. This has nothing to do with agile. The same things happen when we expect a team to switch technical platforms without the proper time, space, and support.