First, a disclaimer, I am not bashing methodologies! Much excellent work has been done over the years on advancing the practices around development methodologies. The agile manifesto was pointed in the right direction, but when I look back, I fear that the authors' intentions have, over time, suffered from two conditions: dogmatic implementation and cargo cult imitation.
The problem with "branded" methodologies, as pointed out in Alec's post, is that the adoption of methodologies is often performed with a near religious zeal (often by the novice practitioner). This is the problem of dogma. The adopting practitioner is not the founder of the method, and if the practitioner does not have enough experience to understand the intent behind a practice (or set of methods), the adoption is blind, and blind adoption is always dogmatic.
To this point, imagine the a group of students whose teacher has moved away. Their source of insight and understanding has gone. No longer can they rely on the teacher for answers. What can they do? They can turn to the teachings. There are only two ways to do this, take the teachings as law, or take them as guidance. If the student lacks the experience to interpret the teachings, they are applied with blind faith, as law, in a rigid and dogmatic style. Either way, as time marches on, the encounter of new situations will cause an instance specific - prescriptive - variation on the method - which may or may not reflect the intent of the teacher. Eventually the original teachings are lost in a compendium of epic proportion, a large and unwieldy set of rules that are so prescriptive that they lacks flexibility. Consider our own body of law - all steming from the basic principles that founded our nation.
Add to that the unending search for the best and newest methodologies (or management styles, or technologies) and the problem gets infinitely worse. We have added the problem of the Cargo Cult - what Ivar has termed as our obsession with "fashion". Cargo cults are built around the ritualistic imitation of others who have received some benefit that the cult wishes to obtain. Businesses (and technologists) are absolutely addicted to the next new thing and with today's rate of change, it is impossible to master one fashion - or determine its benefit - before the next eleven are available and touting themselves as the best thing since (insert your methodology here).
To illustrate this point, imagine an organization who has a workable methodology. It's not great, but it is getting the job done. Then, from the top of the house, perhaps due to a change in executive management, comes the order that the organization will now follow xyz methodology. This could be for any number of reasons, lets say that the CIO knows someone who has used the methodology to great benefit.
A team may be anointed and charged with implementing the new methodology. To ease the transition, the team modifies their current compendium to reflect the new methodology, making it even more convoluted and unwieldy than before, and in turn compromising much of the value of the new methodology. Time marches on, and since the new methodology isn't getting the job done, it is abandoned for the next "fashion" - with the cargo cult like hope of receiving benefits.
But it's really not as hard as all that. Back in 2002 and 2003 , while I was working on software methodologies, I was a strong proponent of a core set design principles, the fundamentals of sound practice that can be applied regardless of which methodological veneer is glued over the top I would argue most of these veneers have strong cultural bias, and one methodology is more suited than another because of corporate culture, and hence better for that culture.
Regardless, here are the basic underpinnings that work for all methodologies.
- Any method should be as simple as possible and adapted to need - be practical
- Focus activities on capital building and minimizing overhead - build value
- Run your project as if it were a business - because it is.
- Understand how the operating environment affects your methods - because they will.
- Stand on the shoulders of the giants - don't reinvent the wheel (but don't be dogmatic)
- Minimize complexity and exploit automation
- Continuously improve your methods
- Continuously develop team proficiency
Thank you Alec for firing me up enough to write this article, and thank you Ivar for laying much of the foundation, even if the industry often looses sight.