Agile vs Agile
I have had occasion recently to read about different development methodologies, and in doing so I realized that I had a fundamental misunderstanding of agile.
What struck me as interesting is that so many people derive so many different meanings from this word. Here are just a few:
The Literate
ag·ile /ˈajəl/
Adjective Able to move quickly and easily: “as agile as a monkey”; “an agile mind”.
The Manager
We can have more features faster if we are more agile.
The Developer
I can spend more time coding new features and less time reading specs and writing documentation.
Lets see what we get when we go to the source.
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.
Hmmm. Seems like we have some people who are not on the same page. It seems to me that agile in the context of software engineering is an ideology. If we look further it seems that this same group provided 12 principles that provide guidelines on defining and evaluating specific implementations.
Principles behind the Agile Manifesto
The manifesto and the principles provide some solid guidelines, but they are not a fully fleshed out software development method. Enter the framework.
I think that when most people think of agile, they are thinking of something like scrum. It is important to understand that scrum is to agile as a fiesta is to a ford car.
It is easy to dismiss agile processes entirely because scrum is not a good fit. If you carefully examine the ideology of agile, it is actually quite versatile. This is because it only defines relative values. For example, just because working software is of more value than comprehensive documentation, it does not mean that comprehensive documentation can not or should not exist.
By gaining a fuller understanding of the core ideas of agile development, we can take advantage of the benefits while avoiding the common misunderstandings.