I recently received this question about the Agile method of developing software and thought I’d share it and my answer.

Q. I am doing some research on agile methods, and wanted to know what you think about the use and application of agile methods? Will they continue to be used more in the next decade in internet software development? And what agile methods do you use?

A. Many startups have been using a more “agile” project management methodology without really knowing it. It’s the formalness of the “official” Agile and Scrum practices that are gaining in adoption now. As to if that official set of rules will stay around for a long time it’s impossible to predict, but judging from history, I think certain exact sets of guidelines come and go in popularity. The principles behind what is considered Agile however, I believe will last a long time. Many of us have seen the failure of planning out year long projects, holding daily hours long meetings to discuss statuses, and building 100 page analysis documents before anything is ever built.

Small, lean, flexible teams, working on shorter production cycles will always produce better software than rigid, bloated teams working on long drawn out project timelines. But most teams will do so without ever getting certified as a Scrum master or some official title for following some group’s rules as to how to manage a project. They do it because they observe the failures of the opposite through experience, particularly if they ever worked in a large corporation and had to follow the time wasting mess of project management that typically emanates from such places.

For me, following rules for how a project should go is not agile enough in itself. Guidelines are great, and I recommend understanding the Agile method so you can learn from it’s principles, but true agility comes from fitting the process to the specific team and project at hand. So I recommend never becoming allegiant to a certain methodology of project management, nor even to a certain development process. Use them as guidelines, but adapt them to your specifics and let them grow with you as you learn and experience more. Ensure the team shares in the understanding of why the agile process is better versus things like the water fall approach. Once they do, wether you stick to the Agile Manifesto or not will not be the significant deciding factor in the efficiency of your software development. It’s the underlying principles that matter, and those I believe will be with us for a long time.