The “Manifesto for Agile Software Development” catalogs very practical suggestions on how to engineer a software in an effective way. These are like fundamental truths, and I believe these could be extended even beyond software engineering, so much that they could be called Management Principles for Effective Teamwork. In the title of the manifesto, “Agile” is an adjective. It wasn’t called “The Agile Manifesto” or “The Agile Methodologies” where “Agile” becomes a noun. When something becomes a noun, it becomes a commodity — something that could be bought and sold. Rather, it could have been aptly called “The Agility Manifesto” for a terse colloquial version.
“Agile is not what you do. Agility is how you do things.” — Dave Thomas
When the “Manifesto for Agile Software Development” became “The Agile Manifesto”, an industry cropped up whose purpose was to look over Engineering’s shoulders and tell them they are doing it wrong because they are not doing exactly as it is written in the book (There is no book!), and then how the Engineering should be doing their job that no one understands better than Engineering themselves. Agile, a noun with ‘a capital A’ makes up for a great marketing gimmick of fear-mongers: “Agile is a thing, either you have it or you do not; and if you do not, you are in crisis.” Agility, on the other hand, is a characteristic, an attribute. It cannot be bought, it needs to be inculcated.
I wish Agile methodology were like Git — install it, it is up and running, and you have a swiss knife in productivity tools. Being agile sadly is much more complicated than that. Whether a certain framework (XP, Scrum, Kanban, etc.) works for you or not, whether it needs to be modified or reinvented altogether to fit in depends on various factors. The Manifesto never prescribed any one particular approach or framework, because no one can tell you what is best for you unless someone has tested their approach for your product, with your business setup, in your time and situation, and so on. There are no absolute rules in pragmatic world, and all rules are context based. Doing one thing in given scenario might not make sense in another. What works for a lean startup might not work a mammoth enterprise. Eg. One person responsible and accountable with one and only one Scrum team might work for a small company, but an architect in an enterprise getting fixed and limited to a team would not work out effectively. Only you can determine what is to be done, no one can tell you perhaps because nobody knows — just like you.
I am not saying not to adopt any framework. We must adopt, these are great. We must learn these frameworks, especially, if we are not following any and see that more value can be added through these. What we should be weary of is some outsider, getting paid hourly, telling us how to apply it in our own setup. I say we should be figuring that out, and not someone who does not understand anything about the software solution under consideration.
In fact, the manifesto was drafted essentially for dealing with the situations where nobody can tell how a decision could bode, and still must move forward making one. In essence, it says:
- Find where you stand
- Take a small step towards the goal
- Learn, understand and reorient yourself from the outcome
We must figure things out for ourselves since the theoretical blueprints might not exactly fit the pragmatic reality.