By Mark Stockmyer and David Saint-Amand


Abstract

This paper covers the different types of teams the authors have encountered as NAVAIR Internal Process Coaches and how they approached Process Improvement with them, with special emphasis on the curmudgeons (bad-tempered, difficult, or cantankerous persons).

Introduction

There are many approaches to Continuous Process Improvement (CPI). The authors have observed, participated, or assisted in numerous CPI initiatives in both private industry and United States Federal Government service. Those efforts included Agile, Capability Maturity Model-Software (CMM®-SW), Capability Maturity Model Integration (CMMI®), Total Quality Management (TQM), High Performance Organization Training (HPO), Lean Six Sigma, Personal, Software Processes (PSPSM), Rational Unified Process (RUP), the Team Software Processes (TSPSM), and possibly a few others which may have been forgotten. All of these systems have a good chance for success if the people and organizations to which they are being applied are properly prepared, and the initiatives are managed in the same manner as a project. A good example of this would be the use of the ADKAR model, with its five objectives, to prepare for and execute a process improvement effort [1]:

• Awareness of the need for change

• Desire to support and participate in the change

• Knowledge of how to change

• Ability to implement desired skills and behaviors

• Reinforcement to sustain the change

Another good example would be the use of the Software Engineering Institute (SEI) IDEAL model, IDEAL has five steps, the last four of which are repeated in a continuous cycle of process improvement [2]: Initiating, Diagnosing, Establishing, Acting, and Learning.

What can a process improvement coach do though when the proper preparations aren’t made and the people are not effectively prepared in advance? If the success of a CPI initiative for any given team is defined as the whole team undertaking and sustaining CPI, then there are many paths to the adoption of CPI.

When preparing to introduce CPI in this sort of environment, it is important to remember that all pre-CPI teams are different. Some are made up of process champions, while others seem to have only arm-folded curmudgeons. Using our experiences as NAVAIR Internal process coaches we will address the following questions. How are these team types different? How can a process coach take these teams from ad-hoc processes to disciplined superstars? Are special approaches required? Most importantly, and this is where we spent most of our time as process coaches, what kind of techniques can you use to deal with the more difficult teams?

The authors believe that the answers they have found are applicable to most process improvement initiatives. While this article focuses on recent NAVAIR initiatives which utilized the Team Process Integration (TPI), it is because the TPI was able to provide them with data from which to draw conclusions about successful approaches to pursuing CPI.

The TPI is a NAVAIR derivative of the SEI’s TSP. The TSP is a disciplined approach to writing software originally based upon the SEI Capability Maturity Model – Software (CMM-SW). The TPI takes the process scripts of the TSP and strips out the elements that are specific to software development. This leaves a generalized set of process scripts which may be customized and applied to support the planning, project execution, reporting, and process improvement efforts of both software and non-software teams.

To begin the discussion of the different types of teams let us briefly review the by-the-book approach to instituting the TSP familiar to its practitioners. We start with the “Innovators” and “Early Adopters” as defined in the “Innovation Adoption Curve” (Figure 1) [3]. They are willing to try new things, they work hard toward success, and they socialize that success to their friends. Their friends are encouraged to try the new techniques and the good new spreads from there. It has been the authors’ personal experience in both the private software industry and the DoD that this is seldom the approach used. It has been more typical in these working environments for management to simply mandate all teams to use a new process improvement framework. While some teams may respond well to that approach, many do not. Whether they do or not often depends on the percentage of individual ‘laggards’ on a given team. If the team is made up almost exclusively of laggards, we call them “Never Adopters” and a special approach will be required.

Different Working Environments

The by-the-book approach, as described above, was developed by experts who hoped that organizations seeking process improvement would pursue it in an idealized, formal fashion. Some of the characteristics of that idealized approach are:

• the project is new

• the members of the project might never have worked together before

• everyone, from management to the individual engineer, is properly trained and prepared

• the purpose of the weeklong Team Project Planning Session (aka “the Launch”) is to build the team

