Northern Horizons Software Technology (TSP Methodology)

TSP and PSP Methodology

View the PowerPoint slide presentation, Productive Engineering Teams.

To obtain the Microsoft PowerPoint ^® viewer, click here.

History

In the 1980s, Watts Humphrey guided the development of the Capability Maturity Model for Software (SW-CMM). An early misperception of SW-CMM by some people was that it did not apply to small organizations or projects. In order to illustrate its application to small organizations, Humphrey took on the challenge to apply the SW-CMM to the smallest organization possible: an organization of a single individual. From 1989 to 1993, Humphrey wrote more than 60 programs and more than 25,000 lines of code (LOC). In developing these 60 programs, Humphrey used all of the applicable SW-CMM practices up through Level 5. He concluded that the management principles embodied in the SW-CMM were just as applicable to individual software engineers. The resulting process was the PSP. He subsequently worked on corporate and academic methods to train others to use the PSP technology.

As engineers started applying their PSP skills on the job, it was soon discovered that they needed a supportive environment that recognized and rewarded sound engineering methods. In many organizations, the projects in crisis receive all the attention. Projects and individuals who meet commitments and do not have quality problems often go unnoticed. Humphrey found that if managers do not provide a supportive environment and do not ask for and constructively use PSP data, engineers soon stop using the PSP. Humphrey then developed the Team Software Process to build and sustain effective teams.

What Makes PSP and TSP Work

Typical software projects are often late, over budget, of poor quality, and difficult to track. Engineers often have unrealistic schedules dictated to them and are kept in the dark as to the business objectives and customer needs. They are required to use imposed processes, tools, and standards, and often take shortcuts to meet schedule pressures. Very few teams can consistently be successful in this environment. As software systems get larger and more complex, these problems only get worse. The best projects are an artful balance of conflicting forces. They must consider business needs, technical capability, and customer desires. Slighting any facet can jeopardize the success of the project. To balance these conflicting forces, teams must understand the complete context for their projects. This requires self-directed teams that:

	understand business and product goals
	produce their own plans to address those goals
	make their own commitments
	direct their own projects
	consistently use the methods and processes that they select
	manage quality

Figure 1 illustrates how the PSP and TSP build and maintain self-directed teams. Successful self-directed teams require skilled and capable individual team members. Capable team members are critical because each instruction of a software module is handcrafted by an individual software engineer. The engineer’s skills, discipline, and commitment govern the quality of that module and the schedule on which that module is produced. In turn, the modules come together to compose software products. Therefore, a software product is a team effort The product’s modules are designed, built, integrated, tested, and maintained by a team of software engineers whose skills, discipline, and commitment govern the success of the project.

Figure 1: Elements of the PSP and the TSP

The objective of the PSP is to put software professionals in charge of their work and to make them feel personally responsible for the quality of the products they produce. The objectives of the TSP are to provide a team environment that supports PSP work and to build and maintain a self-directed team. PSP and TSP are powerful methodologies that provide the necessary skills, discipline, and commitment required for successful software projects.

The PSP

The PSP is based on the following planning and quality principles [Humphrey 00]:

	Every engineer is different; to be most effective, engineers must plan their work and they must base their plans on personal data.
	To consistently improve their performance, engineers must measure their work and use their results to improve.
	To produce quality products, engineers must feel personally responsible for the quality of their products. Superior products are not produced by accident; engineers must strive to do quality work.
	It costs less to find and fix defects earlier in a process than later.
	It is more efficient to prevent defects than to find and fix them.
	The right way is always the fastest and cheapest way to do a job.

Today, most software engineers do not plan and track their work, nor do they measure and manage product quality. This is not surprising, since engineers are neither trained in these disciplines nor required to use them. The dilemma is that until they try using disciplined methods, most software engineers do not believe that these methods will work for them. They won’t try these methods without evidence, and they can’t get the evidence without trying the methods. The PSP addresses this dilemma by putting an engineer in a course environment to learn the methods. The engineers use the methods in the course and can see from their personal and class data that the methods can and do work for them. The PSP course is composed of ten programming assignments and five reports. The PSP methods are introduced in six upwardly compatible steps, PSP0 through PSP 2.1 (see Figure 2). The engineers write one or two programs at each step and gather and analyze data on their work. Then they use their data and analyses to improve their work.

Figure 2: The PSP Course

PSP0 and PSP0.1

Engineers write three programming assignments using PSP0 and PSP0.1. The objective is for the engineer to learn how to follow a defined process and to gather basic size, time, and defect data.

PSP1 and PSP1.1

Once engineers have gathered some historical data, the focus moves to estimating and planning. Engineers write three programming assignments using PSP1 and PSP1.1. Engineers learn statistical methods for producing size and resource estimates, and use earned value for schedule planning and tracking.

PSP2 and PSP2.1

Once engineers have control of their plans and commitments, the focus of the course then changes to quality management. Engineers write four programming assignments using PSP2 and PSP2.1. Engineers learn early defect detection and removal methods and improved design practices.

Mid-Term and Final Reports

After the first six assignments have been completed, engineers write mid-term reports, and after all ten programming assignments have been completed, engineers write final reports. These reports document the engineers’ analyses of their performance. Engineers are required to analyze their data to understand their current performance, to define challenging yet realistic goals, and to identify the specific changes that they will make to achieve those goals.

