TSP Symposium 2010

September 20-23, 2010 | Pittsburgh, PA

TSP Symposium 2010 Abstracts

Exploring TSP: An Introduction

Held on Monday, September 20, 2010, 9 a.m. - 3 p.m., the TSP Overview Seminar covers the following topics:

  • The basic concepts on which the TSP is built;
  • How the TSP can effectively improve software development activities and provide positive motivation for engineers and project team;
  • How to use the TSP to address current and future software needs;
  • How to successfully introduce and maintain TSP; and
  • What management must do to help their teams be successful.

This one-day introductory course for software development management covers the key concepts and principles of the Team Software Process (TSP) and Personal Software Process (PSP) from a management perspective. The purpose of the course is to provide the foundation that managers need to begin to introduce and apply the TSP in their organization.

Keynote Address: To Boldly Go

David Webb

In changing the word of software engineering, those of us who are championing the Team Software Process (TSP) are on a quest “To Boldly Go Where No One Has Gone Before,” like the folks in Star Trek. Instead of “exploring strange new worlds, seeking out new life and new civilizations,” we’re exploring strange, new tools and seeking out new processes and new approaches. While much has been made of the phenomenal successes of TSP projects, adopting TSP into any organization is rife with its own risks and challenges. How we deal with those risks, obstacles, and setbacks is as important as how we deal with the successes; in Star Trek terms, “how we deal with death is as important as how deal with life.” 

With more than 15 years of experience in implementing the TSP at Hill Air Force Base in Utah, David Webb will Captain you through the TSP introduction process so that your TSP initiatives will “live long and prosper!”

Introducing PSP/TSP Massively in Mexico

Héctor J. González Santos

How can Mexico’s SME (Small and Medium Enterprises) accelerate their process maturity to achieve organizational processes and quality? How can Mexican engineers be prepared to compete? The answer is PSP and TSP.  We are convinced that TSP is the key to achieve process, product and quality maturity and first we shall start by training our engineers.

This presentation will show Kernel’s strategy and results when implementing this first phase of our TSP implementation in SME’s by training 250 engineers in diverse companies (50 Mexican SMEs). These companies were selected though the implementation of MoProSoft to accelerate their process of implementation. We will see Kernel’s initiative to achieve 100 PSP Certified Developers; benefits, conclusion, performance results from the engineers, and improvements areas when implementing PSP training massively.

Which are the next steps? How can the SEI help in the implementation of TSP Projects in SMEs? What shall we do as SEI’s Partner?

Ten Years with TSP – A Retrospective and A Path Forward

Daryl Davis

The Team Software Process was released 10 years ago. During the years since the release, we have worked with hundreds of TSP projects in dozens of organizations. This presentation will describe the journey, the detours along the way, the impact of the Agile Manifesto, the successes and disappointments, and suggestions for the path forward. Davis will present data and results from projects to illustrate the successes and the challenges.

In the beginning, we knew how to do launches really well: using TSP for the rest of the project, maybe not so much. Next, we got better with using TSP to manage the project: by coaching team roles, better guidance for team leaders, improved checkpoints, and better postmortems. TSP teams have always produced high-quality software: we learned how to augment the TSP quality practices of personal reviews and team inspections with other practices such as automated unit test and static analysis.  We learned to adapt TSP to modern development practices. We focused on the iterative and incremental nature of TSP. And we started to address areas of the development process not well addressed by the TSP: requirements and end-user involvement.

In spite of all, we have learned and all our successes, we continue to face challenges as we move forward. TSP is simple, but not easy: most teams struggle with the discipline required, and struggle to maintain the discipline for the long haul. The lack of easy-to-use tools continues to be a problem. Community engagement is low, especially from the developer community. The ability to experiment with and to modify the TSP is limited. Finally, the success of Agile methods is a direct challenge to the TSP.  Davis will present some ideas about how to address these challenges.

Will TSP Shape the Future of Software Development in South Africa? Report on a National Pilot Programme

