What’s Wrong with Agile?
Nothing, in theory. Negligence, in practice. Read on to find out how I came to this staggering result.
I remember the times when Rational Unified Process (RUP) has been published by Rational Software, some time in the nineties. And I was among those with eyes agleam who could hardly wait for getting a chance to comprehend try it. A few years later it became obvious for the most of us that RUP is not exactly what we were longing for that much. Out of the many explanatory comments on RUP, I preferred the one explaining RUP is actually most of a methodology framework. It was way too complex, while it gave way too few specifics as to how to exactly conduct software development in practice. So if you wanted to use something tagged RUP, first you had to select which processes, steps, artifacts and other resources and assets to use, with no clear guidance. It was rumored that very large enterprises successfully implemented it, but I was not fortunate enough to see it in practice. So the hype went a bit down.
But then, in the first years of the new century, another term gained the title of being the top buzzword of its time: agile. With many concepts and versions, agile methodologies were common in mitigating the management and documentation overhead, therefore making the development teams more flexible to handle changes. Revolutionary times there had been, people dropped in more and more kinds of diagrams, documents, steps, while they ended up in something we know as agile nowadays.
That materialized practice, however, is a razor-edge. Agile, in my interpretation, puts more analysis tasks to architects and more design tasks to coding guys than optimal. I do believe you can stay agile in the sense of being flexible and efficient by not giving up accurate definition of customer goals and requirements. Nor have you to forget about conceptual level domain models! But in most of the agile projects I have some view of, agile is interpreted by the vendors as they only have to sell an architect and a few coders. And agile is interpreted by PMs as not any kind of formal analysis is needed, and no money should be spent for preparing testing or developing documentation. I think many times wrong people are in wrong roles. A software developer need not be excited to get an opportunity to conduct some formal requirements analysis, they studied programming, they are paid for programming and what they love is programming. Architects like putting pieces together, but they are many times not particularly interested in what for the puzzle is assembled.
To my experience, today’s agile environments require people to play unfamiliar roles which they can not or do not want to play, and the result of an agile development is a piece of software code with no clear requirements, no documentation at a level to be able to hand over the development to another party, and with no chance to test thoroughly, since the lack of requirements.
(Cover strip by Dilbert)