Debunking Common Agile Myths

Agile has plenty of myths surrounding its practice. It does not help that some of the biggest myth makers in the profession are the very people promoting the spread and adoption of Agile. For those of us in the business community who get our hands dirty, we spend an inordinate amount of time dispelling these myths. It is so common that if I received a dollar for each myth I have debunked over the years, I could comfortably retire somewhere in the Caribbean. Today, I want to tackle some of the common misconceptions surrounding Agile.

Myth #1 – Deadlines do not matter.

Deadlines are serious in the business community. A late release date could mean millions of dollars in fines from a regulatory agency. A competitor could obtain a dominant market share with a new feature. Finally, the project team exhausted their funds, leaving the final phase of the work unfinished. Many people unfamiliar with Agile believe that its iterative cycles render deadlines irrelevant.

Deadlines are more important in Agile. The detailed time boxes enable the gauging of progress and determining if the amount of work is realistic for the time allowed. So, when a developer says they are Agile and that deadlines do not matter, ask them when the last time they shipped something. If they cannot remember, they are not Agile. They are not good developers.

Myth #2 – Agile does not work with legacy systems.

One day, while browsing the Mastodon social network, I came across a humorous comparison between the construction of a city and the current state of corporate software. The poster said that most cities are created without a plan, atop ruins, and no one understands what is happening until the sewers back up.

It feels impossible to adopt contemporary software development practices for outdated AS/400 systems, which are older than the junior developers, and a workforce is still using fax machines. The truth is that Agile allows us to slowly sift through the ruins of your company infrastructure and learn how it operates. The small iterative cycles will enable you to test new technologies and see how they integrate with current systems.

Although it may not be a glamorous process, it will yield results and generate a significant return on investment.

Myth #3 – When we prioritize speed, we sacrifice quality.

No, it is not. Quality is central to all flavors of Agile. Before the team creates a single line of code, they agree on what is called a definition of done. The team uses the definition of done to ensure that everything is thoroughly tested before release.

If you are genuinely working in an agile organization, testers are working shoulder to shoulder with developers to ensure that everything is working as expected. A partnership like this reduces defects and increases speed, which is what you want to see from your development team.

Myth #4 – Agile is just a fad.

The manifesto has existed for over twenty years, and millions of people have earned some kind of professional credentials as a Scrum Master or Product Owner. Today, most development shops practice agile methods, and the Project Management Institute has recognized the importance of Agile. It is not going away, and as a businessperson, you must learn to embrace this work approach.

That is all this week. I have busted four musts and I look forward to sharing more wit and wisdom about Agile, Project Management, and business leadership in the coming weeks.

Until next time.