Barry Dwolatzky, Alok Goswami, and Lisa Lyhne

In July 2009, a pilot programme was launched to explore TSP adoption in South Africa. The pilot also aimed to train local PSP/TSP instructors and coaches.

Key roleplayers in the pilot are: the national government of South Africa (through its Department of Trade and Industry); the SEI; the local SEI partner organisation (the Joburg Centre for Software Engineering, or JCSE, at Wits University); and two companies (Nedbank and Dariel Solutions).

The proposed presentation will be the first comprehensive review of the achievements of the TSP Pilot as a whole. The overall objectives will be presented and then results will be described. These descriptions will draw both on the data collected from each of the pilot projects, and on a series of interviews conducted by the JCSE with participants in the pilot.

The presenters will conclude the session with an attempt to answer: will TSP shape, or at least influence, the future of software development in South Africa?

Integrating Software Development and CMMI using TSP

Jason Huibregtse and Jenna Fleshman

Over the past 20 years, Stanley has developed processes that provide the means for development and integration of software systems. To improve the development process, Stanley chose to focus on the basis of the development process, the software development team. Stanley’s plan was to implement processes that allow the team members to produce high-quality products. The TSP practices provide the framework for resource allocation, problem detection, and increased communication to produce these quality products within cost and schedule. As a result, Stanley teamed with the SEI and implemented the Accelerated Improvement Method (AIM) now being offered by the SEI. Stanley’s pilot projects demonstrate the effectiveness of the TSP scripts, forms, and training that were created specifically to address expanded CMMI compatibility.  Since this version of the TSP is not currently available to the TSP community, this is your chance to hear about Stanley’s experience with this approaStanley’s experience with this version of TSP will be presented by those most closely related to the pilot projects: the coaches, the EPG members and the team leads.

"Real Artists Ship" A Journey in Leadership

Tim Lancaster

Steve Jobs once said in one of his inspirational talks to his development teams: "Real Artists Ship".  

High-quality software is more than software that runs as designed. True quality software provides an exceptional experience for the user. It reaches into the problem so deeply that is provides a solution that seems obvious once uncovered. Software solutions like this are art, but they are not real unless we ship the product, unless the product gets used.

The presenter's team is building a very complex product that must achieve this obviousness to the user. To be useful, this product must provide all of its power and expose none of its complexity. So we must build great art. We must build this great art to a real deadline.  It must ship!

Creating art takes a team willing to do more than just the thought work, but also the emotional work to make something special. Shipping that art takes a data-driven, process-oriented, and discipline-based approach. Art and discipline must meet up in the people of the software team. TSP has absolutely helped us do this. To do so has taken a great effort by the presenter and his team. They have had to do more than follow some textbook steps. They had to internalize the key principles like quality and commitment.  On-time, on-budget, defect-free art through a self-directed, process-focused, data-driven, art-obsessed team.

Lancaster will share a few lessons he have learned as this team's TSP team leader.  He will share about helping a team do more than follow the TSP, but how to make it their own.

Panel Session: TSP in Mexico

Hector Joel Gonzalez Santos, Lina Taborda, Yuri Ontibon, Francisco Aleman, and Adriana Gonzalez-Ugalde

TSP is now expanding rapidly in Mexico. Colombia is now where Mexico was in 2007. This double session includes a panel of three partners who share the challenges faced with large scale national roll out of TSP. Each will provide a short talk and we will follow with an open panel. Where are the opportunities? What are the practical barriers? Kernel has been aggressive in building capacity, becoming a leader in training PSP engineers. They will share results and issues in company profiles, preparation, and training models. The Towa talk focuses on implementation of TSP. How to show early results? How do you deal with customers who don’t understand TSP yet? How do you change management behaviors? Intersoft goes back to the beginning, with plans for introduction and rollout in Colombia. This talk will discuss what the Mexicans have learned and a model for how they will lead TSP into Latin America.

Keynote Address: Software Technology: Changing the World though Performance Data

