My Own Understanding of Agile

I had an interesting discussion with a facebook friend concerning the use of metaphors in understanding any subject matter. In that exchange, I used agile development as a specific example of how different metaphors can illuminate our understanding on the subject. It was a short discussion, but it did give me the desire to try and expound on it and see how far I can push the different metaphors.

That kind of topic, however, is too large to do as a single blog post; so, I decided to break it into separate blog posts. As a preliminary step, I thought it would be good to at least write my own understand of what Agile is.

A Short History of Agile

In 1999, Kent Beck invented a software development strategy called Extreme Programming (XP).

XP had some early success, and gained the respect of the development community. However, XP was not the only game in town. Other people created different methodologies (i.e. SCRUM, DSDM, etc…) that tried to solve similar development and project management problems.

In February 2001, the XP guys convened a meeting of several thought leaders from the different group with the intention of finding common ground among all the different processes.

The common ground was eventually written up as the Agile Manifesto which is 4 principles

  1. Individuals and interactions over process and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Anything that obeys those values can theoretically be considered agile.

Agile Strategy vs Agile Tactics

I view Agile as an overall strategy whose tactics are left undefined. This is why you have several different methodologies all claiming to be Agile: SCRUM, DSDM, LEAN, Test Driven Development, Domain Driven Development, Behavior Driven Development, etc …

Each of these methodologies can be viewed as different implementations of Agile.

The Two Sides of Agile

It useful to divide agile into two sides: project management methodologies and software development methodologies.

Methodologies like SCRUM, LEAN, SigmaSix, or Feature Driven Development focus on things like the organization of work and team building, while methodologies like Extreme Programming, Rational Unified Process, and Crystal Clear focus on the organization of code and documentation.

In reality, there is a lot overlap between the two sides. However, each methodology usually is only strong in a single aspect. You just have to make sure that you have consciously determined how you are going to do project management and software development individually.

Unfortunately, it is very common for organizations to apply only the agile principles to project management. Actually, I would say that most companies that I’ve seen apply agile have only ever applied the project management side using SCRUM.

In fact, this phenomenon of using SCRUM only is so common that it even has a name: flaccid SCRUM.

Conclusion

Agile is a set of guidelines; not a set of rules. Therefore, you should not treat any single methodology as a cookie cutter solution. Instead, you should take the principle and figure out a way to apply those principles toward your own organization.

In my opinion, the different methodologies (i.e. SCRUM, LEAN, TDD, BDD, etc…) all work, but only within certain contexts. Sometimes different methodologies can work together, and sometimes they can not. It is up to you to think when and where they can work for you, and cherry pick “solutions” from each methodology if need be.