Can You Define Agile?
What is Agile?
The software industry is still quite young, yet as it matures, we’ve seen many development trends, technologies and tools come and go. As you know, one methodology that has become popular of late is Agile. We all know it as an adjective, we all desire to be agile. Who wants to be slow and clumsy? Those that gathered and put together the Agile Manifesto certainly chose a good name for “it”, whatever “IT” is. That’s the subject of this article, the definition of Agile or what is Agile? Agile is capitalized from here on, because we all know we’re talking about the noun, as a development methodology, rather than the adjective. Yet how do you define Agile?
The Definition of Agile – The Agile Manifesto
We all look to the Agile Manifesto as a rule book or even bible of some sorts when it comes to Agile as used in software development, don’t we? The Agile Manifesto, as such, is a set of guidelines, principles or ideals. They haven’t been chiseled in stone as formal rules and codified law. They are adaptable, malleable, and subject to change and interpretation by different people in different ways. Key Agile ideals as per the Agile Manifesto, include:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Roots of Agile – The Opposite of CMMI
If you look at these carefully, they are in response to the guiding principles that were once fostered by the Software Engineering Institute (SEI) and the Capability Maturity Model Integration (CMMI) Institute. They used to be joined together at the hip but now have become separate and distinct entities. Back in the 80’s the federal government gave a grant to Carnegie Mellon for the SEI to form the Capabilities Maturity Model as per work done by Watts Humphrey. The model was first published in a book in 1989, and then later in 1991 they formalized it into the 5 levels of maturity that a company (potential contractor for the government) could be evaluated on as a standard. They believed that this model would help vet contractors that were building software with the assumption that more mature and repeatable processes would lead to better quality software. So when you look at the Agile ideals above, you can see that key CMM characteristics are exactly the opposite of Agile:
- Processes and tools
- Comprehensive documentation
- Contract negotiation
- Plans
I think that the original intention of CMM was good, in that better processes do make better products, but the road to hell is paved with good intentions. In order to get certified, the were “certification organizations” that would go onsite and document a company’s processes. Eventually, they developed a rating system. i.e. CMM Level 3 or 5. Unfortunately, organizations learned they could take certification shortcuts through various backdoor avenues, and then everyone was rated CMM Level 5 thereby eliminating the value of the certification. I’m sure there were studies done that correlated higher CMM ratings to better quality software, but these studies were most likely carried out by those benefiting from such a correlation.
Returning to software, in manufacturing, CMM works fine for tires and autos, but maybe not as well for coding. In many cases, writing software is akin to creating art; where good processes don’t necessarily lead to high quality software. Talented people AND good (and ‘good’ is not equivalent to well- documented and repeatable.) processes do. While you can measure the quality of raw materials used for rubber tires, there is no equivalent “yard stick” that you can use to measure the capabilities and intelligence of a software developer.
Agile Is a Set of Ideals
So with this beginning, Agile was born. People began following this new set of ideals as they were released from the shackles of CMM. Finally they had a pathway that would deliver them to somewhere! They began to wander out into the wilderness with no documentation, no plan, and no processes. Eventually groups would ban together and form a set beliefs within the framework of the Agile ideals and call themselves Scrum. Or other groups such as Kanban, Extreme, etc. They were not enemies of each other, still believing in the same Agile ideals but implementing them in different ways. They would even get together at grand convocations around the world and discuss their practices of Agile. Some now are even “Adding to the Noise with Agile is Dead, Long Live Agile” pronunciations! It’s focus on individuals and interactions over processes and tools; it’s very set of ideals, is the life blood that keeps Agile kicking.
The Ideal and Not So Ideal
With every ideal, there are associated challenges. The problem is that when you are practicing and striving towards your ideals, and doing what you believe in, you sometimes encounter conflicts in opposing forces, thoughts and actions. After all, the ideals are just that, ideals. They are not carved in stone! Maybe what started off as a great ideal, turned out to be not so great? Perhaps you realize that the ideal is not suited for you or contradictory to the way your organization works. Instead of “turn the other cheek”, you may decide that “an eye for an eye” works better for you and change the ideal.
So, when you are “in the wild” implementing the Agile Ideal, remember that there really is no Definition of Agile. You simply can’t define Agile. It is a set of ideals that you can strive for, and sometimes fail to achieve. The big question is, given that we may fail and that obstacles arise to block us, what can we do to recognize what these issues are so that we can implement our own version of the Agile Ideal. If you’ve got issues that have blocked or hindered you from reaching your Agile Ideals and have solved them, please write and let us know. We’d love to hear from you.
Leave A Comment