Agile has assumed the #1 spot on my 2019 list of misunderstood project / development life cycle (DLC) terms*. It’s regularly bantered about as a panacea for numerous project ailments: Spending too much money? Why, that’s because you’re running Waterfall–you need agile! Scope creep? Agile will fix that! Feeling tired? Listless? Rundown? Agile! (okay, maybe not; you want a good dose of Dodd’s Liver Pills for this).
Sure, applying agile may reduce cost and does, in fact, embrace scope change. But, is agile the best approach for what you are trying to accomplish? Perhaps and iterative or incremental approach might achieve better results.
Here is breakdown of the four main DLCs that may be useful when choosing the best approach for your situation:
Predictive (a.k.a. Waterfall)
A predictive approach is a good choice when you have experience: You’ve done this before; you know what’s required to do it again; and the scope is unlikely to change. It’s great if you want to build a bridge because you know the tensile strength of the steel being used, and the engineers have previously designed a dozen more using the same approach. As a result, you can predict (see what I did there?) scope, schedule and cost. You do things once, and there’s one big pop at the end as the Champagne is opened.
Iterative
An iterative approach starts to move toward agile. It is useful when requirements are fuzzy and/or expected to change: Your stakeholders don’t know exactly what they want (but they have a vision, and will know success when they see it). Iterative is also a good choice when your design team is venturing into the unknown. The team continuously cycles through prototypes of the complex, the unknown and the fuzzy, stopping at the end of each cycle to get feedback and guidance before proceeding. Doing so reduces uncertainty and risk with each cycle. This approach costs more and takes longer, but you can be pretty sure you’ve delivered a solid, useful product by the time you’re done. As with a predictive approach, there is one Champagne bottle, one cork and one pop at the end.
Incremental
Developing incrementally is just that–breaking a large deliverable down into smaller, prioritized, useful increments that can be developed quickly and provide value early. The key term is “useful.” At the end of each cycle, something that is usable to the end user / customer is delivered; and, for all intents and purposes, the project could stop at this point because it delivered value. Next, the team builds another useful component and adds it to the previous one, expanding overall usefulness further. Think Lego blocks: The first block is useful (perhaps not very, though); so you stick a second block on it, making it a bit more useful; then a third; then a fourth… and so on, until you have a an intricately-detailed scale model of the Palace of Versailles. Value is realized early, and increases with each “mini” deliverable rather than all at once at the end of the project. Many bottles, many corks, many pops.
Agile
…which brings us to agile. Agile combines the cyclical, continuous improvement aspect of an iterative approach with the usable building blocks of an incremental approach. In doing so, agile attempts to reduce technical risk and increase customer satisfaction with early and continuous delivery of valuable products (that’s straight out of the Agile Manifesto). It’s a good candidate when requirements are vague or likely to change with the phases of the moon because the product that gets delivered at the end of each iteration is reviewed by a representative of the team that will use it. This product owner provides feedback as to what to build next–which could be a change of direction due to revised requirements, or an end to the project altogether if sufficient value has been delivered. If you’re developing a smart contract for a blockchain, agile can help mitigate risk by removing unknowns and demonstrating value early. However, if you’re building a bridge, and you run into trouble, agile probably won’t help–iterating doesn’t add value because the team knows its way around building bridges already; and, while development is done incrementally, each increment on its own is not usable and, therefore doesn’t provide a great deal of value.
Is agile the best approach for you? Could be; it really depends on the nature of the project. Hopefully the above will help you choose.
*Nominations are open for others–if you have a candidate for most overused DLC term, send it and I’ll add it to the list!
Find more tips like these at Professional Services Plus
