Dedicated team for previous version releases

For software products that have had multiple releases over the years, there is a ticklish question about the resources that need to be dedicated for previous released product versions. This is even more critical for software products that have wide usage such as Microsoft Office, Photoshop, and Acrobat. Organizations have stated policies about providing support for previous versions, but there is a cost associated with doing the same. You need to have people who can do defect resolution and testing, you need people who can do all the entire build infrastructure including releasing the software fix. This can add upto a pretty packet in terms of resources, and this can be painful especially when there are time periods when there are no major fixes that are due.
Deployment in these previous support teams can also lead to tricky morale issues, given that people assigned to these teams would feel that they are put onto a team that is less important than those who are part of the team working on the current features. To avoid such morale issues, team can rotate people across these teams, but that comes with its own problems about people not being able to develop the expertise, something that comes only after gaining experience on the team.
A problem with not having these previous support teams - for some organizations and products, such an option is not possible; a full fledged support team is required. Consider somebody using a previous version of MS Office or Adobe Acrobat, and suddenly, there is news from a computer security researcher about a critical zero day or similar intensity defect in the product which could allow a hacker to get into the hole. These events can be a public relations disaster - such blowback cannot be countered just by Public Relations, but there is a need to have a team that can work on a full scale quick research and fix, such that the organization develops a reputation for responding quickly. And it's just not a fix in a previous version, but the same problem may be there in the ongoing version that is being developed and the team needs to get the research done by the previous version team and incorporate the fix in the version under development.
A lot of teams I know slightly under-budget a team for working on previous version defects, and if the problem requires a slightly enhanced amount of effort, then additional people are deployed for working on the defect fix, and are only there on a temporary basis (even though it might have some amount of impact for the current cycle, but there is no real solution for the same). People assigned to such teams are typically team members who are not very high in ambition, and are not necessarily the high rated people in the team. Further, the Product Management teams need to be involved in both sides, since many of the feedback in terms of defects or suggestions are actually coming from customers or end users and there is a possibility that some of them may have value for the next version to be released.   

Supporting previous versions of the software (Part 5)

In previous posts in this series (Supporting previous versions of the software (Part 4)), we have talked about how an organization makes the decision to remove support for a (much older) previous version of the software. Removing support means that customers are encouraged to move to a higher version, defect fixes are not provided and the support team will not take any more calls on that version. This can get tricky, and sometimes the decision is not all that clear as to whether the support would be withdrawn.
For removing support for a previous version of the software, the groups that typically advocate removing this support are the development and testing teams; the number of previous versions of the software that remain supported in the market, the more effort they need to put in. For example, just as an example, there are a lot of compatibility issues that need to be developed and tested, and these increase as the number of previous versions are supported. Another example would be the support team, since they have to keep a track of issues, defects, notes, and other items for all the previously supported versions. However, when you look at product management and marketing, they have a lot more contact with customers, and they are able to better figure out whether it is possible to drop support or not.
I am going to try to layout some reasons where the team took the call regarding whether to drop support and decided that they cannot drop support as of now. Here are some of the reasons (and this cannot be a comprehensive list, more based on my experience in the industry).
- Too many users complaining about support being withdrawn: This happens when the team informs people through support forums and the helpdesk that they are planning to drop support. If there is significant push back (and discussions with some those protesting reveals that they are really going to be impacted), then the organization may decide to not drop support as of now.
- Previous deals commit support for an extended period of time: This happens typically in the case of OEM's or when there is a large deal. As part of the deal, support was required for 5 years after the launch of a version, and this grew tricky in the years to come. But we were bound by this condition, and the only learning was to be more careful of the implications of providing support for extended periods of time.
- The Product Management / Marketing looks at data, looks at support discussions, user forums and decides that the level of discussion is still fairly high enough that the support needs to remain for some more time.
- Data from metrics reveals that the understanding of the team was incorrect regarding the number of people still using the software and the data reveals more people that are using the software. In this case, it could still mean drop of support along with an offer for those people using the older software to get some concessions when they are upgrading to the latest version.

Read the next version of this series (Supporting previous versions of the software (Part 6))