The managers of the team looking at reviewing processes before the start of every project / product cycle

One of the most critical factors in making a project cycle successful is the processes that are used by the team. What do processes do ? Processes define what the team is supposed to do in different circumstances, whether this be part of the regular routine work of the company, or whether this be involved with exceptional circumstances. Some of the most critical and regular processes that a team deals with and which define whether the team will be successful or not are:
- The process used by the team members for the design phase (whether this be the high level design or the low level design)
- Processes during the coding phase (code re-use, code marking and modification processes (such as commenting with the code, etc), code review process, etc)
- Processes used during the testing phase (process of filing a defect, determining whether the defect has indeed been fixed and can be closed, etc)
Like these, there are numerous processes that are used during the development project, and they play a critical role in ensuring that the work gets done efficiently, and at the same time, as desired. A team may be using processes that have evolved after a lot of experience, or could have been designed by a small set of people (for example, when we wanted to incorporate a component from a new third party vendor, we had to define a process for testing, defect logging and communication with the vendor that worked for the vendor and for us, else things can go real haywire).
When the team is doing one release after another, the processes that they are following are typically those used in the previous release project, and since people are used to these processes, it is pretty easy to follow these processes. However, it is important that the management of the team spend some time in collecting information about how well these existing processes have worked, whether there is a need of modification of some of these processes, and whether some new processes need to be added.
One of the prime examples of collecting such information is the post-mortem meeting. One of the discussion points can be the processes being used in the team, and whether the team feels that there needs to be some modifications in the process being followed, or whether there needs to be any new processes to be created (and such a discussion cannot just start in the post-mortem meeting, but the team needs to be informed that the topic of the new processes will come up in the post-mortem meeting, and that gives them more time to bring the points for the meeting; in fact, the team managers should think through some seed points for such a discussion and include this in the earlier communication, and that will encourage the team to think through this in even more detail).
But this cannot be just restricted to one meeting. If required, specific agenda groups within the team need to be formed to explore some of these processes (for example, every cycle we set up a team to discuss improvements in the coding processes, including the code review process to see what are some of the improvements that are possible and whether some of the processes are no longer applicable and need to be dropped).
The managers can also play a critical role in such a discussion. Each manager can hold a similar discussion within their teams and figure out what are some of the improvements or changes that the team is looking for. When there are processes involved with the external teams, it is important to do a discussion with the external teams to figure out tweaks with such processes as well. There is not a single step to modify such processes, it can be incremental, taking several weeks or even months, but there has to be clarity that initiating such a process of review needs to happen.

The Team Software Process Team working Process

One should make ensure that the team members of team software process team follow the TSP plan.It includes:
- Leading the Team
- Process Discipline
- Issue Tracking
The team leader is responsible for leading and guiding the team which includes the day-to-day direction of the work, protecting team resources, resolving team issues, conducting team meetings, and reporting on the work.
During process discipline, the team leader ensures that the engineers do the job the way they had planned to do it. In monitoring process discipline, the team leader should check that every team member records his or her process data, reports on weekly status, and produces quality products.
Another responsibility is issue tracking which ensures that all of the issues that the team.

- Communication
- Management Reporting
Communication is a key part of maintaining the team’s energy and drive and facilitating communication is a key part of the team leader’s responsibilities. The team leader is responsible for maintaining open and effective team communication.
Management should be informed about team status and performance on a regular basis.

- Maintaining the Plan
- Estimating Project Completion
Maintaining the plan is very important once the teams have completed the project launch and started on the job, the plan guides the work. It also provides a benchmark for measuring progress as well as means to identify problems that might threaten the project schedule.
TSP teams track progress against the plan every week using a method called earned value. With earned value, each task is assigned a value based on the percentage of
the total project estimate that is required for that task.

- Re-balancing Team Workload
- Relaunching the Project
Unbalanced workload can cause a team to be inefficient. Causes include normal fluctuation in engineering performance. Also, the most experienced engineers are generally involved in much more of the work than the team members with less experience.
Whenever teams find that the plan no longer helps them to do their jobs, they should relaunch their projects. Teams should also be relaunched when there are major changes in the work to be done or in team membership.

- TSP Quality Management
TSP shows how to manage quality, teams must establish quality measures, set quality goals, establish plans to meet these goals, measure progress against the plans, and take remedial action when the goals are not met.

Team Software Process (TSP) - TSP Quality Management

Team Software Process (TSP) shows teams how to manage quality, teams must establish quality measures, set quality goals, establish plans to meet these goals, measure progress against the plans, and take remedial action when the goals are not met.

ELEMENTS OF TSP QUALITY MANAGEMENT

