Issues with the Iterative Development Model

Question

I am the Product Manager for a software company. We use an iterative development model (similar to Agile) to separate out versions of our software (i.e. 7.3, 7.4, 7.5, etc.) Prior to each version, we make a design plan based on a combination of customer requests and internal features that we draw up based on market research.

While this is definitely a better approach than the waterfall model, it is also presenting some significant challenges.

1. It is committing our development timeline for a long amount of time. Right now if any of our customers make a development request, depending on the priority level, we may not be able to get it to them in a complete and tested version of the software for over a year. This is also affecting our ability to respond to changes in the market. We have added resources, but as we get more and more requests, we are committing more of our time in the future. What is the best way to ensure that our development timeline includes all of the items we are bound to complete for our clients, without overcommiting our future time?
2. If we try to shorten the development timeline and get versions out faster, this invariably leads to more versions that have to be maintained. Finding a bug in 7.3, for example, means that same bug would have to be identified and fixed in 7.4, 7.5, etc. How can we reduce the number of versions when there are more bugs?

In your experience, what are the best solutions to these issues with the iterative development model?

Answer 1

If you have good version control you should be able to cascade the bug fix from version 7.3 through all the releases up to current. There should be little need to figure out how to patch the future releases. If you have good automated test tools you just need to verify that the bug exists in each release, patch, and verify the fix.

For this kind of release I would develop on the trunk, and branch on release. Branch as early as required, and as late as possible. I have seen projects where each release is its own code island. It tends to introduce problems like you are encountering.

I would split work on bugs in prior releases in to a separate maintenance stream. The maintenance stream should have senior developers or you may introduce more bugs than you fix. This group should be able to merge bug fixes into the current release.

As you find bugs, you may want to trace them back to the oldest supported release and fix it in that release. Then move the patch through to the newest release that is broken.

Documenting the cause of the bug (how it got introduced) may be helpful in reducing the rate at which you introduce new problems.

Reducing the number of supported versions would also help. Consider like a maintenance schedule something like:

• Every release is supported until two quarterly releases have been released.
• Quarterly releases are supported for a year.
• Annual releases are supported for two years.

Answer 2

Is it necessary to have that many versions? Is there a way to change to one track? (One track means that you have one main or master branch depending on your version control system and every change goes into that main or master branch, and there are no versions)

If it is not necessary, then I suggest to forget about the versions and iteratively deliver into that one track (branch). With this approach you can reduce the cycle time in your organization, but still do iterative development.

If it is necessary, then try to find a way not to have them. Maintaining multiple versions is a huge overhead and the effort spent on maintaining branches and versions can be spent on new features. Try to find a way to talk the customer out of the usage of different version. If it is internally, then find out why was it introduced in the first place, and make it disappear. Or, you can have one track and tag them with the latest version number, but don't branch out.

In my experience 90% of the customers are fine with one track. The remaining 10% lost the trust and decided not to take new patches because of this. But, this is a different situation.

Answer 3

Reduce scope, integrate testing into the release cycle (e.g. it's not done until it is tested and fixed) and release more often.

Answer 4

To make an iterative cycle work well, you need to:

1. Increase the frequency of releases, and
2. Always be moving forward

The idea is that:

1. Customers won't have to wait long for problems to be fixed
2. Customers can be confident that newer version will be better than old ones

It's fine to let a customer stay with an older version, but it's unproductive to have them expect that it will be maintained or patched for a long time.

Also, to prevent upsetting your mainstream customers, build a group of "power users" that get new version before everyone else, and help weed out the major problems.

Answer 5

On point 1

Your demand is outstripping supply causing a backlog of work that will trend to infinity. It's hard to give specific advice to help fix that but I'd start with:

Measure how often new feature/change requests are raised. How often a bug is raised on an in production version. Pay attention to levels of value demand (new things customers want that will encourage new business or increase spend) and failure demand (those requests caused by a failure on your part (e.g. bugs)

Once you properly understand where demand comes from and how often, look to match your supply side to the demand by removing failure demand and sequencing work to match value demand.

For more info, check out queuing theory. There's a lot of material out there but I particularly recommend picking up 'Managing the Design Factory' by Don Reinertsen which has a really good section on queues (as well as being a generally awesome book).