I have the privilege of working closely with a number of our software vendors to help them improve their products both for our use and for their entire client base. As I have worked with them, I’ve discovered that there are some amazing correlations between software development processes and business development processes. Those similarities have changed the way I look at development, in many areas.

In this post, I am going to talk through a bit of the history of the two primary development processes and some of their pros and cons. In part 2, I will talk through how we have seen these different processes exhibit in business.

Let’s start with a little history. In the past and somewhat still in the present, software was developed using what is called a waterfall process. On the receiving side, this was seen as software being released every year, every 3 years or something like that. The developer would start by drafting a list of changes, scoping those out and putting them on a road map. From there, they would work on developing the different changes. As the release date of the software drew closer, pressure would mount to get the changes ready for release. Sometimes, this meant releasing something that wasn’t ready, sometimes, this meant delaying a release and, sometimes, this meant the change missed the release and wouldn’t be released until the next release in 1 or 3 years or so. One of the main drivers for this approach was that each release took a significant amount of effort to package and distribute it along with providing support to clients installing the updates.

As Internet connectivity has improved, along with it has come cloud environments. One of the advantages of cloud environments (there are disadvantages as well) is that the developer doesn’t usually have to worry about thousands of deployed environments for their software. They usually only have to worry about 1 or 2 environments. Additionally, the developer usually exercises complete control over the environment, a freedom they don’t have when the software is deployed at a client’s site, on a client’s network, on a client’s servers.

While the cloud isn’t the only thing that started this, the cloud created a much more feasible environment for a different development process called agile. While there are many variants of agile development, at its core, it is exactly what it says it is…agile.

Agile software development takes proposed changes and chunks them up into bite-sized pieces. From there, you focus a team on developing that piece, testing it and deploying it in what is often called a sprint. Depending on the complexity of the change, this usually happens in days, weeks and months instead of the waterfall’s timeline of months and years.

In the waterfall process, much care is usually given to make sure that any change is done right from the get-go as it is going to be a matter of years before it could be changed again. In the agile process, changes that didn’t hit the mark can, usually, be rapidly changed. This allows a level of freedom to agile developers to rapidly innovate and deploy new features and functions to end users. Because the changes in agile development are usually smaller, the bugs tend to be smaller and easier to find and fix. Even if bugs get through, because patches can be rapidly deployed, agile development allows for faster recovery from failures as well.

As with anything, there are pros and cons to each method. Waterfall development still has its legitimate place, especially for more significant changes that have far reaching impacts and justify the time investment to more fully vet them out. Agile development provides for more rapid innovation that gets new features into production faster and allows you to rapidly iterate on those features but it also results in more interruption to the end user as the product is constantly changing.

Join us in our next post as we tie these software development concepts into business development and talk about the pros and cons of using them in your business.