NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: February 1, 2007
This is the seventh and final column in a series on large-scale development work. Part I introduced the structural problems of the massive organizations that typically do large-scale work. Part II addressed the management decision process, why this process is critical for large-scale work, and how to fix it if it is broken. Part III discussed how to get things done in a bureaucratic organization, and Part IV addressed the need for teams to take charge of their own work. Part V then described self-directed teams and how their planning and self-management skills help them to consistently produce superior results. Part VI discussed the requirements a process must satisfy to consistently and predictably produce high-quality large-scale systems. This column discusses how to get the developers to follow their selected processes in doing their development work. As we will see, this challenge is not trivial, but it is also not hopeless.
In Part VI, we discussed the requirements for a process that will predictably produce high-quality large-scale systems. In summary, the five basic requirements are to
While the actions required to accomplish all of this are not particularly complex, they do require that all of the systems, software, and hardware developers and their teams consistently follow certain essential practices. The five required practices are to
For people to work in this way, they must have the proper skills, be highly motivated, and have the leadership and support to consistently do superior work.
The skills required fall into three categories: technical, project, and quality.
Technical Skills—Although the required technical skills are by far the most complex, difficult, and time-consuming to learn, they are not usually the source of most project problems. Technical topics are the principal focus of current academic curricula, and these are the topics the developers find most interesting. Yet even though insufficient technical skills are not usually the cause of project problems, when such skills are insufficient, projects invariably have problems. In short, suitable technical skills are essential, and without them, even the most motivated and best-led and supported teams will not likely succeed, at least not on predictable schedules.
Project Skills—Project-related skills principally concern estimating, planning, tracking, and configuration management. While these skills are relatively easy to learn and can be taught in only a few days, without them, developers and their teams cannot do predictable work. The main reason that such skills are not required on most projects is lack of understanding by the developers and their management. Technical professionals are not taught self-management skills during their educations. While this self-management problem has been particularly serious for software, it is also a problem for every development discipline.
This is an unfortunate failure because truly superior work is invariably done by people who manage themselves. Unfortunately, if technical professionals do not know how to manage themselves, their managers have to manage them. Then the managers make the plans, define the commitments, allocate the work assignments, and monitor work status and performance. If this does not sound like a fun way to work, that is because it isn’t. The only way out of this trap is for developers to start planning and managing their own work.
Quality Skills—While quality problems are not new to the systems-development business, the character of these problems has changed. Early systems had thousands of largely identical parts, and all of these parts were interconnected by wires. The quality challenge at the time was twofold: to find parts of high enough quality and with sufficiently long expected lifetimes to get the systems to work. Then, the priority was to ensure the quality of all the connections among these parts. A useful early test was to literally shake these systems and, if there were intermittent errors, look for and fix the bad connections.
With integrated circuits, these early quality problems were largely solved. Now, the problem is with the multiplicity of part types. We used to have hundreds to thousands of copies of a relatively few part types, but now we also have thousands of different designs. Of course, with thousands of anything, you potentially have quality problems. These problems were first apparent with software, where we never had standardized parts and every module was unique. Large software-intensive systems have always had thousands of parts, and with really large systems, we now even have millions of different designs that all must work correctly.
With software, quality problems have been serious, but they have always been simpler and easier to fix than hardware quality problems. The reason is that, because the costs and time delays associated with fixing a defective software component were much less severe than with fixing defective hardware, it has been practical to fix software components during testing. With hardware, it is impossible to fix defective chips during testing. As a result, hardware quality has traditionally been viewed as a manufacturing problem and not something that the developers needed to worry about.
With embedded software and with software logic now widely used in hardware design, software quality problems are becoming pervasive in the hardware world. They are also becoming as time-consuming and expensive to fix as traditional hardware problems. In fact, nearly a decade ago, an auto company executive told me that the company had started to make hardware changes to avoid changing the software. So we must all learn to adopt sound quality-management skills. The hardware designers must learn from the manufacturing community, and the software engineers must participate in this learning process.
The skills required for quality management are relatively simple, but they are not easy. All that is required is to use a precisely defined personal process, to track and record every defect, and to use these defect data to modify the process both to prevent defects and to find and fix almost all of the defects before the start of testing. The manufacturing community has defined and refined the required practices. Now the development community must begin to adopt these practices. While this is partly a training problem, the training is relatively simple and can be completed in a few weeks. The most difficult issues are motivation, leadership, and support.
There is only one motivational requirement: motivating the systems, hardware, and software developers to adopt and consistently use sound quality methods. To do this, these developers must be trained in quality-management skills, and they must work on teams in which all the members follow these same practices. However, because gathering and using data are important parts of quality management, and since it is essential that these data be accurate and complete, developers must be interested in their data and motivated to gather and use these data to manage their personal work. If they are not, the data will almost certainly be incomplete and imprecise. Finally, and most important, the entire management team must both motivate the developers to follow their team-defined quality practices and refrain from using any of the resulting data in any way that threatens the team members. The need is for the kind of trusting environment that makes creative work possible. While a trusting environment is important for all engineering programs, it is essential for large-scale work. Without trust, there is only limited communication, and without communication, large programs cannot be managed.
Leadership is the key, but leadership is different from managing. Napoleon, when asked how he made his army cross the Alps into Italy, said: “One does not make a French army cross the Alps; one leads it across” [Humphrey 1997]. Leadership requires vision, an ability to define compelling goals, and the foresight to adopt improved practices and methods before they are widely adopted and before the need to use them has become obvious. Leadership involves setting goals, defining directions, and exciting the troops.
In leading large-scale operations, all of the traditional leadership practices are essential, but they are not sufficient. With large engineering programs, the leadership challenge is to build a cooperative management culture that enables rational fact-based decision-making and minimizes political infighting. In one example, the manager of one part of a large program encountered an unanticipated problem and needed additional resources. When he explained this to the leadership team, we knew that we could not expect help from anyone else; we would have to fix the problem ourselves. The managers then asked me to leave so they could try to work out a solution among themselves. When I returned, they had solved the problem. Each manager had looked in his own group to identify any lower-priority work and had either cut or delayed it. With the right kind of culture, managers know that they will get help when they need it and are generally willing to help others when they can.
Leadership is about more than just setting direction, taking risks, and motivating the troops. It involves building a trusting and cooperative culture. It must also recognize and reward superior work. This requires that the developers be properly trained, encouraged to manage their own personal work, have the right kind of support, and be properly recognized and rewarded. This, of course, means that the leaders must know what superior work looks like, look for and identify such work, and ensure that it is properly rewarded.
The final need is for support. In addition to the support provided by proper training and effective leadership, there is the need for coaching support. In sports and the performing arts, we all recognize the need for coaches. In fact, when a team is doing badly, it is always the coach who gets blamed. The coach, conductor, or director is the one who guides, motivates, and challenges the team members. However, we in the development community have been slow to recognize the need for coaching support.
Regardless of the field, whenever it is important for people to do consistently high-quality work, teams need coaching support. It is hard to do complex and creative work, and it is doubly hard to do it with extreme care and precision. If no one notices or cares about what we do or how we do it, it is almost impossible to maintain a high level of personal performance. That is when coaching is truly essential: to provide the support, encouragement, and guidance required to maintain motivation and dedication. Without motivation and dedication, there cannot be superior performance.
This concludes this series of columns on large-scale work. Large-scale engineering work involves many challenges. It requires properly designed and structured organizations, sound and minimally bureaucratic decision-making processes at every level, balanced and participative management systems, well-designed and structured development processes, and the leadership and coaching support required for consistently superior work. The methods and practices required to do all of this are well known and available. The principal challenge is to do it.
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Bob Cannon, Julia Mullaney, Bill Peterson, and Alan Willett.
In this particular series of columns, I have discussed some of the development issues related to large-scale projects. As I now consider the topics to address in subsequent columns, I would appreciate any of your comments and suggestions. If there are topics that you feel are particularly important and would like to see covered, please drop me a note with your comments, questions, or suggestions. Better yet, include a story or brief anecdote to illustrate your ideas. I will read your notes and consider them when planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
Humphrey, W. S. Managing Technical People—Innovation, Teamwork, and the Software Process. Reading, MA: Addison-Wesley, 1997.
Humphrey, W. S. TSP: Leading a Development Team, Reading, MA: Addison-Wesley, 2006.
Watts S. Humphreyfounded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and several books. His most recent books are Introduction to the Team Software Process (2000) and Winning With Software: An Executive Strategy (2002). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.