It has now been more than 13 years since a group of 17 renowned professionals published what is called the Manifesto for Agile Software Development. I have been repeatedly asked to provide my viewpoint about agile practices in general, and more specifically about the Agile Manifesto. So, I am providing this analytical review, which is actually overdue.
Few would dispute that we always need to improve the way we build software as suggested in the Manifesto. However, I must admit that when I first read the first four beliefs that these great individuals wrote down, I had my doubts. I felt that the software engineering discipline was being attacked and destroyed. No doubt that all 17 individuals are great software engineers, and I have all respect for them. We have known for many years the major causes of failure in software projects, and I continually cautioned against the possibility of misunderstanding and using the manifesto as an excuse for doing a sloppy job.
(Related: How to get management to go along with agile)
Recently, I was asked in an interview whether I believed that the Agile Manifesto is a good starting point for people who are new to agile. I found myself saying that I hope our young software engineers do not see the Manifesto! If it were within my authority, I would have prevented those who are new to agile from reading it. Only after your children learn all the right things, you can let them try other things, and you know they would not hurt themselves.
I was attending a conference in the late 1980s where James Martin of the U.K. made his first presentation about RAD (Rapid Application Development). Everyone thought it was a great thing, and maybe it was, but it was also misused by software professionals at all levels, and it ended up with a proliferation of systems that have no documentation and are totally unmaintainable.
Now let me get more specific while maintaining my full respect to those who wrote the Manifesto. We all agree that the Manifesto has great ideas that can improve the way we develop software. However, when a document that is labeled as a “manifesto” dictates rules such as “We value individuals and interactions over processes and tools,” “Working software over comprehensive documentation,” and “Responding to change over following a plan,” that is dangerous, and could even be damaging to the software engineering discipline and to the agile approach as well.
This is exactly what has given management the excuse to push releases to production even with minimal documentation, minimal levels of discipline, and no repeatable processes being followed. Having managed software projects for many years, for both development and testing aspects, I do not see how anyone could possibly imagine that we can maintain large, complex software systems over the years with little documentation.
I have been asked to manage testing for a project where the system functionality was documented in more than a 10-page document and a set of screen designs. What kind of testing can you do with these? How could we ever meet any deadline if we “Value responding to change over following a plan”? How could we possibly repeat success—if we ever have any success with agile—when we did not follow a repeatable processes? How would we answer to Dr. W. Edward Deming when he says, “If you can’t describe what you are doing as a process, you don’t know what you are doing”?