Cynthia Dion-Schwarz

Software Technology Maturity Assessment is an evolving process used by the Department of Defense to assure that new technologies have been demonstrated before the Department embarks on major acquisition programs.  These assessments, called Technology Readiness Assessments (TRAs), are focused on functional outcomes, using two principles:
•    Assessments should be conducted by experts in the technology, of unquestioned independence from the program;
•    Assessments should be based on data and evidence of performance, not on projections of feasibility.

This talk will discuss how TRAs are conducted, what pitfalls we’ve seen, and how the process is evolving to meet the evolving needs of the Department. In addition, this talk will discuss how maturity assessments should (but doesn’t always) precede or interlace proper software engineering practices, such as CMMI/TSP or Agile.

Team Software Process at Adobe Systems: Experiences of Three Teams in a Product Group

Barbara Spencer

This presentation will highlight experiences of three teams at Adobe Systems currently using the Team Software Process. The three teams are part of a large product group. Two of the teams are doing Multi-Team Software Process. The other team is doing standalone Team Software Process. The presentation will cover the three teams' performance, improvements, and benefits, and will discuss how TSP has impacted their ways of working. The presentation will also cover overall project improvements, as well as benefits experienced by the engineers. All three teams started implementing the Team Software Process in 2009 and have been using TSP for less than a year. This presentation will cover what is going well and the teams' current challenges as well as the general topic of how the introduction of Team Software Process within the overall product group is perceived, and prospects for TSP in the future for the overall group.

Selling the TSP: From Organizational Pain to Productivity Gains

Agustin De La Maza

The Team Software Process has helped software development teams around the world to improve their quality and productivity. However, it still is not recognized as an “industry trend”, in part because of the lack of articulation of “business cases” that help IT and business executives to justify the inclusion of the TSP initiative into their project portfolio, to obtain the funding for start-up and on-going phases, and to gain top-management support over time.

In the past years, Softtek has implemented the TSP for several outsourced software development projects and service contracts. Prior to implementing the TSP, a Return-On-Investment (ROI) Analysis was performed for each type of project, according to its “engagement model” (i.e. fixed-price project, core-team staffing, on-demand software factory). Each type of engagement required a ROI Analysis based on different variables (needs, costs and potential benefits) depending on contractual and operation context.

This presentation gives an overview of the “sales process”, the common organizational needs or “pains”, the variables usually taken into account for the ROI Analysis, and some of the actual benefits (productivity gains) achieved in completed projects. This presentation intends to help TSP implementation leaders and promoters to better articulate their business cases and to define business-oriented metrics that provide visibility about the benefits achieved with the TSP in their organizations.

TSP Plays the ACE: Using Architecture-Centric Engineering on a TSP Project

James McHale, Luis Carballo, and Robert Nord

In summer 2009, the SEI began a project with Bursatec, the IT arm of La Bolsa Mexicana de Valores – the Mexican Stock Exchange – to replace their main online stock trading engine, a project which would also incorporate trading of financial instruments such as options and derivatives.  The project has aggressive goals for performance and delivery, and as the face of Mexican financial markets to the world, obviously needs to function flawlessly. 

The SEI answer to this challenge was to blend two of its technologies, Architecture-Centric Engineering (ACE) with the Team Software Process (TSP), each with a reputation for world-class results and superior quality.  This presentation is an early experience report discussing:
1. the background of the project, its business and development context, and its progress to date;
2. how the team was initially structured and how that structure changed as the project progressed;
3. the architectural vision for the project, including architecture coaching of an inexperienced team through the critical elements of ACE, including the Quality Attribute Workshop (QAW) and Business Thread Workshop (BTW), the Attribute-Driven Design process (ADD), the Views and Beyond (V&B) approach to architecture documentation, the Active Review of Intermediate Designs (ARID), and the Architecture Tradeoff Analysis Method (ATAM); and
4. the TSP view of the project, including coaching a combined architecture and implementation team through the early TSP cycles, how the project evolved cycle by cycle, and its current status.

