September 19-22, 2011 | Atlanta, GA
In the current economy, organizations are looking for ways to maximize their return on investment. Capers Jones has rated TSP as one of the top methods across small, medium, and large software projects for improving cost, schedule, and quality performance in software development organizations.
Industry data has quantitatively demonstrated that using TSP significantly improves a team’s overall performance. This one day tutorial provides an overview of the core TSP concepts and principles and provides the foundation needed to begin to introduce and apply TSP in your organization.
Key topics include:
This tutorial is designed to introduce organizational leaders, process improvement champions, consultants, and advocates to the SEI's new Accelerated Improvement Method (AIM). This tutorial concentrates on the concepts and strategies associated with AIM, which is a radical departure from the traditional methods of CMMI implementation, technology transition, and organizational change. It provides a strategic, organizational focus while implementing performance improvements through a tactical bottom-up approach. AIM integrates and leverages established and effective improvement technologies: CMMI, SCAMPI, Team Software Process (TSP), a rapid deployment strategy, and the Six Sigma toolkit. This integration has resulted in a repeatable fast track to high performance.
Key topics include:
There are dozens of software development methods that include Agile, Crystal development, extreme programming (XP), the Rational Unified Process (RUP), the Personal Software Process (PSP), the Team Software Process (TSP), Rapid Application Development (RAD) and many more. There are also the five levels of the Capability Maturity Model Integration (CMMI) developed by the Software Engineering Institute.
This keynote address provides a method of evaluating methods based on quantitative data. It also evaluates a dozen popular methods and shows their current productivity and quality levels.
Software methods are not a “one size fits all” approach. Some methods such as Agile are most effective for small projects below 1,000 function points. Others such as RUP and TSP excel for larger applications above 10,000 function points.
Methods are evaluated using a multi-criteria approach. The rankings include best practices, good practices, fair practices, neutral practices, harmful practices, and a set of very harmful methods that should be considered to approach professional malpractice if used on important software applications.
Data available to date indicates the TSP is one of the most successful development methods for complex systems due to its focus on quality and measurement.
TSP rollout in an organization of any size presents a number of challenges in both resource planning and change management. We will discuss some of the considerations after selecting and evaluating pilots. Taking TSP usage to the next level requires a sales job. We will discuss change management in preparing all levels of the organization. We will also show a video produced help advertise the benefits of using TSP for the individual developers. In this video, developers and project leads talk about their experiences using TSP.
How do you drive excellence in a TSP implementation within new TSP adopter countries? Procesix and Kernel are convinced that alone we can do so little, but together we can do so much. We are also convinced TSP is the key to achieve a committed team, a defined process, and quality maturity.
In this presentation, we will show our strategy on working together to deploy TSP as a first phase to CMMI, combining efforts to share the benefits these models have for companies to achieve maturity, competitiveness, and excel at their overall performance.
The presentation will include improvements experienced at Bupartech Company, the first TSP implementation in Ecuador, a committed organization that successfully built a self-directed team in a successful TSP introduction. This session will include the first results obtained in Colombia. We will include PSP training results and PSP project and team data. We will also share the effort done in a combined alliance to deploy TSP in other countriesin South America.
Which are the next steps? What shall we seek to find in a partner and multiply efforts building alliances and sharing efforts on a TSP implementation?
The presentation will show:
It’s exciting—even glamorous—to lead others through good times and bad. But leadership also has its dark side: the inevitable attempts to take you out of the game when you’re steering your organization through difficult change.
Leading change requires asking people to confront painful issues and give up habits and beliefs they hold dear. Result? Some people try to eliminate change’s visible agent—you. Whether they attack you personally, undermine your authority, or seduce you into seeing things their way, their goal is the same: to derail you, easing their pain and restoring familiar order.
This presentation will provide you with practical tools to resist the attempts to remove you and manage your hostile environment. They will help you to continue to propel change forward.
Watts Humphrey defined the Quality Profile and the Process Quality Index (PQI) as a predictor of component quality in system test and usage. Empirical evidence collected from early Personal Software Process (PSP) experiences showed that components with a PQI greater than 0.4 indicated near zero defects found in system test and in usage. The PQI reflects five considerations of the software development process: 1) the ratio of effort spent in detailed design vs. test, 2) the ratio of effort spent in code vs. personal code review, 3) the ratio of effort spent in detailed design vs. detailed design review, 4) unit test defect density, and 4) compile defect density.
We examined data from more than 100 projects we have coached, and found that the benchmarks specified by the SEI need to be recalibrated for certain types of projects: specifically, commercial software product development. We will share the re-calibrated PQI that we have been using with our teams with some success.
The original PQI did not consider the impact of inspections on component quality. We will share how we have incorporated inspections in the PQI.
The other problem we faced with the PQI as defined by Watts Humphrey is with the unit test defect density and the compile defect density measures: most modern development environments do not include a compile step, and with Test Driven Development (TDD) and automated unit test frameworks, measuring unit test defect density is difficult. The purpose of measuring compile defects was an independent, unbiased method of determining code quality. This usually means the use of a tool. In the spirit of replacing one tool determined way of determining code quality with another, we encouraged our teams to use static code analyzers. We collected data from 13 projects, and the results show that static code analysis is a valid replacement for the compiler. We will share our results in this presentation. Replacing unit test has been harder: we tried substituting code coverage, but the results were not as conclusive as static code analysis. We will also share our results with trying to find a replacement for the unit test defect density component of the PQI.
Why would an architect be interested in TSP? TSP is for developers, right? And also, architecting is a creative task; this cannot be squeezed into any process. Wouldn’t you agree?
Using the Team Software Process (TSP) for designing a system is beneficial not only to plan, estimate, and track the architects work but also to gain a better understanding in how to support TSP development teams so that they can do their job more efficiently.
TSP is strongly based on providing a measurement framework to gain insights in what is happening in a project. Some of the measurements are geared to implementing code. “Size” is usually measured in lines of code. This does not apply to architecture tasks since there are no lines of code produced. Similar issues arise for measuring quality. Tracking bugs in implementations is a good measure for code quality, but what would be the appropriate quality measure for architecting tasks?
But not everything an architect does is technical work. A big portion of the architect’s everyday work is communicating with the various stakeholders. This presentation provides some insights into typical architecting tasks and how those can be estimated, scheduled and tracked. It shows also how the TSP data collected for the technical tasks supports the communication with the stakeholders, such as the product managers, the developers, or even the CEO. Overall, the presentation will show that more transparency into the art of architecting, introduced by using TSP, is not only beneficial for the architect but also for the developers and managers.
It's easy to state that not all pre-TSP/TPI teams are alike but how different can they be? How do they make their way from the dark ages of ad-hoc process to disciplined superstars? We will discuss the different pre-process team types from the self-actualized champions to the folded-arm curmudgeons. Also covered will be techniques for dealing with the different types of teams, baby-step introduction methods, and a multi-level measurement scale to describe the maturity of TSP/TPI teams.
The TSP is typically seen as a way to build software faster, better, and cheaper. The focus is more often on software process and less on team. However, the true power of the TSP rests with the ability focus desired organizational behaviors. Team is the key to TSP.
This presentation will focus on organizational factors, known as organizational citizenship behaviors (OCBs), which are affected by elements of the TSP. OCBs are known to be a necessary part of organizations that outperform their peers. Factors such as trust and altruism are directly impacted by the team environment. A model will be presented that relates important elements of an organization and how TSP directly impacts those elements. Various aspects of the TSP are diagnosed from the perspective of building an organization that outperforms rival organization. The behaviors of several teams will be compared and assessed against the elements of the TSP to determine behaviors most likely to result in high performance. Finally, the resulting improvements to productivity will be presented along with benchmark team data for traditional development teams. From this data, behaviors associated with high performing team will be analyzed.
We can put a man on the moon but we can’t build a clock app that works? Software is a fundamental building block of society. Yet with all the advances that improve software development, building software is hard. Software is often delivered late, over-budget, with missing features, and despite the added costs, software is generally defective.
Is this just the reality of software development?
The issues we face are not unique to our profession. The root cause is human nature. We tend to be too optimistic about what can be accomplished, and are generally not wired to perform highly complex technical work without introducing errors. We resist even evidence-based change and have a built-in blindness in examining our own work.
This presentation examines how other professions get things right, compares these examples and their consequences to software engineering, and proposes what we might do to achieve the same results.
How do you report status to management when your TSP team is working on multiple, simultaneous releases, requirements are changing, you have an integrated product team, and management has great expectations about schedule and quality management? Our team struggled for several months to present the right information in the right format to our management. After several false starts, we have now settled on a format that is helpful to both management and to the team, and that can be generated without too much effort from the team planning and quality managers.
We regularly report scope, schedule, and quality status to management. In this presentation, we will share our experiences, the ones that did not work so well, and the most recent ones that seem to be working.
The Team Software Process (TSP) is a methodology developed to manage self directed teams who are capable to achieve high performance at developing quality software. The many successes of TSP implementations on software projects has been brought to the attention of managers that are also responsible for other groups; i.e., systems engineering, organizational training, help desk, implementers of software products.
This presentation describes another pilot on how TSP has been used to help service organizations. The TSP was implemented to manage a group of engineers in charge of implementing proprietary software products at customer locations (functionality gap, product configuration, test, install, and train).
The presentation first describes the preparation work for the launch—understanding the organization, explaining benefits of TSP in their environment, building the sponsorship, defining the scope, sketching the service processes, and providing the training. Second, it describs the points of inflection in the launch steps—defining the strategy to handle the work and the organization, defining the conceptual design, customizing services processes, customizing size measures, customizing defect data, and defining the quality plan. Third, it describes the points of inflection on tracking the project’s progress—handling changes and dealing with the right abstraction for progress. Fourth, it describes the project results—team performance, measurement, improvement, benefits, changing the team’s way of working, and the overall improvement experienced in the service project. Finally in the lessons learned, it describes how to handle TSP implementation problems such as denying the reality for not fulfilling customer compromises and stepping on dangerous–inadequate organizational practices.
This presentation will cover the experiences of a team at Adobe Systems that has been using the Team Software Process since 2009 as part of a three year project. The team is within a large product group. This session will share the team's performance, improvements, and benefits so far from using TSP, and will discuss how TSP has impacted their work from the perspective of team members, team leader, and their senior management. This presentation will also cover a brief history of the overall TSP program at Adobe up to the present, which is currently just one team doing TSP. The presentation will explore the current context and reasons for the size of the TSP program at Adobe, as well as the substantial benefits that Adobe Systems has gained so far from doing TSP.
Because the PSP is a personal process, what happens using PSP remains personal. So therefore, the improvements to the process are personal. We all know, however, although we are different, we are in many ways the same. We demonstrate this in PSP training by presenting aggregated class results to the class. It is through the statistical analysis of the aggregated results that we demonstrate the effectiveness of PSP and explore the software development process. However, this has not yet been done with recent versions of the course. Because of limits in the data availability, some aspects of the improvement been left unexplored.
A new source of data is now available through the SEI's Blended Learning system. This system has also collected data in greater detail than was available previously. We will now leverage that new data source to better understand how typical expected improvement from the PSP course. We have begun statistical analysis by analyzing the programs of all students using C, C++, and Java and have completed the final exercise PSP II.
In this study, we present an analysis of defects injected during the design phase in PSP exercises 6, 7, and 8. We use familiar PSP analysis, but limit consideration to the defects injected in design. We observe how defects injected during design escape into each phase of the PSP and how the cost to remove is affected by defect. We describe the different defect types injected during design, and how these defect types correlate with the find-and-fix time. From this analysis we draw some conclusions about defect behavior through the process. Finally, we study the defects that escape into Unit Test.
Excellence in PSP means efficiently driving toward zero defects escaping into Unit Test. We analyze improvement opportunities to achieve even better process yields by studying the design defects through the PSP phases.
The TSP for software engineering teams does well due to training provided by the PSP for Engineers course. However, starting a team that provides other products and services such as systems engineering or product support has been challenged by the lack of depth in comparable training for these other areas.
This approach interlaces personal process and just-in-time team member training course modules along with the application of process modeling techniques. This means the team being trained also performs process modeling on the activities used to actually provide their products and services. These processes are then folded into the team training as examples. They are also applied in the actual launch as life-cycle models for the products and services being planned. Generation of team processes during training allows the team to enter the launch with a strong connection between planning the work and knowing how the actual work is performed.
Another benefit of this approach is the attention paid to quality. This is accomplished by introducing the team to the notion of mistake injection and removal phases in their newly defined processes. This begins during initial modeling of the processes and is then repeatedly emphasized through to the review of the process during the third meeting of the launch.
Finally, this defined set of process activities lends itself to the ability to generate an environment that uses the appropriate nouns and verbs so that a team hits the ground running from the first day of the launch.
When a team’s members share a common goal, know how they are going to reach the goal, and are able to work and support each other, they can achieve their best performance. Working in a team setting like this can be a motivating, satisfying, and rewarding experience, but it is also rare.
Not every group of people working together behaves like a team. Because nearly all development work involves groups of people working together, nearly all development work can be improved by having the capability to quickly build jelled, high-performance teams. This is the responsibility of the TSP Coach.
In this interactive we will define the coaching role and discuss methods for building and sustaining high-performance teams.
Most active coaches have been at both ends of the spectrum of “coaching luck.” The senior manager walks in with one of the best meeting 1 presentations ever—or no slides at all. The team of rookies cruises through the launch like they’ve been doing it for years—or the team of veterans treats every process step like it’s the first time they’ve done it. The review team uses checklists like scalpels—or reads them like they are translating Sanskrit.
While some of the successes can be attributed to fortunate circumstances, Louis Pasteur’s famous observation is most often applicable: “Chance favors only the prepared mind.” This session presents some common coaching scenarios, from organizational introduction to individual guidance, and discusses the roles of prescribed preparations like the pre-launch checklist, and less obvious ones, like building a relationship with the management team, in ensuring that your coaching experience is prepared for fortunate happenings at all times.
Developing software for medical devices is a very challenging undertaking. The quality of the software must be extremely high to meet the demands of providing safe and effective products involved in the critical care of patients. Medical devices are regulated by the United States Food and Drug Administration and by similar agencies in other countries. This requires constant focus on meeting all of the regulatory requirements established for medical device software development on a day-to-day basis.
For more than three decades I have lived in a world of constant focus on the quality of the software being produced and constant oversight of the processes used to develop the software to ensure that there are no missing steps that might introduce regulatory compliance gaps. I have spent a tremendous amount of my time doing what is necessary to make sure these go well.
Working with our TSP projects is a delight. With the TSP in place, meeting these challenges is now becoming second nature to the team. We will now be able to focus much more on delivering full feature
In 2004, the United States Marines Corps approached a CMMI Level 5 group in the United States Air Force for software support of their amphibious Expeditionary Fighting Vehicle. Due to resource constraints, this team at Hill Air Force Base in Utah staffed the team with technical experts who, unfortunately, were not all familiar with CMMI. However, the team was part of an organization that had embraced PSP and TSP and was able to provide a highly capable TSP coach who introduced TSP concepts that allowed the team to rapidly implement high maturity processes and practices. Over the next several years, the team grew from a dozen team members to over a hundred and developed more than one million lines of embedded software code as well as hundreds of thousands of pages of requirements, designs, and test procedures. Not only did this team release engineering builds on schedule in a rapidly changing development environment, but they consistently delivered high quality software with system test defect densities below 0.2 defects per thousand lines of code. The final version of software had a delivered defect density of only 28 defects per MILLION lines of added, modified, and deleted code.
The Hill EFV team used TSP across all coding aspects, including Mobility, Power and Auxiliary, Controls and Displays, Fire Control, and even support products such as Test Tools. TSP concepts were also used for System Software Design, System Test, and Command and Control Teams. They experienced great success with a multi-team approach to TSP launches and were also able to modify the launch and tracking processes to account for rapidly changing requirements; this approach eventually brought some peace of mind to a frantic customer.
While the EFV project was canceled in early 2011 due to total cost of ownership, the Hill team’s effort was considered enormously successful and the team members are now taking leadership roles on new projects throughout the Hill group, bringing the practices of TSP with them.
This presentation describes the implementation methodology of PSP and TSP for graduate students and how engineering skills of students are improved in terms of planning and quality. Issues and future work are also described.
Based on a cooperation agreement with CMU/SEI supported by the Ministry of Education, Culture, Sports, Science and Technology of Japan, Kyushu Institute of Technology has introduced PSP and TSP into its curriculum for graduate students to produce responsible software engineers who acquire practical engineering skills for software development. First, three faculty members acquired the certification of PSP instructor. Then, the training courses PSP-I and II of PSP for Engineers have been conducted as regular courses since 2007 and 25 graduate students took the course in total. The TSPi course, the educational version of TSP, was also started in 2010, and the first TSPi team of three students successfully finished their project.
Major issues of incorporating PSP into a yearly class schedule are the most effective allocation of lectures and instructions to the limited time slots of class and programming skills of students required to complete PSP assignments. 100% of students completed PSP-I in 2010 by certainly confirming the understanding of requirements, the soundness of conceptual design, and the correctness of estimation process in the planning phase, while 43% in the first year.
Quality improvement is clarified by the trend curve of defect density and test time through the courses. The average defect density in unit testing is gradually reduced through Assignments 1 to 8, and 26.7 defects per KLOC for Assignment 1 was 7.7 for Assignment 8. The percentage of test time in total development time indicates the same improvement result.
Three students who completed Assignment 6 at least built a TSPi team, and challenged the change counter example. They completed only one cycle even though they chose the development strategy of two cycles. One reason for the schedule change is high defect density, 42.6 defects per KLOC, in unit testing. However, they successfully finished the first cycle without any defects in system testing because they decided to rework the design in accordance with the stated guidelines of TSPi.
Because insufficient skills of coaching a TSPi team are also clarified, it is planned to improve the coaching skills through TSP coach training and mentoring.
This presentation will talk about our project’s journey in trying to figure out how to collect and organize historical data in a way that is useful for future estimates. This presentation will give examples of original approach and discuss the issues and drawback associated with it. Then we will talk about the current approach being used, which includes the use of both size and effort based proxy tables, based on the available historical data. We will discuss the full software development lifecycle, from requirements elicitation to product delivery and provide the associated estimation variables.
From the many lessons Watts Humphrey taught by example, I have selected five major threads that have impacted my own professional life.
The importance of true commitment. Anecdotes are used to show why total commitment to rather simple quality principles are at the center of Watts’s work from the essence of CMMI Maturity Level 2 to the discipline of PSP/TSP.
Discipline is not a bad word. Some psychology is in order to understand why some are more predisposed to a regimen to improve than others. But no matter the predisposition, Watts’s work shows how to make discipline a habit for improvement.
Level 5 is about personal commitment and discipline. Anecdotes are used to show the impact of disciplined data analysis and commitment to quality on business results.
Let nothing stop you. Anecdotes from my own exam to become a PSP instructor and vignettes from Watts’s life are used to show that we succeed when our desire for improvement is stronger than our fear of failure.
The renaissance is over. Watts recognized at the end of his life that genius, outrageous commitment and even extraordinary achievements are not sufficient to have an impact. It takes many teams and collective effort. This may be his most important legacy.
Finally, the principles behind AIM are used to show the impact of Watts’s ideas on the present and future of systems engineering.
After being part of more than 200 TSP launches in the last 12 years, I have been continuously amazed about how much more I know after each experience. This talk will cover the lessons I have learned that will provide the highest leverage to the session participants. The lessons will be highlighted by examples from experiences I have had with TSP teams.
TSP Coaches and team leaders who adapt these ideas will accelerate their growth journey in leading and coaching teams to excellence.
From August 2009 to June 2011, the SEI worked with la Bolsa Mexicana de Valores (BMV)—the Mexican stock exchange —on a project to build a new online securities trading engine that will replace Mexico’s three existing systems that trade stocks, futures, and derivatives. BMV chose two SEI technologies to help guide the project: the Team Software Process (TSP) and Architecture-Centric Engineering (ACE).
Beginning in July 2011 the system enters system test, and live validation testing, running in parallel “shadow mode” to the existing system, is scheduled for September 2011. This talk presents selected project results, process data, and other interesting project information including the starting conditions, architectural quality attributes (both desired and as they stand), the project timeline, cycle-by-cycle process data summaries, process issues surrounding the use of ACE practices, tailoring considerations in using ACE on a TSP team, and preliminary recommendations for using ACE on future TSP projects.
Please tell us what you
think with this short
(< 5 minute) survey.