When talking about Agile development, people often ask me, “but why would I want to change to a new methodology when traditional development has made so much money and created so much value for so many people for such a long time? Why mess with success?” That’s a great question!
After hearing that question for the umpteenth time I finally realized something. It isn’t traditional software development that has provided so much value! It is the software itself. Imagine calling a travel service prior to the advent of software. You call them up and say “I’d like 100 or so options for travelling from Boston to San Jose. I’ll also need a bunch of 3 or 4 star hotels in San Jose and mid-sized rental cars to choose from. Could I get that in 5 seconds please?”
In today’s world, of course you just go to a site like Orbitz. It isn’t traditional software that provides that value, it is the software itself. It almost doesn’t matter what process you use to produce that software, the value is so high. When you are only competing against somebody that doesn’t have software, that’s one thing. When you are competing against other organizations that are also using software, then the exact process you use can make a big difference from a competitive standpoint.
What do we mean by “traditional development?” After having been involved in the process of literally thousands of software development organizations, I can safely say that there isn’t really any such thing as “traditional development” or even “waterfall.” That is, if you look at any two organizations developing software, there is no standard for what comprises traditional development.
In the end, organizations adopt individual practices that make sense for their circumstances. This same approach can be used when adopting “Agile.” There really isn’t any such thing as “Agile.” It is a combination of values and practices which can be adopted by any organization and does not require wholesale adoption in order to provide value. Yes, there are packaged solutions out there such as Scrum, XP, Kanban and others, and they do provide value. But so do the individual practices. So, instead of thinking about “how do I switch to this new thing,” consider Agile as a new set of tools that you can add to your existing process on a case by case basis. Worry about “being Agile” after you’ve gotten some experience under your belt with some of the practices.