Illuminating the Intersection of TSP and CMMI High Maturity Process Performance Models

Bob Stoddard and Dave Webb

This paper and presentation will illuminate the intersection of the Team Software Process methodology and the CMMI High Maturity concepts of process performance baselines and models. Experience with both CMMI High Maturity organizations and TSP projects have enabled this discussion to progress to the point where a body of knowledge related to the intersection is now possible. This presentation will include a very brief conceptual overview of both the TSP and CMMI Process Performance models to set the context for audience, disregarding their historical orientation. As such, the presenters hope this paper and presentation will serve to motivate a number of pilots of process performance modeling within the TSP domain, as well as, pilots within CMMI High Maturity organizations not currently implementing TSP. Apart from motivating these varied pilots, the authors also hope to record the adoption and deployment experience of the pilots as a means to substantiate the claim that adoption of TSP does in fact accelerate accomplishment of CMMI High Maturity and does in fact produce superior results to CMMI High Maturity implementations without TSP.

The crux of this paper and presentation will be the discussion of the possible outcomes or performance measures that would be reasonably valuable in planning, tracking, and controlling software projects and software teams. This discussion will also include the space of interim outcomes in addition to final project outcomes and will identify the set of outcomes specifically available in TSP implementations.  With the outcomes fully defined, the next discussion will be on the potential “x” factors that may be logically inferred within the TSP implementation which serve as significant factors in predicting the different outcomes discussed. At this point, the audience will realize that much of the published work on Leading and Coaching TSP teams inherently identifies a rich set of factors which can be operationally defined as measures to participate in process performance modeling, disregarding whether the modeling is statistical, probabilistic, or simulation in nature.

Using TSP in an Enterprise Engineering Environment

Tash Solangi and Lana Cagle

The Enterprise Engineering Department (EED) provides support in many facets to the US Navy and US Marine Corps. This support covers software development, systems integration, causality response, and coordination. Most tasks within this organization are not software development driven, however the need for metrics, data, and process do exist.  As with every organization, they are driven to produce and complete tasks quickly, correctly and at an optimal cost - all of this with the set resources provided. TSP provides a single language amongst all players in the execution process to determine the tasks and the amount of effort associated with completing those tasks. The tools provided allow all the teams to understand how they need to interact with one another as well as provide a consolidated view on tracking progress. TSP also allows managers to analyze the data to determine how to become more efficient, accurate, and consistent with all of these tasks, and to also understand a status.  However, since TSP was originally geared towards software development, getting TSP to fit the needs of the team presented a number of challenges that the presenters are trying to overcome. This presentation will cover:1. the goals of the EED;
2. roles and responsibilities of the Functional Area Leadership (FAL) team;
3. launching a "team of teams", launching multiple teams synchronously into one mega-team;
4. keeping common measurement framework, while still implementing process;
5. tying processes amongst the individual teams into one large process;
6. interaction between Functional Area (FA) Teams and the FAL;
7. data collection to use internally--how do we become better, fixing the process, how do we do better; and
8. data collection to use for stakeholders--proving that we are becoming efficient.

A Demonstration of Certpoint Blended Learning System for PSP

Dan Burton

This interactive session is for PSP instructors who will use the Certpoint blended learning system to deliver PSP Fundamentals/Advanced or PSP I/II. This system replaces the one previously provided by
iCarnegie. Bring your laptops since this session will include hands-on and follow-along demonstration.

After this session you should understand how to navigate the new system and how to accomplish common tasks. Ask questions and share your experiences and concerns.

Changing Behavior: The Key to Adoption of Complex Process Technology

Gene Miluk

This session will explore non-traditional approaches to behavioral change and technology adoption. Many organizations have made large process improvement investments that, for many different reasons, have failed to be transitioned into practice. This session will focus on methodologies for transitioning system
development processes into sustained practice.

