It doesn’t exist.

It seems corporations and large institutions are increasingly adopting new methodologies in software development, which is great for two reasons. Firstly, they’re going against the grain of the industry by embracing new ways of running their business, which I believe is a healthy thing for any organisation, regardless of the size, and irrespective of what methodology or process they choose. Secondly, it sets precedent for their competition and raises the bar of innovation for the industry.

That said, it’s sad that some companies commit to these methodologies, i.e., agile, believing that it will not only make their development teams more productive, it will also do their laundry. Then, several months down the track when they realise that it’s no easier to run a large organisation faced with the regular issues of human resource management, communication, blah blah, than it was when they were using waterfall or whatever style they espoused previously, they blame the methodology: “It’s because of agile that our code quality has dropped” and other such nonsense.

Now, I’m not promoting or defending any particular methodology. I do like agile for reasons I don’t need to defend, but for the purposes of this post, it doesn’t matter. My point is that there is no silver bullet, no nirvana methodology that will solve all your organisation’s problems, and methodologies should be embraced holistically, understanding their uses and accepting their shortcomings. Perhaps agile may indeed lead to a higher defect rate, but in my view this would more often than not be symptomatic of the fact that agile gives more responsibility to development teams to ensure test coverage because, unlike waterfall, there are no formal SIT (system integration test) or UAT (user acceptance test) phases. Does this mean that agile is the cause of a drop in code quality? Of course not. Many agile teams experience an uplift in test coverage through adoption of agile testing tools like Twist or Cucumber. A different methodology will simply compensate for, or expose different strengths or weaknesses of the team or organisation.

I just cringe at organisations throwing the baby out with the bath water, regardless of the methodologies, tools, or processes they choose. They’re the ones that miss out in the end.