Lajos Moczar recently posted an article in CIO magazine titled “Why agile isn’t working” in which he states that “I’ve concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT”. He goes on to identify ways in which he says agile is not only failing but making things worse for the IT industry as a whole.
I’ve read the article carefully and tried hard keep a balanced perspective as I perused it. I can’t keep calm – this article is dangerous unadulterated drivel! The author misinterprets the agile manifesto and takes some of the agile practices completely out of context, using unfounded statements to justify his conclusions.
This post is my response, addressing the points he makes and tackling the myths he propagates.
Agile “flaw” #1:
He maintains that agile has a focus on delivery over quality, citing part of principle #1 from the Agile Manifesto . The full wording of the principle is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Moczar focuses on “continuous delivery” and asserts that this “has the effect of creating an unmanageable defect backlog while developers work to put something in front of the customer.”
He totally misses the key element of this principle – VALUABLE software. Valuable software has high levels of internal and customer visible quality. Allowing defects to creep in to the development process is accumulating technical debt, increasing the cost of change and detracting from business value; agile should never be used as an excuse for sloppy work practices. Address defects as soon as they appear and resolve them immediately – defects should never be allowed to escape from the iteration they are found in.
The reality of disciplined agile implementations is a significant reduction in defect counts and improved product quality.
Agile “flaw” #2:
“Development over planning” – he maintains that the agile manifesto value statement “we value responding to change over following a plan” is a licence for wholesale unmanaged change. Again this is a misrepresentation of the reality.
The reality of the business environment today is that business needs are volatile. The “half-life” of a business requirement today is approximately 6 months, so if you’ve identified what is needed and it takes 12 months to deliver it then 75% of what was asked for will be wrong, purely because of the passage of time.
The reality of disciplined agile projects is that change is carefully managed, with an underlying philosophy of adapting to the emerging and evolving needs rather than resisting change. Agile is not an excuse to ignore good design principles, nor to allow massive change without doing impact analysis. Agile is about adapting within boundaries, and recognising that when change is so large that it impacts the business value of the project then it needs to be assessed and evaluated, but not resisted.
Again this is not an excuse for ignoring good technical practices. Philippe Kruchten talks about the “architecturally significant non-functional” aspects of a system – these are the elements which will be very expensive to refactor and should be identified and included in the design guidelines from the very beginning of a project. There is nothing in the agile manifesto about not planning the overall structure of the product from the beginning, and certainly none of the respected authors and thought leaders in the space recommend starting to write code “like free form poetry” – any project needs SOME design up front, and in agile projects we resist BIG design up front because we know that the world will change around us.
Agile “flaw” #3:
His final flaw is that agile focuses on “collaboration over management” – “replacing responsible project management with some immature utopian myth of self-organization”.
Again I say: Drivel! Agile encourages self-organising teams, and self-organising teams need good direction, clarity of goals and very importantly good boundaries within which they must work. Researchers Minnick and Ireland identified the characteristics of successful teams and individuals in highly dynamic environments and they talk about the need for “bounded realism” – high performance teams have clear borders and boundaries within which they work. Self-organisation is never an excuse for losing sight of the project’s goals and constraints, in fact it requires of the team that they constantly focus on “solving the right problem” through the iterative feedback cycle of showcases and frequent delivery.
In this interview Johanna Rothman talks about the difference between self-organising, self-directed and self-managing teams. They are not the same thing.
Tragile – not agile
Everything that I read in the CIO article makes me shout “TRAGILE!” or “FRAGILE”.
First, there are the people who don’t walk because they don’t know what walking is. During the structured programming movement, I had countless clients who claimed to be doing structured programming, but when you looked at their actual code, it was spaghetti, spaghettini, spaghettoni, linguini, vermicelli, or fusilli lunghi. Anything you could twist and tangle, they had it–and called it macaroni. In more modern times, I’ve seen dozens programs that claimed to be object-oriented but were merely warmed-over Fortran pudding.
As for agile, the typical words I hear are, “We’re doing agile, but we’ve left out X and Y and Z. They’re not really applicable to us.” At a recent client, I found. X = user involvement; Y = test before design; and Z = pair programming. I’d say it was agile in the sense that “fragile” contains “agile.”
For a discussion about what can happen when an organisation embraces agile, brings in the disciplines and focuses on ALL of the people and quality practices see Jenny Saunders’ and my take on what happened at Livestock Improvement Corporation.