How agile paradigm differs from traditional project style software development?
This post is based on two excellent articles written by Martin Fowler and Mary and Tom Poppendieck.
Historical literature suggests that traditional software development processes were rooted in engineering methodologies that initially developed as or project-based approaches. Civil and mechanical engineering disciplines served as convenient bodies for lending process knowledge to early software development approaches. Agile methods developed more or less as a reaction, but do not represent the opposite extreme of the traditional waterfall approach. Instead agile methods have just enough process without being too bureaucratic — less document oriented and more code-oriented.
In comparing the lean/agile with traditional project approaches, Martin Fowler has points out two fundamental differences.
First, agile is adaptive while waterfall methods are predictive. There are several reasons for this. Separation of design and construction has been possible (and needed) for civil and mechanical engineering feats, and construction process can effectively utilize lower-skilled human resource following a fixed plan. Requirements can often be clearly defined for manufacturing projects. Material requirements, budget and with some accuracy, a timeline can also be drawn up. Success in this traditional paradigm is defined as adherence to the plan.
Software development is a highly creative process with negligible cost of construction. Changing requirements is a norm, and in fact, business environment changes so rapidly that software ought to be changeable. Estimating costs is hard because it is a design activity with rapidly changing raw materials and variations in people doing the task. The actual value of a feature is hard to predict until used. Therefore, agile methods seek flexibility and iterative development, which helps ground the successive iterations through frequent reality checks. Ideally, agile requires close customer cooperation for building something that is of high value. This may turn out to be different than what was originally planned but has gone through user testing and is much more likely to be relevant to the business.
The second important difference between agile and traditional methods is the people orientation of agile rather than process orientation. While a Taylorist approach may apply well to manufacturing industry where the focus is on creating repeatable plug-compatible units of work and workers, software industry involves creative design work by programmers who are highly skilled professionals and cannot behave as predictable replaceable units in a system. Lean/agile methodologies therefore treat programmers are people, and advocates for a delegatory style of management rather than measurement-based external controls. This requires a shift of technical leadership towards programmers as well as a continuous contact with business leadership in order to create relevant outputs.
Besides these fundamental differences, the agile methodology encourages improvement of its own process through shared feedback at every iteration.
In a nutshell, modern lean/agile methodologies like Scrum, Extreme Programming (XP), Crystal and others, differ in their fundamental assumptions about the nature of software development, and produce better results than the traditional and rigid project-based approaches that were borrowed from disciplines with very different nature of work.