We will discuss multi-level, multi-disciplinary cutting edge approaches to technology adoption and behavioral change. Topics include:
• just-in-time sponsorship;
• total process emersion therapy;
• process simulators;
• bayesian Belief network analysis applied to process technology adoption;
• use of cognitive behavioral techniques; and
• application of the Bandura social learning curve with self-efficacy models for increased sustainment of
new behaviors.

Keynote Address: How to Teach Programming – Introducing PSP into the Curriculum at two South African Universities

Barry Dwolatzky

I learnt to program 40 years ago, in the age of mainframes, batch processing and punch cards. There was a huge penalty, in terms of wasted time and frustration, for having defects slip through to compile and
test. The advent of user-friendly interactive development environments has removed the “pain factor” associated with locating defects in compile and test. In this presentation, an approach is suggested for
incorporating PSP into the teaching of programming by recreating some of the conditions experienced by programmers 40 years ago.

Developing an Approach for Effective Transition of TSP Team to Meet Project Goals

Yoshihiro Akiyama

Many organizations have very limited skills, knowledge, and experience with TSP and systems engineering processes. When a coach is asked to launch and coach a large team, the organization may not be aware of how a TSP multi-team supports a systems approach.  This approach coordinates teams structuring the project by considering not only the engineering products, but also a multi-cycle systems engineering process. This inexperienced organization with challenging problems provides special challenges to the coach.

This presentation explores categorizing team working levels TM0, TM1, and
TM2 based on the knowledge and experience levels of the team. We consider the engineering view of they will build, and the ability of the coach and team follow the TSP process.
For example, a simple description of the levels may be as follows:

TM0- A simple project may contain sequential modules that have limited interaction with other modules. Individual engineers work mostly independently. Limited communication and no system design are required.  

TM1- A more challenging project with communication and interacting components may require knowledge is that explicit, but little use of tacit knowledge. The explicit knowledge can be used to identify system design and develop a conceptual design at the team and individual level.

TM2- The most challenging problems occur where the knowledge necessary to start the project is minimally identified. Typically, tacit knowledge will be explored as the initial versions of the product are developed and project progresses. The system design and implementation will be refined iteratively and/or augmented. Success depends upon experienced teams with a demonstrated history of achieving project goals. These teams generally understand what to build and how to build it.

The engineers of a project must be properly staffed and demonstrate appropriate levels of discipline, commitment to the project goals, and a "will to achieve integrity and completeness of system concept" by communicating with the customers, uses, and management so that the team plays the central role in extracting and transforming necessary tacit knowledge to the explicit format. The coach can help the team and management properly on the project initiation by assessing the team's such technical and process capabilities. These properly staffed and coached teams enjoy the greatest opportunity for project success.

New TSP Paths: Systems Engineering Team uses TSP to Manage Software Test Product Development

Daniel Wilson

Recently, systems engineers (SE) from the E2C Program Support Activity developed test documents and simulation scenarios using TSP. Previous experience only included participating in a prior launch for the requirements phase of this same project by the Software Development Team. This was a first attempt by the SE group to fully utilize TSP. This carried the burden of planning based on non TSP historical data and the creation of phases more aligned with Systems Engineering tasks. They also had the additional task of developing the tools, processes, and forms, to support the specific needs of a TSP workbook. Two very different aspects of this effort were realized.
1. TSP forced formal process organization on a group that had a historically undefined yet successful way of doing business, in spite of initial reluctance. This methodical approach led to initial test case delivery several months earlier than ever before and prior to the first delivery of software.
2.  Working in parallel with the software developers added tremendous cross-pollination benefits to both teams. Communication was greatly increased for the whole project and the software development team saw an increase in productivity.

This presentation will describe the natural progressions of TSP to engineering teams outside of soft-ware development area. It will further show how parallel teams from software test and software development can increase efficiency and produce a better product.

Achieving Academic Success Using the Team Software Process

Shigeru Sasao and Marsha Pomeroy-Huff

