AGILE SOFTWARE DEVELOPMENT: MANAGING SOFTWARE REQUIREMENTS THE AGILE WAY

The Agile development movement began in earnest in the 1990s as a rejection of the establishment with its rather staid and seemingly sluggish development methods known generally by names such as the waterfall model or V-model. These older methods had gained a reputation for missing deadlines, going over budget or failing completely and Agile offered a means to make this a thing of the past. With most revolutions the ideas are rarely new and often promise more than they can actually deliver, and so it has proven with agile methods. While there are considerable benefits to agile methods, they are by no means a panacea for past ills and should only be adopted after serious consideration and careful planning. It is critical that the strengths and weaknesses of any method are understood before proceeding, and risks reduced through awareness and preparedness for potential pitfalls. This book aims to provide a quick starting point for understanding the most prominent methods, their individual characteristics and unique offerings. All Agile methodologies share a set of core ideas which are prescribed from method to method in subtly different ways; iterative and incremental delivery of working code, frequent collaboration with stakeholders, closely working, self-organizing teams, and the ability to embrace change late in the project. Agile methods are shamelessly incestuous, borrowing from each other and using existing ideas in slightly different ways so it becomes very difficult to tell whether a project is following any one method as even the slightest adaptation of any aspect of a process can make it seem more like another. Fortunately, the majority of the concepts are compatible so that it becomes very easy to use agile methods like a smorgasbord, picking and choosing parts at will. Some Agile proponents are so enthusiastic that they fail to recognize that agile methods have drawbacks. They are not particularly adaptable to larger, enterprise or distributed developments where teams cannot all meet face-to-face and they are less well suited to fixed-price, contractual projects in which functionality is non-negotiable. They are also difficult to apply to embedded systems. Some Agile methods have little up-front design effort which can lead to considerable rework or integration problems. User involvement is also a double-edged sword when frequently changing ideas lead to more requirements churn than even agile processes are prepared for. The Agile Manifesto (www.agilemanifesto.org) provides a set of guidelines for those wishing to become more agile but it is not a set of rules and is does not in of itself define process. This leaves plenty of room for debate as to which methods are Agile and which are not. In this article we shall address those that are generally accepted as Agile followed by those for which argument continues. It should be stressed that while some methods describes themselves as Agile, or include ‘Agile’ in their name, that does not necessarily make them so.