We’re all familiar with major software releases. Go way back in your time machine and think about the Windows environment. There was Windows 3.0, Windows 95, Windows 98, Windows 2000, Windows XP, Windows Vista, and the upcoming release of Windows 8.
Each of these major releases was designed with new functionality and technology improvements from its predecessors.
A major version release is the next big release of a software product or web application that includes everything in it that everyone has been asking for since the last big release. It’s the solution to all problems and is the mantra that is repeated whenever a question is asked about why the software does not operate a certain way currently.
The answer is a droning on of “9.0…9.0….9.0…” (or whatever the next version is that is on the docket to be released).
This may be all well and good, but there are problems associated with the major release approach of cramming everything into the next release. We’ll discuss some of these challenges along with how a more agile project management method, such as the scrum development, can make releases more iterative, smaller, and more frequent.
The Challenges with Major Releases
There are a number of challenges that exist with this method of software development that follows the path of more rigid development methodologies such as the Waterfall method. Below are a few of these challenges:
Releases are Far Apart from Each Other’
Major releases are typically a long way off from each other. Sure, there may be minor releases along the way (such as 9.1 or 9.05 depending on the size of the release), but these are usually relegated to bug fixes and patches of existing functionality.
The really new and exciting stuff is usually 4 – 6 months out and in this fast paced world of instant gratification that is an eternity. So, this leads to ongoing conversations with clients and end users that what they really want the software to do it at some point in the distant future.
Plus, as the date approaches there is typically some scope creep that has been introduced along the way or functionality that is not working as designed that pushes the date out even further.
Everything Gets Dumped into the Next Release
Ideas will surface during the development of the big release. They are such great ideas and would make such a big difference to the end user that it would be unconscionable to wait for the next major release which could be 8 – 12 months in the future.
These great ideas squeeze their way into a space that is already crowded with functionality. Additionally, there are usually not enough people available to implement the first round of functionality let alone the additional scope that has been introduced. This contributes to part of the reason why there may be the delays mentioned above.
Becomes Larger than Life and Unwieldy to Manage
Now there is a lumbering Goliath of a major release that is walking around the halls of the office. It is taking on a life of its own and starting to push people around as its needs are not being met.
Its needs have expanded to include additional testing, more documentation, and conducting more focus groups to see if the new functionality is easy to understand and use. This requires a lot of ‘handlers’ to steward this monster release to completion and not turn into a monster software release that escapes.
Big Shift in User Interface
A substantial change to the UI is typically associated with a major release. This requires a learning curve on the part of the end user as everyone ramps up with the new interface.
Think back to the navigation changes Microsoft did not so long ago from the Menu based navigation that everyone had known for years to the Ribbon approach that aggregated related functions in one place. We’re used to it now but it certainly did take some time adjusting to the new way of doing things.
Problems are Harder to Identify
Since there are so many people involved in a major release of Herculean proportions, it becomes hard to identify and solve problems. Issues could surface in one area that negatively impacts another area.
For example, a web application may be taking an inordinately long time to load. Nothing changed as far as the code goes, and everyone in the other departments swears that nothing changed either.
“Oh wait…,” the IT department sheepishly says “we did recently make a minor change to the network that may be restricting bandwidth”.
Sure enough, what was thought to have nothing to do with causing the problem ends up being the culprit.
The Benefits of the Scrum Methodology
There has been a shift towards more agile project management methodologies in recent years. This has opened up the door for more iterative releases and closed the window of time between each next major release. The following are some of the advantages of scrum methodology.
- More Frequent Releases: The scrum methodology phases focus on frequent releases with less functionality. Initially, this may come across as being negative. Who would want less functionality? Well, rather than wait 4-6 months for all the functionality to be released at once, the scrum methodology enables releases to be accelerated. In most cases, functionality can be released every 4-6 weeks! The development cycle is actually called a Sprint, which speaks to the abbreviated nature of the scrum methodology.
- Focus on Feature Set, Usability, and Value to the End User: The iterative nature of the scrum methodology lends itself toward a laser sharp focus on features, usability, and value to the end user. Each release must deliver value to the end user. At a certain level, it could be viewed as a phased approach to the major releases. Rather than waiting for everything to be done all at the same time, functionality is released as it comes online.
- Iterative Approach Allows for Changes and Improvements: Agile project management methodologies such as the scrum methodology embrace change. The waterfall method that is so common for major releases is typically resistant to change. There are forms, meetings, approvals, and other controls put in place for the purpose of preventing change with conventional methodologies. The iterative nature of the scrum methodology looks for perpetual feedback and then adjusts the plan and feature sets accordingly.
- Lends itself to SaaS: More applications are moving toward the Software as a Service (SaaS) model. This is where the online application is a living, breathing entity that people subscribe to on an as needed basis. Part of the expectation around the SaaS model is that there will be ongoing changes and improvements to the software. This encourages subscribers to the application to continue to renew month after month. The scrum methodology makes this easy to occur.
The days of waiting 4-6 months between major releases are over. People don’t have that type of patience and there are alternatives to having to wait that long. Even if you don’t adopt the scrum methodology in its entirety, there are certain principles you can use that will allow your projects to move along on the fast track.