The Pollution of Agile

There is confusion in certain quarters about the concept and ideals of Agile; what it aims to achieve and the framework that has been defined to help reach these goals. The terms Agile and Scrum are often used interchangeably in general conversation which only fuels the confusion.

Agile and Scrum are not the same!!.

Scrum is just one of a number of lightweight processes, others include Lean, XP and RAD, that sit on top of the non-specific Agile framework. Each of these has their own pros and cons but all have the same aims to replace historic, heavyweight processes of the past.

When Ken Schwaber and Jeff Sutherland (and others) put forward the idea of Agile (in the Agile Manifesto way back in 2001), the IT industry was heavily dependent on a waterfall-based approach to serious software development. This seemed at the time to be in direct opposition to much of what Agile proposed in terms of incremental and adaptive software development. However in hindsight much of what Agile stood for had been around as far back at the 1960s. Incremental software development (Weinberg, 1957) and adaptive practices (Edmonds, 1974) were well established so it was a surprise at the time to the number of eyebrows that were raised by this 'radical' approach to software development.

The Agile manifesto that governs and defines the overall framework has only twelve statements. Note that none of these statements provides any specifics regarding industry, technology or process and are limited to goals alone.

These statements can be distilled into the following four areas:

Individuals and interactions: self-organization and motivation are important, as are interactions like co-location and pair programming.
Customer collaboration: requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
Produce Working software: working software is more useful and welcome than just presenting documents to clients in meetings.
Ability to Respond to Change: agile methods are focused on quick responses to change and continuous development.

As Schwaber stated "Scrum is not a methodology that needs enhancing. That is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed".

The ideas of Agile are simple, the simplicity of an implementation maybe not so. Misunderstandings or alterations to fit specific needs have helped to pollute the pure, industry agnostic, framework towards specific needs. There are many instances that can be stated to support this claim, including "Sprint 0", variable sprint lengths within a project and 'regression-testing-at the-end' specific sprints. I am sure readers can each find their own specific examples to extend this short list.

What is required to understand Agile is a thorough grounding and understanding of what Agile is trying to achieve, without burdening the concept with project and industry specific baggage. Only then will the true power of Agile be understood and gain the recognition it deserves.

References

Edmonds, E.A., (1974). "A Process For Development of Software for Nontechnical Users As Adaptive Systems", General Systems, Volume 19, pp. 215-218

Weinberg, G.M. (1957). "Iterative and Incremental Software Development", pp. 47-56