visit
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.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.
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.