In a great blog post on the Outsell site, Mark Strohlein talks about some important aspects of agile development. Among the points he makes, I like these the best:
- Agility is a mindset, not a process. You have to think and live this way. You can’t write it out.
- You do the same types of work in an agile process, but you do them differently, and that’s important. Instead of trying to get the requirements done before you work, your work reveals the requirements iteratively. The requirements and the documentation of the work are both captured in the final product.
- Agility is not one thing or approach or process. It is agility. It is an adaptable approach that tailors itself to its purpose.
There are other hallmarks of agile development compared to waterfall development. Of these, the hallmark I always watch for is that in agile development, late requirements are viewed as a good thing and are embraced — you revealed an insight that you found before you went live, and probably one vital to the success of the project. In waterfall development, a late requirement is viewed as a failing and resented.
In agile development, the final product is the goal, which means that the connection with the user is the measure of success. Too often, waterfall development processes lose sight of the reason the project was undertaken — meeting a user need. Instead, a process is enshrined, and the completion of the work as specified is immunized from user interference.
Agile development isn’t appropriate for every project. But in a world in which more and more things are built like software (coded, versioned, iterative by nature, and independent of hardware), agile development is vital to success.
Discussion
2 Thoughts on "Agility = Mindset"
We all want to develop robust new software functionality quickly, but only certain applications are suited to the “agile” approach. For example, a “mash up” of manuscript author location and Google maps is a perfect candidate for “agile” development. If you get it wrong, nobody gets hurt. On the other hand, I don’t want Bank of America doing anything “agile” with my online bank account. Usually, Agile = Fragile.
Richard Wynne
Richard raises an important issue with his linkage of agile to fragile. This is one perception of agile development that holds people back from implementing it for larger projects. I think it’s a misperception.
In my mind, waterfall development is the fragile type, mainly because it fails to adapt to discoveries and input for a long time between specification and completion, and because the process to revise it is slow and embeds the root problem yet again. In short, the goal of waterfall development is a specification, not a use-case or even users.
Agile development takes into account the users and the evolving environment, which yield changes and decision-making and feedback as development proceeds. From anecdotal evidence, even Bank of America has found this out, changing its Keep the Change program at the last minute to include matching funds for the first year based on the CEO’s enthusiasm and intuition that this would drive adoption. In a waterfall environment, this would have been rebuffed as outside scope. The champion’s enthusiasm and insights would have been lost.
Agile development doesn’t mean lack of excellence. In fact, as Strohlein said in his post on Outsell’s site, agile development does what waterfall development does, but without the limitations and with new strengths.
I think a challenge for established IT infrastructures is that agile development involves small, focused teams, not large, showy, multi-tiered, process-driven groups. Reporting, meeting, status updates, and the impressiveness of the endeavor all change, and in a way that can make traditional leadership feel things are out of control, concealed, or non-strategic. This is also a challenge for agile development proponents — how do you adopt agile development while meeting the needs of corporate management?
As you can tell, I’m a strong advocate of the agile approach. I’ve seen the difference in reality. While agile organizations and approaches generate results and integrate feedback and ideas, waterfall methodology integrates caution, slowness, and process-driven staleness.
