We talk a lot on this blog about Agile, a collection of methods used in software development. I think of Agile as breaking a development job into small pieces, which teams aim to complete quickly using simple code.
While Agile has plenty of fans, it also has its share of critics. One of the most outspoken of those critics is Lajos Moczar, an Ireland-basedconsultant, author and veteran of the information technology world.
Moczar gained a measure of notoriety with the June 2013 publication of a piece he wrote in CIO, headlined “Why agile isn’t working: Bringing common sense to agile principles.”
What follows is the first of a two-part email interview I did with Moczar about his views on Agile. I started by asking what, if anything, has changed since the publication of his CIO article.
In the CIO piece, you called Agile a “fad methodology.” In the intervening time since then, have the proponents of Agile done enough to address the problems that you outlined with that methodology?
Well, since then I’ve been involved in yet more agile projects and I stand by everything I said before.
This is why I called Agile a “fad methodology”: While introducing some good ideas, it is in reality a simplistic approach that all too easily devolves into clever terminology and cute practices. While Agile techniques can work in a limited set of situations, they tend to fail badly at scaling either horizontally or vertically.
The truth is that Agile doesn’t go deep enough. If waterfall projects failed and now agile projects fail, then we haven’t achieved as much as we think. What is needed is something more fundamental. We should be asking the question: Why do IT projects fail? For example, if traditional plan-driven methodologies fail, do we know why? Was it because being “plan-driven” is inherently flawed, or was it just done badly?
This is where the work is that still remains to be done. Until we have given people a better way to think that results in better products and fewer bugs, I don’t think we’ve achieved much.
In your estimation, does the problem with Agile boil down to poor execution by the teams that try to carry it out? Or is the issue that the methods and techniques of Agile simply don’t work?
No, they don’t work under most circumstances.
I said Agile is simplistic. Here’s just one example: In his book “Essential scrum,” Kenneth Rubin has said about scrum iterations that feedback “will guide us to do the appropriate and economically sensible number of iterations.”
Who says that will happen? Does the process guarantee it? Is there something inherent in the nature of feedback that does that? Or in the nature of iterations? Or in the nature of human beings that, given feedback, will naturally do what is appropriate and economically sensible? This is where Agile stops: it can’t answer these questions. It is more wishful thinking than a philosophy of change.
Some might argue that with a good scrum master this magic will happen. And I am willing to admit that sometimes it does, but — here’s the rub — not because of anything to do with Agile. It is instead because the scrum master happens to have innate good project management skills and might even be doing some un-agile things in pursuit of success. It is those skills that Agile doesn’t teach, but which we desperately need to systematize so we can leave the arena of feel-good kindergarten practices and achieve repeatable and long-lasting results.
Your CIO piece argued that “Agile promotes the practice of ignoring defects.” That, you said, “leads to unmanageable backlogs and, eventually, to ineffective development.” Is the problem that testing in an agile environment simply can’t be done as fast and effectively as it should be? Or does the fault lie with developers?
Again, it’s the methodology. The iterative and incremental nature of development means a constantly moving target for testers, and no matter how hard you try, features always get prioritized over testing. The only way to get out of the vicious circle is to ring fence these very ideals of Agile — increments and iterations – until you have the backlog under control.
In Part II of our interview, Moczar shares his thoughts on the best development method from a testing perspective.