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”?

Let’s be very careful before we decide to adopt these practices.

Let’s look at another principle from the Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Really? The most efficient and effective? My experience managing projects over the years suggests the exact opposite. I have been cautioning project managers against the negative impact of these undocumented verbal communications. Many decisions, clarifications, explanations, adjustments, and even scope changes and requirement changes happen during verbal communications that are not documented anywhere. I am all for maximum collaborations between all members of the project team, but not fact-to-face and not verbal. These are all known to be main reasons for project failures.

Let me make it clear: All communications between team members, agile or not, must be documented.

We have suffered for more than two decades from the effect of misunderstanding and misusing RAD since it was known in the late 1980s. Now, we probably have another two or three more decades to suffer from the effect of sloppy practices in some agile projects. I strongly believe that revision of the original Manifesto is overdue. After all, if we do not learn from our experience to improve and revise our thoughts, we can never move forward.

Magdy Hanna is founder and CEO of the International Institute for Software Testing, and of Rommana Software.