Agile: Misconceptions, Definition and Perspective
It’s unfortunate, but in my experience, Agile development is closely following the Gartner Hype Cycle. Furthermore, I’d guess that many teams are currently in the “Trough of Disillusionment”, perhaps considering Agile another overused buzzword in an industry full of buzzwords. In this post, I enumerate some common Agile misconceptions and, hopefully, offer a more reasonable perspective.
Agile Misconceptions
A common misconception is that Agile is a software development methodology. It’s a reasonable statement, and the sentiment is accurate. However Agile itself lacks the detail of a methodology. The Scrum methodology is most associated with Agile and seems to align itself with the principles of Agile, frequent, short iterations, collaboration, etc.
In recent experiences I have heard Agile defined as a particular development practice. For example, Agile is working in short iterations or Agile is automated testing. Again, there’s a nugget of truth here, but the answer is incomplete.
Other misguided perceptions are that Agile applies only to the IT department or that Agile is easy or at least easier. Clearly the former ignores Agile’s emphasis on collaboration and interaction. Concerning the latter, Agile helps remove obstacles to better software, but does not involve less effort. I feel Agile often highlights weaknesses, like poor communication skills, or lack of commitment by the business. And those can be hard to fix.
Defining Agile
At a really abstract level, Agile is a philosophy. But I find it hard to sell a philosophy to management. So I use the definition is that Agile is a set of practices that embody the Agile Manifesto[1]. If you’re trying to sneak Agile into your shop, which I currently am trying to do, describe it a set of practices that follow the concepts of integrate, inspect and adapt. Senior management may especially appreciate the inspect and adapt part. I envision the Agile principles and practices being organized as follows[2]:
1. Individuals and interactions over processes and tools
- Face to Face Communication
- Code Reviews
- Pair Programming
- Close Proximity
- Mentoring
2. Working software over comprehensive documentation
- Test Driven Development
- Continuous Integration
- Unit Testing
- Frequent Releases / Short Iterations
3. Customer collaboration over contract negotiation
- Daily Meetings
- Face to Face Communication
- Close Proximity
4. Responding to change over following a plan
- Frequent Releases / Short Iterations
- Continuous Improvement
The figure below is a visualization of the above list.
The ideas of maximizing simplicity and self organizing teams need to fit in somewhere. I just haven’t figured out which principles they best embody.
I suppose any development methodology could be used with Agile, but, for me at least, the Scrum Methodology best compliments Agile.
Agile In Perspective
Agile is a means to an end. That end, of course, is better software. Software that meets the customer’s needs and is reliable, maintainable, secure, etc. The end game is not to be Agile, but to create better software.
When Agile was conceived in 2001, it was in response to rigid, structured methodologies that emphasized documents, specific roles for people, well defined phases, milestones, etc. These methodologies seemed generally inconsistent with how software was actually created, or should be created. Nor did these methodologies embrace change, a reality in most line of business applications.
Eight years after conception, many places would not call themselves Agile. However I would venture to guess that many of those places have adopted Agile practices, for example unit tests, or shorter releases. If Agile isn’t mainstream, many of its practices are.
Most of what I’ve discussed thus far is at the project level. For developers, many Agile practices existed before Agile. Two years prior to signing the Agile Manifesto, Andrew Hunt and David Thomas wrote The Pragmatic Programmer. Many of the practices they discussed would now be called Agile practices. To find out more about Agile developer practices I would direct you to either The Pragmatic Programmer or Practices of an Agile Developer.
[1] I wish the Communists didn’t have a manifesto. To me, it ruined the word.
[2] The numbered items are from the Agile Manifesto. The bulleted items are practices that support the concept.