The Manifesto for Agile Software Development is perhaps one of the greatest published works in the field of software development. It has had a tremendous effect on the software community and inspired any number of processes, tools, documents, contracts and plans. This is somewhat curious, since the very essence of the Manifesto is that these things, while valuable, are of lesser value when compared to motivated individuals collaborating and interacting to produce working software even in the face of certain change.
So Agile adoption is a very precarious precipice. If you believe you’re Agile because you’ve implemented the latest Agile Methodology across your organization, you’ve completely missed the point. You’re not putting control in the hands of the motivated individuals, but in the hands of the processes, tools, documents, contracts, and plans. A few people who have come to this conclusion and have dubbed their reaction to this revelation as Post-Agile. So rather than recommending the Agile Methodology du jour they advocate instead one should “simply do whatever works for you.”
Now, this is all well and good, but if you’ve ever experienced the flaming hoops through which you must dive just to get a well-published, oft-implemented official Agile Methodology pushed through your organization, the hairs on the back of your neck stand up when someone suggests you should instead simply do whatever works for you. Management has a difficult enough time with things like Scrum and XP. They’ll laugh you out of the room if your best defense for a new practice is “well, I think it’ll work for us.”
So, where are we then? The Manifesto stays silent on how we should actually achieve the Principles. The Methodologies tend to fail miserably when implemented strictly by the book. The Post-Agilists have left us with hopelessly little. Agile is worthless if we can’t do it.
This is one of the deepest misunderstandings surrounding Agile. Agile is not prescriptive, instead it’s the realization that being proactive is to be intensely reactive. Agile is characterized not by what you do, but by how you can do it better. Agile Methodologies are not Agile in themselves, they are snapshots of the current process and practice of a few agile shops. If those shops are truly Agile, by the time you implement what they were doing, they’ll be doing something completely different.
Agile is not a set of rules, it’s a set of principles; ideals to move towards, not laws to govern. So in a sense the Post-Agilists are right, do whatever works. But if that’s the case, how do we know what will work? If Agile isn’t prescriptive, how do we know what to do? How do we know how to do it better? What are the guidelines for determining whether something is more Agile than something else?
It is my claim that there is only one rule to Agile, the Agile Golden Rule, and it is simply this: Communicate with others as you would have them communicate with you.
The most critical point here is that communication is possible under any methodology. Whether you’re an agile shop or following strict waterfall, you have the right and privilege of having a completely transparent, trusting, open dialog with your fellow stakeholders on the project.
That said, while communication is independent of the methodologies in place, it is a sad but true fact that processes, tools, documents, contracts and plans can make open dialog difficult to the point of impossible. In those circumstances, I’m afraid I can do little more than offer my condolences; I have been there before and I know your frustration. But at the very least, you have a clear indication of the barrier to developing better software. I encourage you to work to remove the barrier or work to remove yourself.
Dialog is difficult even when the channels for communication are fairly open. Work to keep the channels open; make sacrifices if it comes to that. Protect your right to engage in dialog with your fellow stakeholders. This is the core and heart of Agile; if we put our heads together we can come up with something better.
Posted with : De Machina