Agile is No Substitute for SDLC
Agile software development, as defined in Wikipedia, “refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams“.
Many articles, blogs, and discussions have been written over the past few years regarding the benefits of Agile development. In fact, as a management method, Agile has peaked as the latest fad to sweep software management consulting, and as a result, it has become very popular with IT/development managers. Is it just a fad? Perhaps in some ways, but its value can’t be understated when utilized for the right type of project and under the right circumstances. Specifically, Agile targets small software projects with teams of 10 or fewer, which are focused on the delivery of user interactive software. In these projects, the customer is often better able to fully envision/specify final product requirements through a small series of prototype iterations.
While the need for Agile is real and clear for this kind of development effort, I do wince every time I hear some consulting organization promote Agile as an alternative to SDLC (Software Development Lifecycle).
In fact, the Agile methodology is only applicable to a few project types and lifecycle phases (namely software design, coding, and unit test) within the overall SDLC, and finally, it is very “design/coding focused” in its aim. Agile is a concept produced by software designers/coders for software designers/coders, rebelling against strict waterfall methods that held them accountable for highly accurate requirements and design plans, in situations where iterative passes at requirements and design made much more sense. It quickly became obvious to many, that Agile was a clear improvement for a subset of smaller projects, focused on more user interactive products, and better served by an iterative process.
Agile adheres to a unique set of core principles (listed below) that define its purpose, but it’s important to understand that while those principles are a good match for some of the software development efforts described above, they’re in no way universally advantageous. I’ve provided some competing considerations for each, in an effort to underscore their limits.
| Agile Principle | Competing Considerations | |
| —————————- | ————————————————- | |
| Individuals and interactions over process & tools | Advantageous for small projects with straight forward single dimensional software deliverables. | |
| Can really get you into trouble as requirements and / or design size and complexity increases. | ||
| Working software over comprehensive documentation | This is no different from SDLC – great documentation is only a goal in as much as it drives quality in software and software related deliverables. | |
| A poor SDLC management culture can skew quality priorities to the point that it may seem as though the documentation is “the point”, but like any methodology (even Agile), it is only as good as those who use it. | ||
| When requirements come up front or result in a complex design or system of designs, then cycles of documentation and review are absolutely critical to 1. success at any level and 2. achieveing the level of quality required. | ||
| Customer collaboration over contract negotiation | An oxymoron if contracts exist at all – contracts/other agreements must allow (enforce) the Agile management dynamic in a way that doesn’t increase risk for the software producer. | |
| Potentially disastrous if they don’t and you’ve taken shortcuts in documenting requirements. | ||
| Responding to change over following a plan | Perfect where the customer priority is the quality of the outcome, especially when they aren’t clear on what that outcome should be when the process begins. | |
| A recipe for trouble when dates and quality are both important. Which is almost always the case. |
Given that Agile is limited to a subset of project types and SDLC phases, it follows that Agile cannot act as a replacement for SDLC. In fact, Agile isn’t a comprehensive project methodology at all, it is a component methodology. As a result, a large system development effort may be separated into a number of individual user focused design efforts that use Agile during development, while other design subsystems within the same project follow SDLC, even for the design, coding, and test phases.
Agile only makes sense as a component of an overarching end-to-end SDLC model despite the tendency of consulting organizations to expand the scope of Agile in an effort to extend the scope of their consulting engagements.
My purpose for writing this piece is to continue to challenge management executives to exert due diligence when it comes to the selection of contract professionals, methods, and the use of consulting organizations. Management methods and tools must be applied to the specific problem space they were designed to address, to avoid poor or even damaging outcomes.
Despite the claims made by some consulting professionals, Agile cannot replace SDLC and cannot meet full lifecycle needs. Agile may in fact be a superior process approach for the software projects you manage, but it only solves part of your project / lifecycle problem. You still need an integrated project level SDLC framework (perhaps with both agile/waterfall component development methods) to manage project initiation through planning, and post development lifecycle activities.
At PMOSoft, we provide the PM Office information and quality management systems (web applications & procedures) needed to achieve the PMO mandate in as little as 3-4 months. Please visit us at http://pmosoft.com to learn more.
