Learning SPI in Practice
According to the common rhetoric of software process improvement (SPI), there are a few basic steps to improving your software development process. First, you assess your organization's current capability to develop quality software. Based on this, you derive a stepwise, focused strategy for improving this capability. You then make improvement efforts an integral part of your organization's long-term goals. The result? Both the quality of your services and the productivity of your processes increase.
SPI rhetoric is certainly powerful and appealing, and it inspires many software organizations to engage in improvement initiatives. However, even though most organizations struggle to meet expectations, many of them eventually fail.
Starting SPI is not difficult. You begin by assessing your current processes. Typically, enthusiasm at this point is high. Most of your colleagues will be eager to learn about the strengths and weaknesses in the way projects are organized and carried out. However, turning assessment insights into action is the point at which many organizations fail. Others manage to initiate focused improvement projects, only to find that implementing new ideas is very difficult (see Chapter 15). Even when you succeed in implementing an idea in an individual project, you are still a long way from institutionalizing improvements. In addition to the predictable challenges at each stage, you're likely to encounter other challenges. These include conflicts between SPI efforts and other traditional improvement initiatives, and the tendency for resources to grow scarce as the first wave of energy for SPI dies out. Clearly, SPI success involves more than simply choosing the right methods and collaborating with the best experts (see Chapter 16).
The authors of this book have all been actively engaged in SPI research and practice for several years. Our experiences have taught us what it takes to go from SPI rhetoric to success with actual initiatives. In some ways, SPI's main goal works against success: SPI seeks to change existing practices. In this change process, deeply rooted values and traditions—including traditional improvement efforts—are necessarily critiqued and challenged. For most organizations, SPI is a radically different improvement philosophy, and as such it must be learned. Learning SPI can help you prepare for the changes and challenges ahead.
How does SPI differ from traditional approaches to improvement? Based on our experiences, we have identified five core SPI principles. These principles express SPI's underlying values—values that organizations must adopt to succeed with SPI. The five principles are
- Focus on problems.
- Emphasize knowledge creation.
- Encourage participation.
- Integrate leadership.
- Plan for continuous improvement.
Practicing these principles is an acquired skill. We examine each principle in more detail and discuss the factors that support and undermine them. We also provide insights drawn from the broader field of organizational learning that help explicate each principle's underlying rationale.
1.1 Focus on Problems
Problem solving is the essence of improvement. SPI starts with an organization's existing practices. SPI practitioners diagnose these practices to evaluate their strengths and weaknesses; then they identify and prioritize possible improvements and establish teams to design and implement new or better processes. Practice is the SPI group's starting point as well as their goal, and their customers are practitioners, be they software engineers or software managers. Figure 1.1 illustrates the problem orientation of SPI efforts.
){kind=link}
This SPI principle has several immediate implications:
There are no generally-applicable solutions. The SPI group must take into account the organization's specific traditions, values, and capabilities.
Many different and competing viewpoints are involved. Different actors and groups within the organization have different perceptions of the problems and of the usefulness of possible solutions.
The ultimate measure of success is practice. Is the SPI initiative actually improving the organization's capabilities? The SPI group must constantly ask this question to keep an improvement initiative on track.
Figure 1.1 SPI should focus on problems
Examples from Practice
For years, Danske Data's methodology department had developed methods and tools to support software practices. Its first SPI assessment showed that these methods and tools were state-of-the-art. However, as Chapter 5 explains, few projects used the tools and methods. Furthermore, the methodology department did not feel obligated to ensure that its inventions were used. The SPI initiative questioned the department's tradition of solution orientation. How well did the department members understand current practices? What did they conceive as the result of their efforts? What were their underlying success criteria? Such questioning led to many discussions and ultimately to changes in both the improvement efforts and the methodology department.
Brüel & Kjær's project managers were skeptical about using methods and were in no way motivated to engage in improvement programs (see Chapter 6). Because project managers were key players in the organization, their attitude toward SPI was crucial to the effort's success. The SPI group had no choice but to build a constructive alliance with the project managers. They therefore decided to engage project managers in a dialog to identify their most immediate problems and needs.
Key Factors
Organizations that are learning to be problem-oriented should start with perceived problems and build diagnostic competence. To identify problems, SPI group members must understand and address the software practitioners' perception of which practices need improvement. Two obvious strategies help here. You can analyze and formulate problems and develop improvements in direct response to practitioner perceptions, and you can engage practitioners in dialog about other, less obvious, but equally important improvement issues.
Building diagnostic competence also facilitates a problem orientation. Your SPI group should have the drive and skills to identify problems in current practices. You should develop and maintain strong relations to practice, know how to relate problems to possible causes, and relate possible improvement actions to specific problems. You can use appropriate methods—such as assessment techniques (Chapter 7) and problem diagnosis (Chapter 9)—to build diagnostic competence into your group, or you can import the competency by inviting people with relevant backgrounds and experience to participate.
Factors that undermine problem orientation include the silver bullet syndrome and a general disrespect for SPI among software practitioners. Traditional methodology departments typically believe that they can resolve problems by applying technology. Their primary strategy is thus technology push. This silver bullet approach is rarely compatible with problem orientation.
The problem-oriented approach is also undermined when SPI or the SPI practitioners lack credibility among software practitioners. A negative image of SPI among practitioners can result when the SPI group offers too little or inappropriate information, does not demonstrate useful results, or fails to interact with software practitioners.
Broader Insights
The underlying rationale for a problem-oriented approach to SPI conforms with general lessons from organizational learning. Argyris and Schön (1996) suggest that the real challenge in any form of organizational learning is to effectively address the gap between espoused theories and theories-in-use. Espoused theories express what people believe and think they do; theories-in-use is what they actually do. Hard as it is to admit, most of us realize on some level that self-deception, lack of discipline, and environmental factors often make it difficult to follow best practices. We keep doing what we are used to doing even though we know that other approaches are more effective.
As individuals and as organizations, we are constantly facing the challenge of understanding and bridging the gap between espoused theories and theories-in-use. State-of-the-art software engineering knowledge is not the only nor the most important source of learning. The key to effective organizational learning is to understand the difference between what we already know we should do and what we actually do. With problem orientation, we confront that gap. If we don't, we risk getting stuck with general solutions and personal beliefs.
Many methods can help you practice a problem-oriented approach. Widely known in the SPI community, the IDEAL model—Initiate, Diagnose, Establish, Act, and Learn—describes in detail a problem-oriented model of how to organize SPI (McFeeley 1996).
You can also use other, more general approaches to inspire your SPI initiative. One approach is Soft Systems Methodology (Checkland and Scholes 1990), which applies rich pictures, multiple perspectives, system modeling, and debates to drive complex problem-solving processes. This method takes as a starting point an unstructured situation in which problems have yet to be identified. Thus, problem owners and their different perceptions of problems play a key role in the process.