- Preparing a quality plan.
- Identifying quality problems.
- Finding and preventing quality problems.

PREPARING A QUALITY PLAN
TSP make a quality plan based on the estimated size of the product and historical data on defect injection rates, they estimate how many defects they will inject in each phase. Once the engineers have estimated the defects to be injected, they estimate defect removal,again using historical data or the TSP quality guidelines which are based on the yield for each defect removal phase. Once the injection and
removal estimates have been made, the team can generate the quality plan.

IDENTIFYING QUALITY PROBLEMS
TSP provides many quality measures one of them being is by comparing the data for any module or component with the quality plan. TSP introduces a series of quality measures like: Process quality index—PQI.
- Percent defect free—PDF: Comparing the PDF curves for several similar projects. Where there are problems, the quality manager can look at data on lower level components to identify the source of the problem and recommend what the team should do about it. PDF plot can only be produced for an overall system or large component.
- Defect-removal profile: The defect-removal profile can be drawn for the system, each of its subsystems, any component, or even down to the module level.
- Quality Profile: The quality profile measures the process data for a module against the organization’s quality standards. The five quality profile dimensions indicate module quality based on data for design, design reviews, code reviews, compile defects, and unit test defects.
- Process quality index—PQI: is produced by taking the product of the five dimensional values of the quality profile to produce a single quality figure of merit. With PQI values above about 0.4, program modules are generally defect free.

FINDING AND PREVENTING QUALITY PROBLEMS
The TSP quality measures can indicate likely quality problems even before the first compile. Once the problems are identified, they can be prevented by:
- Monitor the module during test to see if problems are found and then determine the remedial action.
- Reinspect the module before integration or system test.
- Rework on the module to fix suspected problems.
- Redevelop the module.

Team Software Process (TSP) - Framework Activities and Phases

Team Software Process (TSP) scripts define elements of the team process and the following framework activities:

- LAUNCH
It reviews course objectives and describes the TSPi structure and content. It assigns teams and roles to students and describes the customer needs statement. It also establishes team and individual goals.
- STRATEGY
It creates a conceptual design for the product and establishes the development strategy and decide what will be produced in each cycle. Strategy makes initial size and effort estimates and establish a configuration management plan, reuse plan and risk management.
- PLAN
It estimates the size of each artifact to be developed. Planning also identifies tasks to be performed, estimates time to complete each task;, assign tasks to team members, make a weekly schedule for task completion and make a quality plan.
- REQUIREMENTS
Requirements analyze need statements and interview the customers, specify and inspect the requirements and develop a system test plan.
- DESIGN
It creates a high-level design, specify the design, inspect the design, develop an integration test plan.
- IMPLEMENT
Implementation uses the PSP to implement modules/units, creates detailed design of modules/units, reviews the design, translates the design to code, review the code,
compile and test the modules/units and analyze the quality of the modules/units.
- TEST
Testing builds and integrate the system. It conducts a system test and produce user documentation.
- POSTMORTEM
It conducts a postmortem analysis, writes a cycle report and produce peer and team evaluations.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their work. Scripts defines specific process activities and other more detailed work functions that are part of the team process.
TSP recognizes that the best software teams are self directed. Team members set project objectives, adapt the process to meet their needs, have control over schedule, and through measurement and analysis of the metrics collected, work continually to improve team's approach to software engineering.

Team Software Process (TSP) - Strategy and Objectives

The goal of Team Software Process (TSP) is to build a self directed project team that organizes itself to produce high quality software. The objectives of TSP are:
- The TSP is intended to improve the levels of quality and productivity of a team's software development project.
- Using TSP, organizations establish a mature and disciplined engineering practice that produces secure, reliable software in less time and at lower costs.
- Accelerate software process improvement by making CMM level 5 behavior normal and expected.
- Show managers how to coach and motivate their teams and how to help them to sustain peak performance.
- Build self directed teams that plan and track their work, establish goals, and own their processes and plans. To form a self directed team, you must collaborate well internally and communicate well externally.

A self directed team should do the following:
- understand overall goals and objectives.
- defines roles and responsibilities for each team member.
- tracks quantitative project data.
- identifies a team process appropriate for project.
- implementing strategy for the process.
- defines local standards.
- assess risk and reacts to it.
- tracks, reports and manages project status.

TEAM SOFTWARE PROCESS (TSP) STRATEGY

- Provide a simple process framework based on the PSP.
- Use modest, well-defined problems.
- Develop products in several cycles.
- Establish standard measures for quality and performance.
- Provide detailed role definitions.
- Use role and team evaluations.
- Require process discipline.
- Provide guidance on teamwork problems.