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.   

Customer interaction - Ensuring that solutions to problems are put out frequently on the product page

Just selling a product is not enough. Unless a company is in a very niche area where there are very competitors, customers should be seen from the long term. There have been some good products that have failed because of inadequate attention being paid to ensuring that the customers are happy and satisfied. Every product will have defects (if somebody is claiming that there product does not have any defects, you can be confident that they are lying), the way forward is to ensure that you have the right strategy in dealing with such defects.
There are many defects that have a workaround. So, for example, a customer may be running into a problem with a specific workflow using a set of steps, and there is a certain defect in either the process of the workflow, or in the information generated at the end of the workflow. Now, there are certain customers for whom this workflow is not important enough, or was something that they tried only a few times, and did not try again, or that they feel that they will not try. There could be other customers for whom the workflow is very important, and they do not feel right about this workflow not working.
Along with the different impact of such a defect to customers, there are also differences with the way that the customers raise such issues. There are customers who will actually raise such complaints to the customer service team of the product, who will search for this issue and look for any solutions posted by the company or by other users, and will visit user forums seeing whether other users are also getting such solutions and whether the company has posted anything with regard to such solutions.
In earlier posts, I have mentioned how the company should be monitoring the user forums, looking at customer complaints and the like, so that they know whether their customers are facing issues, and so on. And it is not just looking for such complaints or issues, but reaching out to people who have reported such issues. This reach out gives customers a great feeling that the product is supported by people who are responsive to customer issues, and this increases their attachment to the product.
There is another higher level in terms of responding to customers. If the team reaches a point where they feel that the case is critical, or where a number of customers are reporting the same issue, the team should consider investigating the issue such that some kind of solution is available. This might mean interacting with customers to get more information about the problem, and then putting in the best possible effort to solve the problem and figure out a solution. This solution could be in the form of a small patch that is posted on the product site along with an article that details how to use the patch; it could be in the form of some steps that prevents the product from getting into a state where the defect occurs (for example, we once had a case where we could edit a specific registry entry and an application crash was prevented), or it could be in any other form.
The point to all this was to figure out that there was a problem that needed the attention of the product team (often this would be flagged by the customer support team, since they kept a track of what issues were becoming critical; but this could be seen by looking at items / complaints getting posted by users on other online forums), investigate the issue and figure out a solution. Once the solution was available, then the next step would be post an article that detailed the issue, and then list the steps needed to solve the issue. The advantage of posting these on a site was that the post would also bet picked up by search engines and when a user ran across the issue and did a search, they would quickly find the solution.

What are different scrum controls?

It happens in some of the cases that the whole scrum process comes on the verge of the collapsing! In such cases it is required that the management controls stay in order, undisturbed and firm all the times. 

There are many scrum controls; however the risk assessment continues to be the most valuable one with its impacts as well.

What are different Scrum Controls?

The below mentioned are the effective scrum controls:

1. Issues: 

Issues can be thought of as the obstacles that do not pose any major risk, defect or bug but cannot be considered to be a positive aspect for the software project.

2. Risk assessment: 

This is the most influential scrum control also as it influences the other scrum controls quite much. The success of the project depends largely up on this scrum control as well its impacts.

3. Packets: 

These are product elements pending for the modification in order to facilitate the implementation of the product backlog items in to the working software that is to be released at the end of the sprint.

4. Backlog: 

This backlog consists of all the details of the bugs, defects and the requests of the customers that could not be implemented in the current release and have to be incorporated in to the next release. In addition to all these, the backlogs also consist of the technology and functionality upgrades.

5. Solutions: 

These are the scrum controls occurring between the risks, problems and changes.

6. Release and Enhancement: 

After the risk assessment, this is the second most valuable scrum control for the entire development cycle. This scrum control at any point of time represents a viable release based up on the requirement variables.

How does these scrum controls help?

- Most of the above mentioned scrum controls are employed for the management of the product backlogs and the sprint backlogs. 