• the organization has sufficient communication between projects to allow the “Adoption Curve Strategy” to work across the organization

This strategy has been used on numerous teams in the non-Academic environments of both the DoD and private industry. During the course of those efforts some differences between the Academic and non-Academic environments were identified. In general, in the non-Academic environments:

• the project is to enhance and maintain an existing product

• the team already exists and team members have often been working together for years

• in the interest of schedule, importance, and budget, not everyone is trained properly, if at all

• the Launch is used to introduce “Best Practices”

• few of the projects in a large organization talk to each other, making the dissemination of TSP/TPI a grindingly slow process

These differences in environment are important. Depending on the type of team, they can make a by-the-book approach unworkable.

Different Types of Teams

It is said that the first step to recovery is admitting you have a problem. Based on that, we have found that teams may be divided into two general categories, depending on who is doing the “admitting.” Is it the team or their management?

Self-Selected Teams

These are the teams who know that something is wrong with the way the work is being done and they are personally motivated to do something about it. In our experience, these teams will usually identify one of three primary reasons to adopt process improvement:

1. To fix broken management: Irrational management has created a chaotic environment

2. To obtain a process the team will use: The Team Lead has worked on teams with good processes and wants their new team to start out on the right foot

3. To save the broken schedule: The product is chronically late and the team as a whole decides that they need a way to judge their progress.

Management-Selected Teams

If it is the management that decided there is a problem, which they think may be solved by process improvement; it is usually for one of the following reasons:

1. To fix the broken team: They have teams where the product is never delivered or, if it is, the product doesn’t work

2. To introduce best practices: Management read about a process improvement framework in a White Paper

3. To gain insight into the schedule: Their teams are unpredictable and product delivery is never known until the last minute

It has been our experience that Management-Selected teams are typically neither convinced to, nor properly prepared to undertake process improvement. They are instructed to do it. Some teams will take this new effort on willingly, but the Never Adopters will not. The probability that these types of teams will be successful in the pursuit of mandated Continuous Process Improvement can vary widely.

Introduction Strategies for Self Selected Teams

Self-Selected teams, by their nature, are generally not difficult to deal with and can be expected to attempt to take on all the TSP or TPI practices from the start. A coach should not have to spend much time with them outside of what might normally be expected. These are the teams where the Innovation Adoption Curve works, and for which TSP coaches are trained.

In general, the team’s chance of success is good, but not always.

Self-Selected: Fix the broken Management

Occasionally, an engineer from a disciplined team joins a new team and the new surroundings are not that for which they bargained. The engineer figures out too late that the new environment is not quite as disciplined as they had imagined, but at least they figure that they can control their own world.

There is a low chance of success here because it is likely that, intentionally or unintentionally, management itself is fostering an environment of chaos and will oppose attempts to introduce discipline.

Is there a good reason for a person to pursue process improvement in this environment even though the chance of success is low? Yes. That person builds a record of their attempt at discipline and that will serve them well later on when the project fails and management is attempting to assign blame. One of the authors of this article assisted an engineer in this situation, and because that engineer had planned, documented, and tracked their work, they were recognized by upper management as a competent, honest, and diligent employee: complaints lodged against him by his irrational manager notwithstanding.

Self-Selected: Obtain a Process the Team Will Use

In this instance the team lead is an innovator, an early-adopter type, or a person who may have formerly worked on a high-discipline team. They understand that chaos is a poor product development strategy. They want a team process and are willing to try new things. As the new team lead they have an opportunity during their new Team Lead “honeymoon” period to introduce CPI and they make the most of it.

The overall chance of success in adopting Process Improvement is high.

Self-Selected: Save the Broken Schedule

In this instance, an entire team comes to a consensus that something is wrong, be it schedule, cost, or quality. Not only do they admit they have a problem, they are willing to accept change in order to find a better way to do business.

The overall chance of success in adopting Process Improvement is high.

The Management-Selected Teams

Teams are usually selected for Process Improvement when management:

• Understands there is a problem with a team’s performance

