An introduction to Agile methods
Published: 24 Jan 2005 14:41 GMT
Most of us are familiar with two ways of developing software – the approach that McConnell (Rapid Development. Redmond, WA, USA: Microsoft Press) characterised as "code and fix", and an approach based on a disciplined, detailed process, called a methodology. Methodology based development has a reputation for being document-oriented, bureaucratic and slow, and is often resisted by developers.
Traditional methodologies have been favoured for large projects with extended timeframes, but have generally been rejected for smaller projects because people felt they added too much overhead, leaving small projects in the hands of the "code and fix" brigade.
In the last few years, in reaction to traditional methodologies, a group of alternative methodologies have emerged under the "agile" umbrella. Extreme Programming (XP) is probably the most widely know of the agile methodologies. However, others include Scrum, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal, Adaptive Software Development, and Lean Development, all of which were surveyed by Highsmith (Agile software development ecosystems. Boston: Pearson Education). Although the emphasis varies from one methodology to another, all these methodologies share some common principles, which have been expounded in the Agile Manifesto:
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
At a management level, the biggest distinction between traditional and agile methodologies is the attitude to plans and planning. Traditional methodologies focus on producing detailed plans—often laid out far into the future—and treat deviations from the plan as errors that need to be corrected.
Agile methodologies also produce plans, but treat them only as approximations for what will actually happen. When there is a deviation from the plan this is treated as feedback, and future plans are adjusted accordingly. The result is that while traditional methodologies resist change, agile methodologies embrace change and view it as a vital part of a vibrant project.
To preserve responsiveness, agile methodologies approach development in an iterative and incremental manner. Regardless of whether the initial planning described the required features loosely or in detail, a given iteration of an agile project will deliver a subset of these features, at production quality levels. At first glance this might seem like a standard RAD approach - except that most RAD projects aren't focussed on code quality; indeed RAD teams commonly complain when a customer wants to move an early iteration to production.
In contrast, the evolutionary approach used by agile projects, described in a different context over a decade ago by Gilb (Principles of software engineering management. Addison Wesley), means that they can be moved to production at almost any time.
Although more and more people are becoming at least aware of agile methodologies, even if they aren’t using them, there are still many misconceptions about them, particularly from a management perspective. Many managers are concerned that agile software development is just an excuse for hacking, or for not delivering the agreed features, and that it will be impossible to keep an agile project under control.
However, when properly implemented, agile methodologies are just as disciplined as traditional methodologies, and give customers and managers more control over a project, rather than less. For example, evolutionary approach development makes it very easy to estimate progress by observing working features, avoiding the classic "80 percent finished, 80 percent of the time" problem.
In subsequent columns I plan to go into more details of how agile methodologies work in real life, paying particular attention to dispelling common misconceptions. I’m very interested in using an agile approach to this column as well – although I have some idea of the path I’d like to follow, I’m keen to get feedback so I can change the content to maximise its value. The next column will provide an introduction to Extreme Programming, before we talk about how to start an XP project.
Steve Hayes is the founder of Melbourne-based Khatovar Technology. Khatovar provides training, mentoring and consulting in the effective use of agile development methodologies.
Did you find this article useful?
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