Team VdashNeg, a student group in the Master of Software Engineering program at Carnegie Mellon University, was tasked to build software to autonomously control a robot for a real-world industry project. Four months into the project, after several attempts using different methods, the team was still having difficulty creating a project plan which could effectively track their progress. Having heard that the Team Software Process (TSP) might address many of the issues that the team was facing, they decided to try it out.

Although the team was reluctant to lose another week of productivity, it conducted a TSP launch and its benefits were soon evident. The team gained a shared understanding of the project goals, output products, and risks. The team also made a detailed task list that was within budget and balanced among the team members. Using this task list, and coupled with earned value analysis and the TSP weekly meeting, the team was finally able to effectively track their progress.

The true strength of TSP was most apparent during the implementation phase, as the team strengthened its risk management by strictly following the relevant scripts. The team also began collecting and tracking quality metrics and adjusted the respective processes to support quality goals. The team augmented some of the TSP’s planning and tracking mechanisms to support inter-task dependency and tracking, and followed the concept of continuous improvement through reflection.

TSP was instrumental in the project’s success. The team delivered to the clients a week ahead of schedule. The system had only two documented defects in over 20K LOC. The low-defect density and the early delivery played a major part in the substantial improvements in client relations. The team also eliminated maintenance costs because there were no enhancements or bug fixes to be made, a stark contrast to the other teams, who spent an additional two months on bug fixes and enhancements. Most importantly, TSP taught the team how the software engineering puzzle fits together, and helped the team to mature as engineers.

Lessons Learned Using Agile Methods with TSP

Noopur Davis

For the past five years, we have been incorporating agile methods with the TSP.  In this presentation, Davis will share lessons learned, including false starts, what worked, what did not work, and results from dozens of projects.

The agile practices we have incorporated include user stories, planning poker for high-level estimates, short iterations, iterative and incremental development, automated unit testing/test-driven development, and end of iteration review. Pair programming has also been used occasionally.

Specifically, Davis will discuss changes to team training, changes to the launch, use of the tool, differences in interpreting planning data, and changes to the quality plan.

Who You Gonna Call - TSP

Dan Wall

Imagine that you own a small company, and you are awarded a major new contract but you must be CMMI maturity level 2 within 12 months and you don’t even know what that means! Do you panic? NO. You use the TSP and PSP to kick start your efforts and then build the remaining capabilities over the next nine months, have an appraisal, keep the contract, and win more business.

This session will outline how a small company in upstate NY in this situation was able to make a very effective transformation and achieve a very practical implementation with great benefits in a relatively short period of time. And on top of that, they did it in such a way as to not turn off or burn out their people; rather the staff embraced the process and the changes it has brought about. You will hear their story; how they changed the way the company operated, along with anecdotes from the company’s management, developers and support personnel.

The session will specifically cover their problem, their approach and timeline, lessons learned, and next steps.

What Happens When Your Team Members Go Out to Sea?

Devin Goodwin

The Survey Operations Center is responsible for life cycle maintenance of secure Naval computer operations. This presentation is about the challenges and solutions in leading a TSP team to tackle this unique situation.
How is it unique? It is a mix of IT maintenance work and development work, and there is need to track and understand the cost of each. There is a challenge that some team members may have to go out to sea with very short notice - yet there is work ashore that still needs to get done.  The presenter will discuss how to build a process to plan and track these unique situations. The team status meetings are the heartbeat of keeping the team running light and fast.  The presenter will share their practices for keeping this project on-course.

TC-AIM Case of Study: Moving from TSP to CMMI ML3

Oscar Mondragon

This presentation describes the experience of a small Mexican company that is using the TSP as the foundation for implementing the Capability Maturity Model Integration (CMMI) through maturity level 3 (ML3). The company, SILAC, is working with Software Industry Excellence Center (SIE Center) of Tecnológico de Monterrey (Tec) and the SEI to pilot the Accelerated Improvement Method (AIM), a formalization of methods used by other SEI customers to combine the best of two great technologies.