- These scrum controls are used for the following purposes:

1. Managing issues
2. Obtaining better solutions

- Even these controls are reviewed from time to time and modified or reconciled if and whenever required during the sprint planning meetings. 

- These scrum controls help control chaos that occurs during the development process. 

- All the above mentioned scrum controls play a great role in the following stages of the scrum:

1. Defined processes
2. Project cost
3. Final product
4. Responsiveness to the environment
5. Completion date
6. Knowledge transfer
7. Team flexibility creativity
8. Probability of success

Scrum, we can say is an enhanced version of the iterative and incremental object oriented development cycle. 

The software releases in a scrum are planned according to the below mentioned variables:

1. Time pressure: Time frame required to make most of the competitive advantage.
2. Quality
3. Resource: It includes staff availability and funds.
4. Vision (system vision)
5. Competition: What is required to gain the competitive edge?
6. Customer requirements: How the current system can be enhanced?

All the above mentioned can be modified according to the development plan during the project. But any processes carried out further should take these changed variables in to account. A system that requires a complicate and complex development process require appropriate control and maximum and efficient control.

What are different software development problems and what are its solutions?

Today‘s world is growing up in the age of software. The whole world revolves around the computers and the computing is all possible because of effective softwares. The quality of the software systems and applications that we use depends largely up on the quality and efficiency of the software development process.

For producing the quality and efficient softwares, a sound software development process is required. But, today as the technology is advancing, so are the problems associated with it.

In this article we are going to throw some light on the problems that come in the way of software development and also we shall seek some solutions for them.

DIFFERENT SOFTWARE DEVELOPMENT PROBLEMS

- There is a lack of skill in the IT sector and the available expertise is focused more up on the core competencies which include outsource functions that are distasteful and complex though still being important.

- The local software development relates to the global software development.

- A good cooperation is needed among the intra- organizational companies.

- There is a great need of effective outsourcing which includes the availability of global data centres, IT infrastructure and embedded softwares, software applications and maintenance applications.

- Apart from all these there is a big requirement for better application service providers or ASPs.

There are several other problems associated with the software development:

1. Communication Problems
- In today’s world the development of software is not concentrated over a region or area, engineers and experts from all over the world contribute in this.
- Formal communication is needed during the routine, inspections and for formal specifications whereas informal communication is required to describe the informally captured requirements.
- Problems like following occur:
(a) Distinct backgrounds
(b) Time zone difference
(c) Lack of information communication
(d) Distinct backgrounds
(e) Distance

2. Strategic Problems
A lot of problems are faced while designing a strategy for the software development like:
(a) When to start development?
(b) Which task is to be allotted to whom?
(c) How to manage risk at both organizational level and project level.

3. Complexity in Coordination
The members of the software development team often find it difficult to cooperate with each other.

4. Issues related to Diverse Cultures
- Team members are from different cultural backgrounds and this has an affect on their performance, individualism, and attitude towards the work.

- Emotions and attitude towards race, religion and class etc add to these problems.

- The team members should be smart enough to understand each other’s culture and learn to compromise and respect the cultures of each other.

- Some of the measures to overcome cultural issues include reducing the intense collaboration among the team members, reducing the cultural distance by cultural liaison and personnel exchange etc.

5. Physical or Geographical Dispersion
Geographical dispersion of the team members as well as resources which results in an uneven distribution of the vendor support, access to expertise and cause a hindrance in the use of software development practices which need a face to face interaction.

6. Technical Problems
Sharing of the artifact as well as information about the development plan and software becomes quite a difficult job.

7. Management of Knowledge
This is a consequence of lack of communication or poor communication among the team members, lack of proper documentation, repositories and so on.

8. Availability of Open Source Software
- Open source softwares that facilitate the exchange of information and artifact among the developers and provide means for the modification of the code should be made available to all involved in the development process.

- Such open source softwares help in unifying the distributed development process.