Archive for February 2009
Agile software development is a methodology that relies on small iterations and frequent releases, teamwork and collaboration. Agile development embraces change as the rule not the exception. It is generally nimble and adaptive. Agile typically favours face to face communication to documentation. Agile measures success according to working software (hence the importance of rapid prototyping), not abstract (from a software end-product standpoint) project milestones.
By putting the emphasis on the end-product, on collaboration and by embracing change, the agile methodology is perhaps the best software development methodology available today (for most projects). We use some form of agile development and project management on virtually all projects. One size does not fit all however. I sure hope the avionics of the plane I am flying on were not developed by a team who believes that paper specifications and formal documentation were unnecessary project overheads. Yet most projects, even the largest and most complex (perhaps better served by the waterfall method), benefit from adopting some agile principles.
My biggest concern with strict agile is the insistence on human interactions over documentation, as if one was a substitute for the other. Take requirements analysis for example (a topic recently covered in a LinkedIn Q&A). Gathering requirements is an iterative process, a series of passes. After each pass (a discussion, interview or meeting with stakeholders), requirements must be documented and compiled. Provisional conclusions and principles are drawn. At the next meeting, it is important to review and vet the requirements, assumptions and principles as understood and documented. This will typically elicit further qualifications and uncover other requirements and assumptions. The process requires multiple iterations, each advancing the requirements-gathering further towards finalization. The process goes on until all parties believe they have exhausted all qualifications and that the requirements, as documented, fully encapsulate the business, functional and technical needs of the particular feature or component being discussed. This does not mean the specifications are ever “final” or set in stone (one of the biggest arguments against the waterfall method. “finalizing” requirements assumes changes are the exception not the rule). It does however support the idea that documentation is an extension of the collaborative thought-process not a substitute for it. I believe without this important qualifier, the agile methodology cannot scale to large and complex projects where dependencies, complexities (business rules and complex processes) and risks abound.
In conclusion, I believe the agile methodology to be sound and effective, cost and otherwise. But documentation does not undermine the methodology, it makes it better.
User interfaces are typically responsible for representing objects as pixels on a screen. These objects (sometimes referred to as widgets, controls or gadgets) interact with each other as software abstractions, governed by rules which often (but not always) emulate the real world (stacking, shuffling, etc…). What if the objects had real physical properties governed by real spatial interactions? Meet computer 2.0 at http://www.ted.com/talks/david_merrill_demos_siftables_the_smart_blocks.html