1.3 Encourage Participation
Participation makes improvement happen. The point of SPI is to change the way practitioners develop software. However, changing human behavior is not an easy task. SPI initiatives provoke the same types of resistance to change as traditional IT implementations (Levine 1997). The factors that make IT projects successful are similar to those that help SPI succeed. The main difference between the efforts is the target customer: IT projects address the way the users work; SPI initiatives address the way software practitioners work.
One way IT projects cope with resistance to change is to encourage user participation. Early in the process, they involve the people whose behavior needs to change (see Figure 1.3). As obvious as this sounds, it is difficult to practice for many reasons. For example, if your SPI customer group is very large—thus making it impossible to involve everyone—who should participate? If you involve only representative practi-tioners, will they maintain the practitioner perspective over the long run, or will they themselves become change agents? Allocating time is also a problem. Software prac-titioners have their own work to do, and SPI work is typically logged as overhead. Given this, do you have a plan for keeping them motivated?
){kind=link}
Figure 1.3 SPI requires participation
Table 1.1 Brüel & Kjær's Requirement Techniques Questionnaire
|
To what extent will this be a change in the way you usually work? |
|
To what extent do you think this will be a change in the way other people at B&K usually work? |
|
Please evaluate this statement: The technique described here is effective and usable. |
|
How certain is it that the use of this technique will lead to the expected prevention of errors? |
Do you have the necessary time in the project to adapt and use this technique?
Examples from Practice
At Brüel & Kjær, participation became the cornerstone for most improvement activities (see Chapter 6). An improvement group analyzed problem reports and identified the most promising requirement specification techniques. But instead of forcing the best techniques on the projects, the support team asked project members which techniques they preferred. Table 1.1 shows the questionnaire the team used to discuss the techniques with project members. Each project then selected five or six techniques. The support team held a workshop and used some of the techniques to elicit and check a requirements specification. Not only did the result lead to better requirement specifications and better products, but also the improvement effort was so successful that many other projects asked to learn the same techniques (see Chapter 18). Letting project members pick which techniques they wanted to learn created the commitment needed for this improvement initiative to succeed.
Another example of participatory improvement comes from Ericsson Denmark (Chapter 3). Ericsson Denmark had long tried to move from one maturity level to the next but had made little progress. This changed when project managers became involved in doing UltraLight Assessments on their own projects (see Chapter 10). Each month, every project manager assessed his or her own project and presented the results to management. Because of project managers' commitment and involvement, Ericsson Denmark successfully advanced to the next maturity level a few months later.
Key Factors
As these examples show, the involvement of professional practitioners and a decentralized improvement effort are key factors in the participatory approach. The intent is not merely to persuade practitioners to practice new processes; you must involve practitioners in actually designing and developing new processes based on their own experiences and professional judgment. When the people who will use the new processes help create them, the processes are much more likely to be integrated into future practice. To succeed, you need more than just good practitioners—you need professional practitioners who are engaged both in getting the job done and advancing the profession.
Decentralizing the improvement effort facilitates participation throughout your organization and helps you to capture and account for local variations in current practices. However, inviting participation can lead efforts in unexpected directions. To see such developments as opportunities rather than threats, your organization must be decentralized because opportunities are much easier to appreciate locally. This, in turn, requires that you be able to coordinate your effort and dynamically adjust your tactics.
A participatory approach is primarily undermined by bureaucracy and firefighting. Strongly formalized assessments and centralized, management-driven SPI programs tend to make things too rigid and distant from practitioners' daily practice on software projects. To support participation, you should limit bureaucratic arrangements and approaches. Bureaucracies are excellent ways of implementing rules and routine, but SPI follows few rules, and it focuses on problem definition and problem solving rather than on routine.
Even when resources are directed toward SPI participation, practitioners are often submerged in day-to-day work, and finding time to participate in SPI activities is difficult. Also, a culture that acclaims firefighters as heroes offers individuals little incentive for investing their time in long-term improvement activities. At the start of Danske Data's 1997 improvement effort, management directed several people to devote 30% of their time to the SPI initiative. At a first glance, this sounds satisfactory. But—not surprisingly—we quickly found that "part time is no time" (Johansen and Mathiassen 1998).
Broader Insights
The idea of participation is well established in the software profession. Mumford's now classical work on involving users in systems development efforts (1983) has had a major impact on the profession. In Scandinavia, participation is now more or less characteristic of systems development. Bjerknes et al. (1987) and Greenbaum and Kyng (1991) provide many examples and practical approaches in support of active user involvement. Unfortunately, user participation often degrades into platitudes such as"build a prototype," "enlist a sponsor," and "create user-friendly interfaces" (Hirschheim, R., and Newman M., 1988). To succeed, participation must go beyond persuasion or motivation; it is a powerful strategy for building useful knowledge and must be treated as such.