underlying theme is that by understanding and defining the current state of a company's software development processes, quality practitioners and managers ...
Implementing a people focused SPI programme Nathan Baddoo, Tracy Hall, David Wilson
Abstract Software Process Improvement (SPI) has become the most popular approach to delivering improvements to the software product. Based on statistical process control, the underlying theme is that by understanding and defining the current state of a company’s software development processes, quality practitioners and managers can sufficiently determine and control areas within the development process to achieve improvements in the product. We support this general approach to SPI. We also believe that the people factors in SPI implementation are vital. We believe that to achieve greater success in software process improvement initiatives, greater attention needs to be paid to the perspectives and attitudes of software practitioners. However, we believe that different groups of practitioners have different experiences and attitudes towards SPI. We present preliminary evidence from our study of UK companies. We present the obstacles and motivators to successful SPI from the perspective of three groups of practitioners: strategic management, operational management and grassroots level practitioners. We find that grassroots practitioners believe that SPI generates increased workload due to the amount of documentation required by current models. We also present evidence of positive influences and motivators to SPI that we have come across in companies. We find that giving practitioners ownership of the processes to be improved encourages them to be more responsive towards the improvement programme. We draw together the common issues in the study and argue that time, financial commitment and practitioner buy-in are critical to the success of SPI programmes.
1. Introduction Software process improvement (SPI) is an approach to software product improvement achieved through making improvements to the development process. SPI is currently very popular and leading models like SEI’s CMM [7] and ISO’s SPICE [8] appear to be at the forefront of this approach. We support the concept of SPI and believe that process improvements do indeed lead to better quality software. We also believe that the perspectives, experiences and general attitudes of practitioners towards SPI programmes significantly influence the success of these programmes. We believe that to achieve greater success in SPI initiatives, more attention needs to be paid to such practitioner factors. However, we suspect that companies are overlooking such critical people management factors when they implement SPI. Over the past year, we have been conducting studies in a number of companies with groups of software practitioners about their views, perceptions and experiences of software process improvements. This is part of a three year project on SPI1. In this paper we present preliminary findings from this research project. In this project, we follow up on work that we have done previously in the area of assessing practitioner attitudes towards software quality improvement initiatives [4], [10]. In this paper we focus on the views of three groups of practitioners: strategic management, operational management and grassroots level practitioners. We have identified in earlier work that there is misalignment in the perspectives and attitudes of these separate groups of practitioners towards SPI programmes [4]. We have undertaken to propose approaches to 1
This project has been funded for three years by EPSRC under grant number EPSRC GRL/991962
373
reduce this attitudinal misalignment. By focusing on these separate views we are able to identify commonalties and differences and are able to isolate issues that need to be addressed in order to reduce such misalignment. In this paper we present the three separate views on the obstacles and motivators to implementing successful SPI. The paper is structured thus: In Section Two we present an overview of our project. We describe the aims and objectives of the project. We introduce the range of companies involved in this study in terms of size, main business function and operational complexity. We also discuss the research methodology applied in this study. In Section Three we present preliminary findings of factors that act as obstacles to the success of SPI in companies. In Section Four we report on what companies are doing to motivate their staff to participate in SPI initiatives. In Section Five, we draw conclusions by pulling together the common issues that have emerged from our study across the three practitioner groups.
2. Project overview 2.1. Companies This study is a continuation of empirical work that we carried out with software developers in UK companies three years ago [4]. In what served as a pilot to this project, we sampled and collected data from a cross section of practitioners from five UK companies. The pilot study led us to be particularly interested in the attitudes of software practitioners at grassroots, operational and strategic levels of companies. The findings of that pilot serves as the basis of our current work. In this study, we are testing the pilot findings on a larger group of UK companies. We have expanded our study to collect data from three groups of practitioners in twenty companies. So far, we have collected data from fourteen companies. In this paper, we present preliminary findings of the data collected from ten of these companies. The companies are of varying operational complexity, ranging from small software houses to large multinational companies.
2.2. Methodology We made use of social science research methods to measure and analyse practitioner attitude. We collected attitudinal data via various social science research methods including focus group discussions, questionnaires, structured interviews and Repertory Grid Technique (RGT) [2]. In each company we met with groups of between six and ten practitioners from each level of decision making. We also conducted in-depth interviews with the people co-ordinating the SPI programmes. In the following section we describe the research methods used and how they were implemented in this study. 2.2.1 Repertory Grid Technique The Theory Repertory Grid Technique (RGT) is an investigative technique employed as a rigorous system of data collection [2]. RGT examines and records the personal construct: an individual's hypothesis about a given situation. These hypotheses are formed through the individual’s experiences. RGT allows the subjects of an investigation to reveal their hypotheses without any influences from the investigator. It enables researchers to understand how subjects have arrived at their perspective on a given situation which allows the researcher to uncover the "building blocks" of an opinion. In theory once this has been established, the researcher can then manipulate these building blocks to alter the subject’s attitude towards the given situation or set
374
of circumstances. By employing RGT in this project, we are able to uncover how software practitioners arrive at their views on software process improvement initiatives. The practice We implemented group sessions with three groups of practitioners: The first group was made up of software developers/ testers /designers. The second group was made up of project managers/middle managers/team leaders. The third group comprised senior managers. We choose these groups in Part One of this session. In Part Two of the group sessions we used the Repertory Grid Technique to elicit participants’ personal constructs about key elements of software process improvement. These included: Metrics, Reviews and Inspections, Certification and Standards and Procedures. 2.2.2 Structured interviews Structured interviews allow the researcher to present the same set of questions to the different interviewees in the same format and the same order [1]. Structured interviews establish a clear picture of a given situation and provide key pointers to how to extend the research. They are useful in obtaining objective context setting information. In this study we used structured interviews to obtain objective context setting information from software quality managers.
3. Obstacles to SPI In this section we discuss the issues that are of particular concern to software practitioners across the companies we visited. We describe the factors and circumstances that practitioners view as obstacles to the success of SPI programmes. In earlier work, we have discussed the difference in attitude and behaviour that three practitioner groups exhibit towards software quality initiatives: senior managers, middle managers and developers [4] and undertaken to propose approaches to reduce this attitudinal misalignment. Hence in this section, we present what practitioners believe to be the obstacles to successful SPI programmes from those three perspectives: strategic, operational management and grassroots. The result is an aggregated view across the ten companies. 3.1
A strategic level perspective
3.1.1 Inability to create the bandwidth for process work Practitioners must feel that the time apportioned to process work has been factored into their job plans and schedule. In our study thus far, we have had discussions with practitioners who feel that “cutting code” is the only way they can be seen to be productive. Thus it is important to make the point officially that for example, documenting procedures, per se, is as vital as time spent doing other development activities. 3.1.2 Lack of funds Senior management in the study believe that by far the biggest obstacles to software process improvement is the lack of financial resources. Even when the finances are available, management are hesitant to make the financial commitments to implement SPI programmes. 3.1.3 Lack of the technical know how Senior management also feel that even when the necessary commitments are made, they often find that the organisation lacks the skill base to direct the SPI programme. One manager
375
expressed this problem this way: “ We don’t have in high supply the skill of being able to manage SPI. You need to have someone to manage the change”
3.1.4 Time Senior management feel that on the whole practitioners are willing to change and will welcome any changes that will make their lives easier. 3.1.5 Organisational changes Most of the companies we have visited in this study have undergone some sort organisational change recently. The feeling amongst senior managers in these companies is that too frequent organisational changes are not helpful to the institution of SPI programmes. These changes happen too often and make building upon past successes difficult.
3.2
Operational management perspective
3.2.1 Investment There is a general feeling amongst operational management in the companies that we have visited that top level management is committed primarily to profit and hence find it difficult to make the necessary investment in SPI: a programme with no immediate direct benefits. 3.2.2 Effort Operational management feel that instituting a SPI programme can be seen as, firstly, requiring too much effort to replace existing practices and, secondly, disruptive to product development. 3.2.3 Inertia Operational management across the companies in the study feel that practitioners are generally reluctant to change. They believe that practitioners are set in their ways because they have not been given sufficient evidence of the improvements that SPI can bring. And thus there is generally a disbelief that improvement will actually occur. 3.2.4 Lack of process ownership Operational management believe that practitioners are less likely to be fully enthused about carrying out processes they do not own. 3.2.5 Lack of technical know-how Operational management also believe that often there is insufficient technical know how in companies to direct and organise process improvement programmes. 3.2.6 Time Operational management feel that in the absence of all the other obstacles, lack of time seems to be the overriding obstacle to SPI success in companies. Often, companies do not have the time to factor process work into their development schedules. The primary reason for this is the need to meet delivery deadlines. 3.2.7 Short termism Operational management find that often the process improvement initiative is thwarted by the need to provide short term indicators of fiscal success for management. We find that where short
376
termism is operational in a company, the SPI initiative is compromised because it is often difficult to account for the benefits of SPI on short term basis. SPI requires long term sustainable commitment.
3.3
Grassroots perspective
3.3.1 Time Similar to the views expressed by other practitioner groups in this study, time pressures seem to be the biggest obstacle to process improvement. Grassroots practitioners feel that they are often caught between the need to follow procedures in order to inject quality into the product and the demands of customers to meet specific deadlines. At the end of the day, customer demands are usually met to the detriment of implementing process improvement and even using existing processes. As one practitioner put it: “When the customer is waving his[sic] cheque book at you, process issues have to go” 3.3.2 Culture Company culture influences how grassroots practitioners react to SPI. Grassroots practitioners in most of the companies in this study testified to the existence of a culture of not being able to say no to unrealistic job schedules. These practitioners feel that often, they agree to project schedules which they know will be difficult to meet. Thus when faced with deadline pressures, they allocate less time to process work. The result is that the SPI programme is frustrated by the culture of not being able to say no to customers. 3.3.3 Lack of planning Grassroots practitioners across the companies feel that being unable to plan their work schedules makes it difficult for them to plan for process work. Often they find that they are unaware of what projects are coming in and this means they are not in a position to factor process work into their schedules. The result is that SPI effort is thwarted by an inability to effectively plan project work. 3.3.4 Increased workload There is a feeling amongst grassroots practitioners that formal software process improvement programmes are difficult to implement due to the volume of work that such programmes generate. Grassroots practitioners feel that SPI programmes introduce procedures which are difficult to adhere to and which add work to existing practices. They find that unless sufficient time is factored into their existing schedules to take care of process work, then when deadlines become critical, process work tends to be seen as superfluous and is often accounted for via “reverse engineering”. 3.3.5. SPI is bureaucratic SPI does not only add to the workload, but also increases more bureaucracy into the development process. This is the view of grassroots practitioners in our study. And this type of bureaucracy, they feel, stifles creativity. Directly coupled to the above argument is the desire not to compromise the expediency of “getting the product out of the door”. Practitioners feel that there is constant pressure on them to deliver the product on time, and regardless of the merits of SPI, the ethos of meeting delivery deadlines tend to outweigh other quality or process considerations.
377
3.3.6. Lower priority process work Process work tends to be given a lower priority than other software development work. We find that practitioners are less inclined to engage in lower priority work because they feel it will not reflect favourably in their personnel appraisals.
3.3.7. Insufficient evidence to support improvement Software practitioners need to have some evidence that the changes initiated by SPI programmes will bring about improvements. Often this evidence can be provided from two sources: simulated pilot projects or early realisable benchmarks in the programme. In companies where it has been possible to implement the former, there is evidence both in our research and in the literature [Itatel 1999] that supports the fact that this approach achieves better buy-in. The latter approach, however, is frustrated by the fact that most software projects are very long and that companies often set their sights on benchmarks which take too long to realise. Therefore the evidence to support improvement is often not readily available.
4. Motivators to SPI In this Section we present what practitioners say motivates them to get involved with SPI. We present the aggregate view across companies from three perspectives: strategic, operational management and grassroots.
4.1
Strategic level motivators
4.1.1. Justifiable long term benefits For SPI programmes to really take off in companies, senior management feel that they need to be able to justify the long term benefits of the programme. In our study, the companies with the most advanced SPI programmes are the ones where management have substantial evidence of long term improvements gained from the programme. This is often the only way to guarantee the financial commitments needed to drive the programme. 4.1.2. Demonstrable improvements Software process improvement also needs to have demonstrable direct improvements to get management on board. 4.1.3. Revenue cost ratio If SPI can show favourable revenue and cost ratios, it is more likely to receive better support from higher management. Senior management feel that any SPI programme needs to have a respectable return on investment to facilitate higher management support.
4.2
Operational management perspective
4.2.1. More time and resources for development. Operational managers across the companies in the study feel that a programme that will allow them to “do what we are supposed to be doing, i.e. development” will receive a lot of support. In effect, when an SPI programme is launched with assurances that there will be more time and resources for development, then that assurance serves as motivation for embarking on SPI.
378
At this stage we must point out that even though the literature does not contradict the above position, we are yet to find a company that has managed to introduce more time and resources in conjunction with an SPI programme. 4.2.2. Valid maintainable procedures Operational management also believe that having valid procedures that can be maintained and kept alive is an important motivator for an SPI programme.
4.2.3. Reduction of administrative overheads Operational management feel that if the implementation of software process improvement leads to automation of documenting procedures, then more practitioners will be motivated to carry out process work. Operational management feel that SPI models stipulate detailed documentation which lead to large administrative overheads when carried out manually. However, if such documentation could be automated, then saving can be made in administrative costs and the whole process may be easier and more endearing to practitioners. For example, some of the documentation of procedures that models like CMM [9] or SPICE [8] require would be less cumbersome if automated. 4.2.4. Empowerment Operational management feel that for SPI to be successful, there needs to be in place, within the SPI programme, practices that empower staff. For example, there needs to be in place practices that allow staff to devise tactical approaches to their problems and that enables them establish systems for prioritising their work.
4.3
Grassroots motivators
4.3.1. Visible successes If practitioners can experience the improvements that SPI introduces into the development process, they will be more responsive to conducting process improvement work. That is if their lives are made easier and current processes become less “troublesome”, then they will be willing to participate. There is a need for the successes of improvement programmes to be visible in order to get more practitioners engaged in them. 4.3.2. More positive feedback Practitioners feel that if they receive more positive feedback about the things they do, it will motivate them to embark on more process work. This is because on a personal level, they want to feel that they are doing well in their professional positions. The feeling in most companies is that often the only feedback they receive about both process and product work that they carry out is when things go wrong. 4.3.3. Bottom-Up initiatives Grassroots practitioners feel that if they can have a forum where they can identify the issues and pin point the areas of concern in software process improvement, then they are more likely to give the whole programme better support. We have found in our study thus far that in companies where practitioners have had some input in the design and planning of improvements processes, the SPI programme enjoys better support. Paulk et al describe the formation of process ownership teams on the Space Shuttle Onboard Software project at IBM-Houston, where the team comprised of “… the people who
379
perform the processes and are therefore in the best position to know what improvements should be made.” [9]. We support this concept of process ownership to improve practitioner support and involvement in SPI. And even though none of the companies in our study had dedicated process ownership teams on any comparable scale to the IBM-Houston project, it was the companies with an appreciation of the usefulness of that approach who had made significant progress in gaining grassroots buy-in.
4.3.4. Shared best practice Grassroots practitioners are concerned that best practices attained from the implementation of SPI programmes are often not shared company-wide. There are often “islands of knowledge”. The feeling is that if best practices are shared across teams and departments in companies, it will stop several cases of “re-inventing the wheel” and also overcome some of the difficult learning curves associated with SPI. 4.3.5. Training Grassroots practitioners feel that if training is provided in SPI practices, they will be more motivated to undertake those practices. However, grassroots practitioners feel that such training should be provided at the appropriate time and should have immediate relevance to the development processes. Otherwise the whole training programme could feel like time wasting and could be positively de-motivating to practitioners.
5. Conclusion 5.1. Lack of financial commitment We infer from the companies where it is difficult to establish top level financial commitment that the software process improvement goals have not been properly aligned with the business goals of the company. And the relationship between SPI and overall cost saving cannot be very apparent to the level of management where decisions about financing software initiatives are made. In these companies, we feel that the case that “quality is free” has not been sufficiently.
5.2. Time All three practitioner groups agree that the lack of time is the biggest obstacle to successful SPI. This is testimony to the pressure that practitioners are facing to meet delivery deadlines.
5.3. Lip service from managers We find that senior management appear to be committed to SPI. They appreciate the merits of improving the processes and understand the argument for investing in software quality. However we feel that in most companies, the organisational culture itself does not value SPI. As a result the allusions to SPI from senior management appear to be “lip service”. This is because the culture frustrates the commitment and stops the manifestation of tangible support for the improvement programme.
5.4. Measurable benefits
380
Another overriding finding from our study is that even though companies and individual practitioners may appreciate the conceptual benefits of SPI, they are yet to evidence enough measurable benefits for themselves and for the companies they work for in order to merit embarking upon SPI.
5.5. Potential support Despite the above, we do find that practitioners overall are very positive about the idea of software process improvement. We do, however, feel that companies are failing to unharness all of this potential support. This is because companies are not really involving practitioners in an effective and efficient way in SPI. In one example, a companies invited developers who were already laden with work to comment on a three hundred page process improvement document! For SPI to be truly successful, we feel that companies should develop better strategies for involving practitioners in improvement programmes.
6. References [1] Easterby-Smith, M., Thorpe, R. and Lowe, A. (1991), Management Research - An Introduction, Sage Publications. [2] Fransella, F. & Bannister, D., Eds. (1977) A Manual For Repertory Grid Technique, London, Academic Press. [3] Hall, T. (1995), What Do Developers Really Think About Software Quality?, In: Quality Management III Vol 1, [Ross et al Eds], Quality Management, Computational Mechanics Publications, p.359-368. [4] Hall, T. and Wilson, D. (1997) Views Of Software Quality: A Field Report, IEE Proceedings On Software Engineering, Vol 144 (2), April. [5] Heather P. & Stone S., (1984), CRUS Guide, Questionnaires, University Of Sheffield. [6] Humphrey, W. S. (1989), Managing The Software Process, Addison Wesley. [7] Paulk, M C., Humphrey, W. S. and Pandelios, G. J. (1992) Software Process Assessments: Issues and Lessons Learned, Proceedings of ISQE92, Juran Institute, 10-11 March, p.4B/41-4B/58. [8] ISO (1999), Software Process Assessment - Part 5: An Assessment Model And Indicator Guidance. [9] Paulk, M., Chrissis, M., Curtis, B. and Weber, C. (1994) The Capability Maturity Model: Guidelines For Improving The Software Process, Addison Wesley. [10] Wilson, D. N. and Hall T. (1998), Perspectives Of Software Quality: A Pilot Study, Software Quality Journal, Chapman Hall, (7), 67-75. [11] Zeithaml, V. A., Parasuraman, A. and Berry, L. L. (1990), Delivering Quality Service: Balancing Customer Perceptions And Expectations Free Press, New York.
381
382