SILAC began operations in May 2006 customizing web applications for administrative domains, for example in government services.  A typical project is between six and 12 months in the implementation phase, about four to seven engineers writing roughly 5,000 to 13,000 LOC. SILAC began using PSP-trained developers in June 2006, and began implementing TSP in December 2007.  The discussion will include the company context, process status, managing an EPG, and the implementation strategy for missing processes.

The AIM project started formally in November 2009 with the launch of the company’s Engineering Process Group (EPG) using the “TSP 2009.09” release and process elements from the unreleased “TSPm 2008.09”. TSPm includes materials for launching and running the EPG as a TSP team, including new roles for the process group that define responsibilities for managing the organization’s set of standard processes (OSSP),  escalating process non-conformance issues, organizational training, and related issues.

The EPG defined four implementation cycles and three main goals for 2010:  a SCAMPI B and TSP evaluation in June 2010, and SCAMPI A examining all ML3 PAs in September 2010.  This presentation will cover the work accomplished through the first three cycles, including a discussion of the additions to “standard TSP” – for example, a custom design template that was developed to strengthen the TSP philosophy and capture the design rationale for each of the new and refined processes, and also such items as the priority for process implementation within the CMMI process categories – project management, process management, and basic support, then followed by the engineering areas and the other PAs at ML3.

TSP or Bust! - The Fight for Emerson

Daniel Roy

For the last 12 years, the author has been teaching and consulting for various components of Emerson, a $20B company that operates 275 manufacturing locations and employs 140,000 persons in 70 countries.

In the face of a reluctant and conservative management, PSP and TSP techniques have been patiently introduced by hooks and crooks and in an exclusively bottom up fashion. Synergy with the company's efforts in ISO and CMM was emphasized to nudge this multi-national company toward PSP. First, PSP planning concepts were instrumental for the first Emerson component to reach CMM level 3 in 2003. Shortly thereafter, this component cut cycle time by a factor four.

Then, major PSP/TSP principles (time management, measurement framework, personal reviews, team planning, and EV) were gradually introduced during CMMI gap analyses and used to plan process improvement in the U.S., the Philippines, India, Europe, and China. Results of his work were presented at the European SEPG in London in 2005. These major PSP principles and TSP-like PP/PMC helped a Chinese component in being the first at Emerson to reach CMMI level 3 in 2009.  However, in spite of a successful full fledged PSP/TSP introduction at Alcatel in nearby Changdu (first official PSP/TSP in PRC, on time delivery, three times improvement in quality, two Chinese instructors and coach certified at SEI) in 2008, neither Alcatel nor Emerson China are committed to PSP/TSP at this time.

PSP/TSP principles have been systematically mentioned at Emerson annual software conference presentations.  A number of divisions are now using SCRUM which forced management to add agile principles to the organization processes.  Process dashboard is now being introduced at every opportunity to keep on the fight.

TSP Symposium 2010 Important Dates

September 20: Exploring the Team Software Process: An Introduction, Partner Workshop Day (by invitation only), and Certification Exams (registration must be completed 24 hours prior to exam administration)

September 21-23: TSP Symposium 2010

Walk-in registrations are being accepted for the TSP Symposium 2010 (including the introductory tutorial, Exploring the Team Software Process: An Introduction). Please proceed to the 17th floor of the Omni William Penn Hotel to register.

Savings for SEI Members
Save 15% with SEI Membership

SEI Members save an additional 15% off the conference fee!  Not a member  Join now »

Another benefit to SEI Membership is The Monitor, a monthly publication exclusively for members. Read the July 2010 issue which highlights the latest work from the SEI's Team Software Process (TSP) program.



Follow us on Twitter! Follow TSP Symposium on Twitter at: http://twitter.com/SEINews


If you have been approved to submit a paper for inclusion in the Symposium proceedings, you can now sign and submit your copyright permission online.


TSP Symposium 2010 For More Information

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.