By the end of the course, engineers are able to plan and control their personal work, define processes that best suit them, and consistently produce quality products on time and for planned costs. In 1997, a study was conducted to analyze the impact of PSP training on 298 software engineers [Hayes 97]. This study found that engineers were able to significantly improve their estimating skills and the quality of the software products they produced. Engineers were able to achieve these notable improvements without negatively affecting their productivity. In terms of product quality and schedule variance, individuals were able to perform at a level that one would expect from a SW-CMM Level 5 organization. The 1997 study was recently repeated on a much larger data set of over a thousand software engineers. The larger data set represents a more diverse group of instructors, engineers, programming languages, development environments, etc. The purpose of the replication was to demonstrate the statistically significant improvements in estimating and quality practices, i.e., to answer the question, can engineers learn to use their data to significantly improve their performance? The results from this replication are essentially the same as in the original study.

The TSP Launch

The first step in developing a team is to plan the work, which is done during the TSP launch. The launch is led by a trained and qualified team coach. In a TSP launch, the team reaches a common understanding of the work and the approach they will take, produces a detailed plan to guide the work, and obtains management support for the plan. A TSP launch is composed of nine meetings over a four-day period, as shown in Figure 3.

Figure 3: The TSP Launch

The first step in the launch is for the team to understand what they are being asked to do. This is accomplished in meeting 1 by having marketing (or an appropriate customer representative) and management meet with the team. Marketing describes the product needs. Management describes the business needs and any resources and constraints under which the team will have to work. This is also a chance for management to motivate the team. The team has the opportunity to ask any questions they might have about the product or business needs. In the next seven meetings, the team develops an engineering plan to meet the business needs.

In meeting 2, the team sets its goals and organizes itself. The team reviews the business and product goals presented in meeting 1, and derives a set of measurable team goals. Next, the team also decides which team members will take on which routine team management tasks. These tasks are designated by manager roles:

	customer interface manager
	design manager
	implementation manager
	test manager
	planning manager
	process manager
	support manager
	quality manager

Each team member selects at least one role. For teams with more than eight members, roles are shared. With smaller teams, team members may select multiple roles.

In launch meeting 3, the team determines its overall project strategy. The team members produce a conceptual design, devise the development strategy, define the detailed process they will use, and determine the support tools and facilities they will need. They list the products to be produced.

In meeting 4, the team develops the team plan. This is done by estimating the size of the products to be produced, identifying the general tasks needed to do the work and estimating their effort, defining the tasks for the next development cycle to a detailed work-step level, and drawing up a schedule of the team’s availability week by week through the completion of the project.

In meeting 5, the team defines a plan to meet its quality goals. The team does this by estimating the number of defects injected and removed in each phase and then calculating the defect density of the final product. The team ensures that the tasks needed to achieve its quality goal are included in the team plan. The quality plan provides a measurable basis for tracking the quality of the work as it is done.

In meeting 6, tasks on the team plan for the next cycle of work are allocated to team members, and each team member creates an individual plan. In building their plans, the engineers refine the team estimates using their own historical data, break large tasks into smaller tasks to facilitate tracking, and refine their hours available per week to work on this project. The team meets again to review the individual task plans and to ensure that the work load is balanced. The individual plans are consolidated into a team plan. The team uses this plan to guide and track its work during the ensuing cycle.

The team conducts a risk assessment in meeting 7. Risks are identified and their likelihood and impact are assessed. The team defines mitigation and contingency plans for high-priority risks. Risks are documented in the team plan and assigned to team members for tracking.

Meeting 8 is used to develop a presentation of the team’s plan to management. If the team’s plan does not meet management goals, the team includes alternative plans that come closer to meeting management’s goals. For instance, the team might be able to meet a schedule by adding resources to the team or by reducing the functionality delivered.

By the end of the launch, the team has formed a cohesive unit and created a plan that balances the needs of the business and customer with a feasible technical solution. The team has agreed on the technical solution that they propose to build and understands how that product will satisfy business and customer needs. The team agrees on the strategy and process for developing the product. The team has a detailed plan that it can use to guide and track the work. Team members all know who is responsible for which tasks and areas. Everyone on the team understands and agrees with the quality goal, and the team can monitor progress against that goal. Finally, the team has explored all of the things that might go wrong and has done its best to mitigate those risks. In short, the TSP launch provides a team with all of the conditions necessary to become a self-directed team.

In meeting 9, the team presents the plan to management for their approval to start the work. The team explains the plan, describes how it was produced (Figure 4), and demonstrates that all team members agree with and are committed to the plan. If the team has not met management’s objectives, it presents one or more alternative plans. The principal reason for showing alternative plans is to provide management with options to consider in case the team’s plan does not meet the organization’s business needs.

At the end of the TSP launch, the team and management agree on how the team will proceed with the project. The team has a plan it believes in, is committed to, and can track against. The launch not only creates a winning plan, it builds a cohesive team.

The TSP includes guidance for ensuring that the energy and commitment from a TSP launch are sustained as the team does its work. A TSP coach works with the team and the team leader to help the team to collect and analyze data, follow the process defined by the team, track issues and risks, maintain the plan, track progress against goals (especially the team’s quality goal), and report status to management.

The First Cycle of Development

During the first development cycle, the team meets once a week to review their status, resolve issues, and decide how to proceed. Each role manager reports on how the team is performing according to plan as to its accomplishments, goals and risks. At the conclusion, the meeting recorder and team leader prepare the meeting report for management.

Cycle Post-Mortem and Re-Launch

Meeting 4 of the launch prepared a detailed plan for only the first cycle of the project, typically a one to three month period. When the cycle completes, a post-mortem is held to identify issues, changes in goals or risks, technical concerns, or a change in team membership. A one to three-day re-launch plans the next cycle of the project. Development cycles with their corresponding re-launches and post-mortems continue to project completion.

Material on this page is reproduced from The Team Software Process (TSP) in Practice: A Summary of Recent Results by Noopur Davis and Julia Mullaney, Technical Report CMU/SEI-2003-TR-014, September 2003.