• Hears about other teams’ success with process improvement

• Wants a process coach to fix their broken team

Management-Selected teams all respond to the new CPI initiative in pretty much the same way and are the process coach’s biggest hurdle. They are often staffed with experienced professionals who have seen many Process Improvement flavor-of-the-month initiatives start and fail, or worse, start and be abandoned with the next change in management. If a process coach tries using the by-the-book approach with these teams, the probability of success is low. This is because the Canon of this approach often runs squarely into the Reality of the work environments of the DoD and Industry (Table 1). It is because these teams can be such a challenge for a process coach that the remainder of this article will focus on them.

It is likely for the Management-Selected teams that at least one member of the team with significant professional experience will be cynical and has learned that the best strategy for avoiding “work disruption” is to passive-aggressively resist the latest initiative. If all the members of the team fit that description then the process coach has entered the “Never-Adopters” portion of the Innovation Adoption curve. A coach will spend much more time with these teams than with a self-selected team, and the bulk of that time will be a seemingly endless effort to cajole the team into complying with the initiative.

For the Never Adopters, the introduction of process improvement must be done slowly and incrementally. Overwhelming them with process will just give them the ammunition they need in their complaints to management that what the process coach is asking cannot be accomplished and still expect them to get work done. Worse, the ferocity of their passive-aggressive resistance will blind them to any value there is from the process improvement initiative. At best, they will do the very minimum they can get away with and still be seen to be complying. In some cases they may even outright refuse to participate. Then, after the initiative collapses due to the team’s intentional failure to perform, they will point to the lack of progress and data and say that the process is a hoax. They will say this even in the face of evidence of other team’s successes with the same initiative. Typically their explanation is that their work is unique and not at all like the other team, whose success is either some sort of very-specific lucky break, or an outright lie.

In a further effort to justify their failure, they will spread this word throughout the larger organization and that will “poison the well.” As a result, the organization will be less likely to try that brand of process improvement in the future and the coaching organization will lose other process improvement opportunities.

If management keeps up the pressure for process improvement, despite the manufactured failure and team complaints, then there is a risk of the organization losing valuable corporate knowledge through early retirements and lateral transfers.

So, if taking the by-the-book approach is likely to produce poor results, will rolling out process improvement in small doses really result in long-term success? If the goal is to change the culture and improve the practices of an organization, then the experiences of the NAVAIR Process Coaches suggest that the answer is ‘Yes.’

Introduction Strategies for the “Never Adopters”

Everyone knows, from the manager who orders it, the process coach who has to introduce it, and the team who has to implement it, that they are eventually going to have to eat the entire process-improvement elephant. So, how do you get the “Never-Adopters” to undertake the effort? The key is to convince the team to agree to try a bite of the trunk, just to see what it tastes like.

Ask the team to:

• plan their work: introduce the team to projects with detailed plans

• track their work: start to instill process discipline

• think about Quality: get them to consider the possibility of building on the process

From this modest introduction, the process coach wants the team to come to understand that collecting performance data is neither difficult nor time consuming, that their performance data will not be used against them, and that there is value for them personally in the data which they are collecting.

Introduce Planning

Of all the process improvement practices this brings the greatest benefit, but it is not a common practice: have the team who will be creating the product build the project development plan. Many engineers in industry and the DoD have never seen a detailed plan, let alone participated in making one. The planning effort might not be considered much fun at first, but the resulting plan will be popular. Here are two quotes from the end of one such planning session:

“This is the first time I’ve known what I should be doing on this project.”

“We should always have a plan.”

Start the project team off with basic planning techniques. Have the team create a task list, estimate task size in terms of time and keep the workflows, if there are any, simple.

Introduce Tracking

Now the team has a plan, how are they going to track progress? Have them use a project tracking tool. There are a number of commercial programs available, and several of them are free to use. By using one of these tools, each member of the team will record their personal time against their tasks, and mark those tasks as completed when they are finished with them. Emphasize to the team that tracking their own work will, with very little effort on their part, provide them with personal insight into the following areas: Time on task, Earned value, Schedule progress, Forecasts, and Accuracy of estimates.

