NEWS AT SEI
This article was originally published in News at SEI on: January 1, 2004
When Jeff Schwalb heard the SEI’s Watts Humphrey describe the SEI Personal Software Process (PSP) methodology back in 1995, he thought it might be the key to reenergizing the software-process-improvement efforts at the U.S. Naval Air Systems Command (NAVAIR), which develops, acquires, and supports the aircraft and related weapons systems used by the U.S. Navy and Marine Corps.
At the time, Schwalb, who works in the Software Resource Center at NAVAIR’s China Lake site, was trying to teach software development teams to use the SEI Capability Maturity Model (CMM) for Software. “It was frustrating,” he recalls. “We would teach groups about CMM, and people built the process and the documentation, but then they didn’t use it.” Schwalb attended the Software Engineering Process Group conference in 1995, hoping to pick up some tips. He attended a presentation in which Watts Humphrey explained a different way for engineers to precisely apply CMM process principles—using PSP. “I saw Watts and I thought: ‘This is the way to do it. Don’t make groups create a process, rather give them something to start with. Then they can revise the process as needed.’”
Later that year, Schwalb attended PSP training at the SEI and became the first PSP instructor at NAVAIR. When the SEI developed the SEI Team Software Process (TSP) methodology to extend PSP’s disciplined engineering approach to teams, Schwalb was an early adopter.
The PSP provides guidance on how individual engineers can continually improve their performance. The TSP provides guidance about how PSP-trained engineers can work as effective team members on high-performance teams. These methodologies can work together to allow organizations to produce quality software on schedule and on budget. Also, PSP and TSP can help organizations implement Capability Maturity Models, which focus on what organizations should do, but do not specify how to reach those goals.
Schwalb introduced PSP and TSP to NAVAIR’s Software Leadership Team, which devises software-engineering policy and guidance. He also brought in Watts Humphrey from the SEI to make a presentation. The team “bought in to PSP and TSP as a way to quickly implement CMM-based process improvement,” Schwalb recalls. That support ultimately resulted in a NAVAIR instruction that includes the statement: “Programs engaged in organic software development should use the Personal Software Process and Team Software Process for personnel training, project initiation, and execution.”
Today, eleven TSP projects are underway at NAVAIR, seven are planned, and at least five more are being considered. Some of the projects that have benefited from TSP and PSP include the F-14D Tomcat, its successor the F/A-18 Super Hornet, and the AV-8B Harrier. For example, the AV-8B Joint System Support Activity at China Lake, CA improved from CMM Level 1 to Level 4—the second-highest level—in only 30 months, less than half the usual time. Also, “the savings from cutting defects in the F-14D project more than paid for the TSP training,” Schwalb says. The project’s managers expected to save more than half a million dollars from reduction of defects in flight testing alone.
Using TSP has paid other dividends. Recently, NAVAIR managers found it relatively easy to combine two teams, one that had just finished working on the Operational Flight Program component of the last major fleet release of the F-14D and another working on the Hawkeye electronic surveillance aircraft that was understaffed. The key to success was the fact that both teams used the same process and could easily share information. “TSP and PSP gave us a common vocabulary to start with in terms of how we were going to do our work,” says Timothy Chick, Hawkeye project co-leader. The methods also “define many of our day-to-day processes, which allows us to focus on communication and the technical challenges before us.” Antonio Garcia, the project’s other co-leader, likes the fact that with TSP, team project status is always available. “Knowledge of problems or slips with project plans as they occurred has been a tremendous plus,” he says. “This was not possible in the past, without the weekly tracking of plans that is done in TSP.”
Teams working on upgrades for the Hawkeye patrol plane are using the TSP.1
John Mishler, former technical director of NAVAIR’s Naval Aviation Systems and Analysis Department, found the results of TSP projects impressive: “My experience with PSP/TSP has made me more aware of how little of what is claimed by numerous management theories is really based on empirical data. By contrast, the PSP/TSP approach is built on a firm foundation of personal and team motivation theory and software engineering research, and provides a sound practical application of statistical theory. The PSP/TSP method is backed by an ever-growing body of research and a practice methodology that is data based and produces consistent results. The TSP enables teams to manage requirements, to plan their work based on empirical data, and to work their plan using best-practice methods, such as earned value management. Projects using the PSP/TSP method have a proven track record of delivering products on time and within budget with dramatic quality improvements.”2
For more information
Please tell us what you
think with this short
(< 5 minute) survey.