Improving Software Team Performance with TSP

Team Software Process (TSP) Add comments

Experience from Financial Systems
By Bill Nichols,
Senior Member of the Technical Staff
Software Engineering Process Management

Bill Nichols In his book Drive, Daniel Pink writes that knowledge workers want autonomy, purpose, and mastery in their work. A big problem with any change in processes is getting the people who do the work to change how they work. Too often, people are told what to do instead of being given the information, autonomy, and authority to analyze and adopt the new methods for themselves.  This posting—the first in a two-part series—describes a case study that shows how Team Software Process (TSP) principles allowed developers at a large bank to address challenges, improve their productivity, and thrive in an agile environment.

In 2009, Nedbank, one of the four largest banks in South Africa, launched a TSP pilot program in collaboration with the Johannesburg Centre for Software Engineering (JCSE) at the University of Witwatersrand and the SEI. After TSP pilot teams at Nedbank were given a toolkit—including training on how to measure, analyze, and communicate—their behaviors changed.  Not only were the developers (a mixed team of elite and average programmers) able to work more autonomously, they implemented methods that resulted in higher quality work in less time.

The Nedbank TSP pilot involved two software-intensive projects: one maintenance project and one new development project. Nedbank had faced software process improvement challenges in the past. They therefore sought to address the issues of quality and productivity among their software engineering teams by implementing a methodology that would improve the teams' performance through planning, tracking their work, establishing goals, and providing teams with the tools to take responsibility for their processes and plans.

Engage the Team

The Nedbank TSP pilots began with separate training for everyone involved: senior managers, team leads, software developers, and non-developer team members.  The groups learned how the process change would affect them and their relationship with others in the organization. They learned that working on a TSP project required them to behave differently in terms of reporting, data collection, expectations regarding other team members, and interactions with other team members. Developers learned the Personal Software Process with a focus on software engineering discipline, measurement, and planning. Non-developers, such as testers, business analysts, and documenters, learned to work within the new team and project structure. Throughout the courses, Nedbank team members learned what a measured software process looks like and how to measure the software process. They also learned to communicate with a focus on the data, project, and work, not on personal issues.

Launch the Project

TSP projects begin with a structured launch to plan the work, including nine meetings plus a post-mortem meeting to satisfy specific project planning needs. The Nedbank teams began by understanding project goals from a management standpoint and then identified supporting team goals and personal objectives for each participant. These goals helped frame their subsequent decisions on strategy, process, support, and work breakdown.

The project was then broken down into small pieces, and work was assigned among team members. Each member was then able to commit to the plan and his or her specific interim goals, and understand how those goals support the organization's larger goals for the project. The key to success was that the team had the autonomy to plan and manage the work and determine how it would be done. For example, early in the planning phase, the team working on the maintenance project realized that the schedules of the designers and the developers were not aligned. The designs wouldn't be ready when the developers needed them. Working together, the team approached the schedule problems in the following two ways:

  • The team lead went to management and negotiated priorities, using his team's progress data to support the schedule needs. The team lead was then able to convince the designers to prioritize their work so that they could supply the developers with the designs needed to proceed. The senior developers next took the load off the designers by taking on some of the design work.
  • In addition, the team identified modules that would not have to be changed as well as sets of programs that would be easy to update. This change in approach not only helped meet project needs, but also helped satisfy the management goal that teams gain a big picture view of the project.

Deal with Mid-Project Issues

Early in the development process, both projects fell behind schedule. Discipline and measurement became critical. By tracking their time and following their defined steps, team members were able to identify their status precisely and understand how they got there. The team lead made sure the measurements and data were discussed in the status meeting. The coach helped the team understand what the measurements and data meant and how these facts affected the work. With this data-driven feedback, the teams saw an increase in the number of task hours (direct time on project tasks) per week, as well as a sharp reduction in defect rates. With the coach, the teams periodically analyzed their data and improved their processes.

By the end of each pilot project, the quality of each team's work had improved significantly. They were able to find and remove defects earlier in the process. After the initial delivery, no further defects were found in system tests or production in the remaining three cycles. There were zero defects in deliveries two through four. This improvement required months of effort, training, management support, coaching, worker motivation and engagement, and meaningful data-based feedback.

See the Results

In the end, the TSP pilot teams at Nedbank made significant behavioral changes that not only improved the quality of the software but also improved team members' work lives by decreasing the need for evening and weekend overtime. The teams were able to make these improvements because they had project-specific measurements to guide their decisions, and they had the authority to implement those decisions. Based on the results of the pilots Nedbank decided to implement TSP throughout the organization.

To learn more about Nedbank's views on TSP, see their rollout video below:

This video requires the Adobe Flash Player Plug-in please go to the following URL to download:

Expanding and scaling any process comes with challenges. These topics will be discussed in the second post of this series: Achieving Quality and Speed with TSP Organization-Wide.


Additional Resources:

To read the SEI technical report Deploying TSP on a National Scale: An Experience Report from Pilot Projects in Mexico, please visit

To read the Crosstalk article A Distributed Multi-Company Software Project by Bill Nichols, Anita Carleton, & Watts Humphrey, please visit

To read the SEI book Leadership, Teamwork, and Trust: Building a Competitive Software Capability by James Over and Watts Humphrey, please visit

To read the SEI book Coaching Development Teams by Watts Humphrey, please visit

To read the SEI book PSP: A Self-Improvement Process for Engineers by Watts Humphrey please visit

Share this

Share on Facebook Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Save this page on your Google Home Page 

2 responses to “Improving Software Team Performance with TSP”

  1. Barry Dwolatzky Says:
    Thanks Bill for this really interesting overview of the Nedbank TSP adoption. As the Director of the Joburg Centre for Software Engineering (JCSE) I was very excited to be involved in this TSP pilot.

    The one amazing factor not covered in much detail by Bill (it may be in Part 2) is the human dimension. The developers and their managers felt incredibily positive and empowered when given the opportunity to work in a TSP team. This comes across really well in the video.

    In an industry where people suffer burnout at 30 years of age, TSP is the only method I've seen that takes a stand against the anti-social work ethic and hero culture that has long defined software development.
  2. Peter Alkema Says:
    I found this blog and the videos very interesting and I am considering doing some postgrad research in this area as part of the JCSE's pioneering work. I think the bottom up approach is desperately needed by small to medium size teams and project managers looking for practical approaches to deliver high performance rather than extensive theoretical methodologies.

    I would be most grateful to hear from anyone who has suggestions for research topics in this area. I also strongly feel the human element is overlooked in software development and the increased motivation levels of people who participated in the TSP pilot was evidence of the improvements you can achieve by helping people deliver high performance in software engineering.

Add Comment

Leave this field empty: