Acknowledging the Common Good of Agile
by Logapps LLC
June 5, 2013
Praising the good of Agile and abrogating the negativity it brings.
Introduction
It’s a common misconception that Agile development methodology is a no-documentation-little-planning-and gun-ho-developers-on-the-loose Google style of project management compared to the traditional Waterfall methodology. Critics of Agile say this development methodology is making things worst for some software people by promising solutions it cannot deliver and displays a habit of promoting sloppy requirements, hiding true cost of development and preventing effective management. Their argument is that the latter leads to long-running projects, dissatisfied customers and an overall IT ineffectiveness. Additionally, critics say Agile only works when products are in the proof of concept phase of development and teams are already integrated.
With software development cycles are getting shorter and shorter due to demand for faster time-to-market, Agile offers a project management style suited to the ever-changing software development environment. Organizations can find significant value in adopting agile methodologies and techniques because agile practices can help ensure you meet customers’ expectations, deliver products on time, and create a motivated environment that is able to quickly adapt to change.
Background
Agile software development is the process by which a software product is produced quickly and efficiently by means of frequent and complete releases allowing the stakeholders in the project to get their hands on the product in order to test, review it, and provide any additional inputs. A prototype or proof of concept can be developed into a useful productive software product by means of an iterative and incremental process whereby feedback is given by all stakeholders, based upon the rapid successive releases of the software.
Organizations like The Project Management Institute (PMI) are gradually adopting Agile as a valid project management methodology with its new certification, PMI-ACP, PMI Agile Certified Practitioner. Today, there are quite a few arguments to be made on both sides for the practice of agile development but the community should take notice to the amount of good Agile is doing rather than the minuscule negativity it brings.
Flexibility
First, Agile provides more flexibility compare to traditional waterfall methodology. Waterfall is a Hitler of scope and features ahead of design and implementation. With scope as a constant, not willing to be moved or negotiated with, the other aspects of the project management triad –schedule and cost – must adjusted accordingly. With Agile, schedule and cost are the major determining factors and it is scope that changes in order to accommodate acceptable business demands…the client’s needs. For mature Agile teams, this level of flexibility is brought about by years of experience working together. Traditional Waterfall won’t allow this level of flexibility once a project is underway since it strictly adheres to the concept that once a stage/process has ended, one cannot go back to adjust.
Instantaneous Feedback
Secondly, interaction provides immediate feedback to the client and management. Agile Scrum methodology calls for smaller release cycles known as interactions with other nomenclatures having similar meanings such as story points, sprints, drops, demos, etc., in which the product is always in a ready release state. This ready release state is made possible by continuous feedback from all stakeholders from product owners and end users to the development and quality assurance teams. Comments, corrections and suggestions are immediately passed on to the developers and testers, who in turn judge if such changes can be accomplished without negatively affecting the schedule, cost, and current/future delivery of features. Standard iteration cycles usually span one to two weeks; thus end users see progress in a shorter amount of time compared to the Waterfall methodology with stretched cycles spanning 1-2 months.
Proactively Hunting Defects
Lastly, Agile gives organizations the capability to present the final product with few defects. This is the result of quality assurance testing being done on each cycle. In a CIO article by Lajos Moczar, he argued that focusing on continuous delivery of software value has the effect of creating an “unmanageable defect backlog while developers work to put something in front of the customer”. Since QA can’t stamp a release as “client ready” if it isn’t working properly, and the Agile methodology requires that each iteration be a virtually finished end product, defects are detected very early on; thus, Agile does not promote the practice of ignoring defects but simply prioritizing and taking corrective actions on the fly. The continuous process of “develop, build and test” also cuts down on the number of defects as the iteration cycles go on. Combine manual and automated testing and you drastically increase test coverage before the final product is released. Agile team composition should consist of at least 1 person who spends between 80-90% of their time taking on the roles and responsibilities of the quality assurance analyst or engineer and 1 person dedicated to test activities. This will help reduce the defect rate while improving awareness and mitigation practices, thus cultivating a quality software product.
Agile may not be for everyone and the same goes for Waterfall but that begs the question – what is the right project management methodology for your organization and what software development approach should we use for any given software project? Well … it depends!