Introduce Quality

Will a team have good quality assurance practices right from the start? That is unlikely. Will they have a quality product? That depends. Their quality will probably be better than in the era before they started to make detailed plans, if only because their software interfaces are usually better defined. The key is that the process coach starts the discussion on quality which primes the team for introducing more disciplined quality practices later on.

Build on the Process

Will the team have high-quality personal data at the end of the first project cycle? Probably not. Most likely they weren’t too diligent in recording their own data, but it is still data. After the first cycle, the team members will begin to see that their plans have useful information in them, and they will see that the data wasn’t as good as it could have been. Most engineers like data and the desire for better data encourages them to improve the way in which they have been tracking their effort. It also leads them to begin wondering “if this data is useful, what else might I track that would be of interest?” They begin to think “if some process isn’t bad, more process might be better.” It is in this way that individual members take themselves from ‘Process Resistors’ to ‘Process Defenders’ and then on to ‘Process Advocates.’ Once that starts, the team is on the road to higher performance.

Team Results Over Time

So, the strategy outlined for introducing CPI to Never-Adopters is to start them out with simple processes and build on them over time. It will certainly take longer, but will it actually produce positive results? The answer is yes, as the results of the efforts of two different types of TPI teams will show: a team of software testers, and an Interdisciplinary team of Software, Electronic, and Mechanical engineers.

Team A: The Software Test Team

Figure 2 shows how a team of software product testers fared over time in their tracking of the actual hours associated with their Task Time. The first chart shows the data for the first TPI cycle, and the second for the fourth TPI cycle: a span of two years. The red lines represent the planned accumulation of task hours as estimated during the launches. The blue lines are the actual number of task hours as logged by the team during the project cycles.

If you move the Actual line of the fourth project cycle to the left to account for the delay in the start of testing, you can see that the team is accurately estimating their availability to work on the effort.

Figure 3 shows how the team fared in tracking their earned value (EV) over the span of the same four project cycles. The red lines represent what was planned at the launches. The blue lines are the EV that the team accrued during the project cycles. The green lines are the actual cost of that EV in terms of hours.

While the actual EV never matches the EV progress as anticipated by the planning tool, the actual EV and the actual cost of that EV are very close. As a result of using the TPI, this team is able to accurately estimate the size of their tasks, even though they were estimating solely on the basis of time.

Team B: The Interdisciplinary Team

How well did this approach work for the interdisciplinary TPI Team composed of software, electronic, and mechanical engineers? The results can sometimes be startling. Figure 4 shows the team’s performance during their first TPI cycle. The red line represents the planned accumulation of task hours as estimated during the launch. The blue line is the number of task-hours as logged by the team.

It is all the more impressive as they had only one day of TPI training.

The outcome is equally exciting for their EV tracking (Figure 5), where the tasks were, for the most part, simple tasks estimated in units of hours or days, not Source Lines of Code (SLOC) or some other more direct measurement. The red line represents what was planned at the launch. The blue line is the EV that the team accrued over time. The green line is the actual cost of that EV in hours.

What About Quality?

It has it been our experience that convincing the never-adopter teams to perform quality assurance practices, other than the usual test-and-fix, has been one of the most difficult areas of our CPI efforts. At the time that this article was written, some of our teams had on their own initiative taken on peer reviews, and they do seem to be more open to additional quality control practices, but they are just getting started on this part of their journey. It is too early yet to know what sort of progress to expect.

Changes in Attitude

It was hinted at earlier in this article that if a process coach took the incremental CPI path, the team members’ attitudes towards process improvement would become more positive over time. The evidence for that change in attitude may be found in a comparison of selected comments collected from the launches and postmortems of four six-month project cycles of four TPI teams (Table 2).

The teams went into their first project cycle launch with the idea that it would be a useless, miserable experience. They left feeling that:

• it wasn’t unbearable

• they had some control over their work

• the plan generated during the launch was their plan

