Agile in the Right Direction
I'm in agreement with the conclusions of the Software Development times article on the review of Agile for 2010. It concludes that among experts there was no prescriptive Agile method for all projects, but Agile for most organisations will deliver value and quality.
Agile methodologies contain varying degrees of prescriptiveness. The Unified Process for example has up to 50 processes (not all are mandatory) whereas Scrum has only 9. XP and Scrum are more focussed on terms and processes that relate to the software whereas DSDM Atern contains a more corporate friendly approach with pre-project feasibility and post-project stages as part of the project lifecycle.
The article highlights that the elimination of waste is not mentioned in the Agile manifesto but that the question "Why are we doing this?" is key in any project. This refers to an explicit business reason as well as any measure of quality relating to a specific functional deliverable.
Here Kanban offers a Lean perspective, adapting the just-in-time principles from manufacturing. The key is to limit the development work-in-progress by operating a pull system—tasks are only started when a resource is free to begin them. The number of tasks at any stage in the development process from analysis through to testing are limited.
Agile is not without its critics or problems. There are an array of different agile methodologies that may be suited to particular environments. Scalability can be an issue if not managed effectively but techniques such as Scrum do specify retrospectives after each Sprint. Agile adoption is also required from the business owners as well as any IT division which in itself presents challenges. Agile is about learning and refining. Development iterations with business owners involved deliver confidence and quality software if managed correctly. The first statement in the Agile manifesto is after all "individuals and interactions over processes and tools."
The alternative to Agile—Waterfall, where requirements are scoped and signed off prior to development, has an ever-decreasing justification if developing software in-house. Requirements up-front, signed-off, and then delivered months later are fraught with problems, especially if the project relates to online product delivery.
With software development suppliers however the appeal of Waterfall is still strong. With a limited number of development resources and the account management driven approach to business where new business is regularly acquired, can they really work any other way than getting a client to sign off to a specification which they will then deliver at some point in the future?