• they would like to have had more detail in the plan

By the Second and Third project cycles the launches are taking less time, and now that they know what to expect, are beginning to seem easy. More importantly, to the process coach anyway; the coach has gone from being seen as the common enemy to being part of the work environment. In essence they:

• worked together as a team and enjoyed it

• found the rigor of the new processes to be beneficial

• liked that there was data to analyze

• wanted better data from the next cycle

The Fourth cycle comments suggest that after two years of following the incremental CPI path, the project launches are now easy, safe, and relatively fun. The teams:

• have historical data they can use to estimate their future work

• are beginning to take control of their current work

• are working together to create the plan and iron out the unclear parts

• understand that process improvement is saving them time- and-effort

These results are evidence of a strong improvement in team’s attitudes towards CPI.

Final Comments

The long-term goals of Process Improvement should be to introduce and sustain a culture of continuous process improvement. The results of the incremental approach used by the authors suggest that not all teams have to take the steep path towards that goal. After several years of coaching Never-Adopter teams, NAVAIR Process Coaches have seen steady improvement in the ability of their TPI teams to estimate their level of effort and schedule, and have seen positive changes in team member’s attitudes towards process improvement. While the journey for these teams is not yet over, it appears that by taking the slow, incremental path, reluctant teams may be able to make themselves into process-improvement-oriented teams which actively search for ways to do business better.

Disclaimer:

CMMI,® CMM,® PSP,SM and TSPSMare registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.


References and Notes

1. Hiatt, Jeffrey M. ADKAR: A model for Change in Business, Government and our Community. Loveland, CO: Prosci Research, 2006.

2. McFeeley, Robert; IDEAL: A User’s Guide for Software Process Improvement. Software Engineering Institute, Carnegie Mellon University, 1996.

3. Rogers, E. M. Diffusion of innovations (3rd edition). New York: Free Press, 1983.


David Saint-Amand

Click to view image

David Saint-Amand is a Team Process Integration (TPI) Coach with the Naval Air Systems Command Process Resource Team. His previous positions include DCS Corporation Section Manager, Naval Operations Research Analyst, and Engineering Geologist and Seismic Safety Consultant. He holds a B.A. in Geology from the University of California at Santa Barbara with a secondary emphasis in Computer Science. He is a Defense Acquisition University Certified Level III Life Cycle Logistician and an SEI-Authorized PSP Instructor.

Mail Stop 6308, 1900 N. Knox Rd.

China Lake, California 93555-6106

Phone: 760-939-2372

FAX: 760-939-0150

E-mail: David.Saint-Amand@navy.mil

Mark Stockmyer

Click to view image

Mark Stockmyer is the Software Lead for the OASuW (Offensive Anti-Surface Warfare) Technical Project Office at the Naval Air Warfare Center in China Lake, California. His previous positions include Fire Control System software engineer for the SPIKE missile project and systems software engineer at TouchNet Information Systems, Inc. He holds an M.S. degree from the University of Kansas in Computer Science and B.S. degrees from Missouri Western State University in Computer Science and Chemistry. He is an SEI-Authorized PSP Instructor.

Mail Stop 6612, 1900 N. Knox Rd.

China Lake, California 93555-6106

Phone: 760-939-3979

E-mail: mark.stockmyer@navy.mil

Mark Stockmyer

Click to view image

Mark Stockmyer is the Software Lead for the OASuW (Offensive Anti-Surface Warfare) Technical Project Office at the Naval Air Warfare Center in China Lake, California. His previous positions include Fire Control System software engineer for the SPIKE missile project and systems software engineer at TouchNet Information Systems, Inc. He holds an M.S. degree from the University of Kansas in Computer Science and B.S. degrees from Missouri Western State University in Computer Science and Chemistry. He is an SEI-Authorized PSP Instructor.

Mail Stop 6612, 1900 N. Knox Rd.

China Lake, California 93555-6106

Phone: 760-939-3979

E-mail: mark.stockmyer@navy.mil


« Previous Next »