Software Development Methodology Evaluation Model - CiteSeerX

MEASURING AND IMPROVING SDM TECHNICAL AND SOCIAL SUITABILITY

1

MEASURING AND IMPROVING SOFTWARE DEVELOPMENT METHODOLOGY VALUE BY CONSIDERING TECHNICAL AND SOCIAL SUITABILITY OF ITS CONSTITUENT ELEMENTS Damjan Vavpotič, Marko Bajec, Marjan Krisper* ABSTRACT The theoretical research in the field of software development methodologies (SDM) shows that the use of SDM should improve the efficiency of the development team and the quality of the developed product. Interestingly, however, in practice not many software development organisations use SDM. In our paper, we present an evaluation model that provides a foundation for measuring SDM suitability on two dimensions: the SDM technical suitability for a given project and its social suitability for a given development team. Our work is based on two research areas, one socially oriented (diffusion and adoption of software process innovations) and the other technically oriented (situational method engineering). We believe that the model could be useful for software developing organisations, which want to improve their SDM. 1. INTRODUCTION The theoretical research in the field of software development methodologies (SDM) shows that the use of formally defined SDM should improve the efficiency of the development team and the quality of the developed product1. Interestingly, however, in practice not many software development organisations use formally defined SDM. Moreover, even those using SDM rarely follow it rigorously2-6. Fitzgerald2, for instance, found out that 60 percent of companies do not use formally defined SDM and that only 6 percent reported following formally defined SDM rigorously. An important cause for SDM non-adoption is that SDM are not attuned to actual organisation and project needs2, 7-18. E.g., SDM prescribe inappropriate techniques and *

Damjan Vavpotič, Marko Bajec, Marjan Krisper, University of Ljubljana, Faculty of Computer and Information Science, Tržaška 25, 1000 Ljubljana, Slovenia.

2

D. VAVPOTIČ ET AL.

methods; SDM are too rigid and cannot be adapted to specific project demands; etc. Another reason for non-adoption is SDM do not fit specific social and cultural characteristics of the development team and the organisation12, 19-30. E.g., it is difficult to introduce rigorous SDM into organisations having liberal culture; non-innovative development team will probably reject innovative SDM; etc. The first step towards an improvement of the aforementioned situation would be to measure how appropriate is a particular SDM for a particular development team on a particular project. We believe that the value of a SDM should be considered from two aspects: the first aspect dealing with technical suitability of the SDM for a given project, and the second dealing with its social suitability for a given development team. To this end, our work merges efforts from two research areas, method engineering research dealing with technical aspects of SDM construction, and diffusion and adoption of software process innovation research, which covers social aspects of SDM adoption (section 2). The objective of this paper is to describe a theoretical model for SDM evaluation that is based on a technical and social suitability of SDM. The model is intended for organisations, which have formally defined SDM, but they use them only partially or not at all. In contrast to the existing research, in which suitability is typically observed for a whole methodology, our model focuses on the SDM on a finer granularity, measuring the SDM suitability element by element. This provides software development organisations with a possibility to observe, which elements of their SDM are technically and/or socially (in)appropriate (section 3). The organisation can then gradually improve the value of its SDM by improving inappropriate SDM elements using a suitable improvement scenario. Improvement scenarios tell an organisation how to move from unsuitable SDM to SDM that is technically and socially suitable (section 4). We believe that the SDM evaluation model and corresponding improvement scenarios can greatly contribute to the improvement of the SDM use in organisations. Although the main contribution of the paper is a description of the theoretical model for SDM evaluation, we also discuss the possibilities for application of the model in practice and an outlook for further research and testing of the model (section 5). 2. BACKGROUND The aim of method engineering is to construct SDM from the methodology components or fragments10, 17. Especially important is situational method engineering that deals with construction of a methodology adapted to a certain project7, 10, 13, 16. Although method engineering has never been widely practiced by software development organisations, it gives interesting insights into the problem of a custom methodology construction and adaptation. Interestingly ideas similar to situational method engineering recently also emerged from practice. The idea of custom methodology construction was reinvented with the emergence of “agile methodologies” that advocate the idea of SDM adaptation for a given project8, 12, 31. While method engineering considers every possible technical aspect of SDM construction, it almost completely omits social aspects of its users. At most, it considers characteristics like developer knowledge and education but not much more. Despite the fact that, method engineering enable us to construct technically suitable SDM, users do not necessary adopt such SDM as they do not consider their social characteristics23, 27, 28, 30, 32 .


3

To obtain a clear picture of SDM value we also have to consider a research area explaining SDM (non)adoption in software development organisations. It is based mainly on Rogers’ diffusion of innovations theory (DOI) that tries to explain why certain innovations spread among their target users and others do not33. Researchers in this field consider a SDM as an innovation and try to predict/explain its (non)adoption i.e. to explain target adopter attitudes and their innovation-related behaviour20. Beside DOI other innovation diffusion models like Theory of Reasoned Action, Technology Acceptance Model, Theory of Planned Behaviour etc. can be used to predict/explain SDM adoption. Research shows that all this models have some common characteristics that were found more or less significant in context of SDM adoption. E.g., more significant characteristics include: relative advantage, which is the degree to which an innovation is perceived as being better than its precursor; voluntariness, defined as the extent to which potential adopters perceive the adoption decision to be nonmandatory; compatibility, that refers to the degree to which an innovation is perceived as being consistent with the existing values, needs and experiences of potential adopters; subjective norm, defined as the degree to which people think that others who are important to them think they should perform the behaviour; etc.4, 5, 28. Some researchers also use actor-network theory (ANT) to analyse situations containing both human and non-human elements. ANT was developed to analyse situations where separation of human and non-human elements is difficult34, 35. Especially interesting is the research that combines DOI and ANT theories to analyse the adoption of methodology innovations24. 3. SDM EVALUATION MODEL As already mentioned the SDM evaluation model is intended for organisations using their SDM only partially or not at all. The model enables such organisations to evaluate their SDM suitability on two dimensions. The first dimension is SDM technical suitability. It focuses on a suitability of a SDM to the project and the organisation technical characteristics (based on situational method engineering research). E.g., characteristics of the system to be, project size, project type, number of the developers, certain element compatibility with other process elements etc. By these characteristics we can determine whether a certain SDM is appropriate for a certain type of a project i.e. whether a certain SDM technically suits to certain project needs. However, developers would not necessarily adopt even technically efficient and refined SDM. To introduce SDM successfully we must also consider social and cultural characteristics of a development team28. SDM social suitability forms the second dimension. The social suitability focuses on SDM suitability to social and cultural characteristics of a development team. These characteristics enable us to determine the level of a SDM adoption in a development team. E.g., team culture, innovativeness of a team, existing experience and knowledge, opinion leaders etc. Based on these characteristics we can evaluate whether a certain SDM suits to a certain development team i.e. what are the possibilities that the development team will adopt the SDM. But again, even if socially appropriate for a given team it is not necessary that the SDM will also technically suit to projects undertaken by the team. E.g. structural techniques that might be well adopted by a certain development team are not well suited for an object-oriented development.

4

D. VAVPOTIČ ET AL.

Furthermore, we argue that it is important not only to consider SDM as a whole, but also as a constitution of interconnected elements. We define an SDM element as a constituent part of SDM and specially focus on SDM elements that can be formalised. Common SDM elements that can be formalised include elements like activities, phases, workflows, roles, artefacts, techniques, templates, guidelines, recommendations, etc.3, 7. The reason we decided to consider only elements that can be formalised is that such elements can be observed and discussed on a solid ground i.e. formalised description of the element.

SDM (formalised part) SDM element (e.g. role, activity, ect.) role template

artefact activity technique

tool

Social suitability for a given development team

Technical suitability for a given project

(Non)adoption of SDM element by its users in a development team

(Non)efficiency of SDM element on a given project

...

Figure 1. The value of a single SDM element

Figure 1 shows the idea of considering the value of a single methodology element. We propose each SDM element to be evaluated by its technical and its social suitability. An important advantage when evaluating single SDM element in contrast to the evaluation of a SDM as a whole is that we get much clearer picture on which SDM elements are technically sound and well adopted, which elements need readjustments whether technical or social and which elements are to be replaced completely. Another important advantage when evaluating a single SDM element is that we can precisely pinpoint the user of the element and evaluate whether he or she adopted the element or not i.e. whether the element is socially suitable for the person that actually uses it. We combine both dimensions in a SDM evaluation model that is shown on Figure 2. A SDM element value is measured by technical (horizontal dimension) and social suitability (vertical dimension). Based on this model we distinguish between four different types of SDM elements regarding their usefulness. Figure 2 shows each type of a SDM element in a different quadrant. •

•

The first type is a useless SDM element that is both technically and socially unsuitable. We can define different reasons for a technical and social unsuitability. E.g. with constant technology change a certain SDM element can become technically unsuitable because there is no one to update and improve it. Consequently, since users stopped using the element, it also became socially unsuitable. Alternatively, an element might have been technically unsuitable from the beginning and therefore never used. Inefficient SDM element is socially suitable, but does not really suit technical needs of a certain project or organisation anymore. Here we can find SDM


•

elements that have been technically suitable in the past and are still well adopted among users, but because of technology changes they have become obsolete (e.g. structural techniques in object-oriented environment). In contrast to an inefficient element, an unadopted SDM element is technically suitable, but its potential users do not use it because it is socially unsuitable. There can be many reasons why potential users do not accept certain SDM element. The element might be overwhelmingly complex, it might be difficult to present advantages of the element to the potential users, the element might not be compatible with existing user experience and knowledge, etc. A useful process element is socially and technically suitable. Such SDM element is well adopted among its users and suits technical needs of the project and the organisation.

Suitable

•

5

Social suitability

Inefficient process element

Useful process element

A.

C. B.

Unadopted process element

Unsuitable

Useless process element

Unsuitable

Technical suitability

Suitable

Figure 2. The model for SDM evaluation

An organisation can use the model to evaluate each SDM element and based on the evaluation choose the most suitable improvement scenario for the element. Ideally, SDM would include only useful SDM elements. However, in reality SDM elements are usually not equally efficient and/or adopted. 4. SCENARIOS FOR SDM IMPROVEMENT To improve SDM we should improve its less useful elements. That means moving SDM elements to a useful process element quadrant in SDM evaluation model (see arrows at Figure 2).

6

D. VAVPOTIČ ET AL.

•

•

•

In case of an inefficient process element (see arrow A.), we should improve element’s technical and retain social suitability. Users already adopted this element well. If possible, we should modify the element only to a certain extent that it becomes technically efficient again. We should clearly present the advantages of the changes to the users of the element and consider their arguments pro or against the changes. Another possibility is to replace the element with a similar but technically suitable element that will not require from the users to acquire completely new knowledge to work with the element. Of course, such modifications are not always possible, which means in the worst case an inefficient SDM element has to be discarded completely. An example of an inefficient SDM element could be a development tool based on COBOL programming language. Such tool might be well adopted among developers in a certain development team, but technically inappropriate for a system that we plan to build. Even though we might identify a tool based on Java programming language as technically the most suitable, developers would reject such tool as they are used to COBOL. In this case socially more suitable tool should be considered e.g. tool based on object-oriented COBOL, even though such tool might be technically less suitable than Java based tool. In case of an unadopted but technically suitable process element (see arrow B.), we should explore the causes for element’s rejection among its potential users. We might find out potential users lack knowledge and experience to use the element. To improve the adoption among potential users we might consider educating and presenting advantages of the element to the potential users. In case users still do not adopt the element, it might simply be socially unsuitable for our development team so we should consider replacing it. An example of an unadopted process element could be a certain modelling technique that is unused by a development team albeit obvious advantages of using such technique are reported in different publications. In this case we should present advantages of the technique to developers and offer them a proper training. In case of a useless element (see arrow C.) that is both socially and technically unsuitable the most probable action would be to replace or discard it completely. Most likely we can find a technically and/or socially more suitable element or the element is not needed at all.

Of course the scenarios can not be applied uniformly to each and every process element. Not every element can be changed to the same extent. E.g., elements that form the SDM core can only be changed to a limited extent or not at all. In case of such element we can only improve the adoption of the element, but can not change its technical characteristics. If we find such elements (e.g. SDM core elements) technically completely unsuitable we should replace the whole SDM. In the paper we present only three basic scenarios. More detailed scenarios can be defined depending on an element technical characteristics like element type (e.g. different scenarios apply to an activity or to an artefact), element adaptability (e.g. SDM core elements can not be replaced so we should try to improve their adoption), element significance (e.g. changing one SDM element can have more significant impact on the value of SDM than changing another SDM element), etc.; and social characteristics of its potential users like user innovativeness (e.g. less innovative user does not easily accept


7

innovative SDM elements), user experience and knowledge (e.g. it is not easy to introduce OO techniques into a team used to structural techniques), etc. Each improvement scenario should also include the most suitable strategy for implementation of a new or adapted SDM element into a development team. E.g., when opinion leaders support the new SDM element, they can start using it and gradually introduce it to other potential users. Alternatively, in case of a strong authority the authority can mandate the use of the new SDM element. The existing research dealing with SDM implementation strategies defines three basic SDM implementation strategies20, 21, 36. In case of a support strategy, the organisation makes resources available to potential adopters use, but permits individuals to voluntarily use the innovation in an exploratory manner. Advocacy strategy means the organisation actively ensures that the innovation becomes adopted among a subset of the potential adopter base (e.g. opinion leaders). Total commitment is a strategy best described as the simultaneous combination of the support and advocacy strategies. In this case, the innovation is adopted across the entire target adopter population36. Based on these strategies we can form strategies for a single SDM element implementation. Another concern is a SDM element compatibility and consistency with other SDM elements. Actually, this problem has already been addressed by method engineering7, 37. We intend to use these findings to determine whether SDM elements are compatible and to what extent. 5. PRACTICAL APPLICATION OF SDM EVALUATION MODEL As mentioned before we plan to use and test the SDM evaluation model in practice. We created a tool that enables us to use and test the model in a software development organisation. We have already identified an appropriate development organisation that is willing to participate. The organisation develops software following an object-oriented approach and is rather advanced according to technologies it employs. Before choosing this organisation, we conducted a small survey among employees that were presented to us as organisations opinion leaders (n=7). Most of the opinion leaders are experienced developers with a degree in software engineering and approximately 5 years of work experience. Interestingly, the survey showed all of them were in favour of innovations and all of them believed the use of an appropriate SDM could improve their development practice to some extent. Another important issue is that the organisation already uses a SDM that has been specifically designed for its needs, based on object-oriented development and frameworks developed by the organisation. However, as it was discovered later, only parts of the SDM are really used in practice. Organisation’s SDM is relatively non-prescriptive/non-rigorous (the whole SDM is described on approximately 130 web pages) and is stored in a web-based form so that users can access SDM easily through organisation’s intranet. The organisation also employs a methodology expert - a person responsible for the SDM maintenance, improvement, etc. Therefore, we believe this organisation is well suited to test and use the proposed SDM evaluation model and improvement scenarios. To introduce the evaluation model into the organisation we designed a SDM improvement workflow (see Figure 3). The workflow consists of three activities that together comprise eight tasks. We plan to create tool support for five of these tasks.

8

D. VAVPOTIČ ET AL.

Evaluation of SDM is the first activity. This activity runs in parallel with the project execution. Users of SDM elements (e.g. developers) evaluate SDM elements they use and post their own suggestions for SDM elements improvements. To gather constructive suggestions and evaluations, SDM users have to be motivated. We believe that motivation to post a suggestion for improvement or a complaint about SDM element is the greatest when actually using an inappropriate SDM element. Therefore, it is crucial to capture users’ discontent with SDM as early as possible. We will enable developers to post their complaints and evaluations for each SDM element by SDM evaluation tool. We will integrate the evaluation tool into organisation’s web-based SDM. 1

2

Evaluation of SDM Evaluate SDM element suitability (social and technical)

Analyze SDM elements social suitability for its users

Post suggestion for improvement of SDM element

tool support

tool support

3

Analyze SDM elements technical suitability for a given project

tool support

Improvement of SDM Analyze suggestions for SDM elements improvement by its users

User of SDM element (e.g. developer)

Analysis of SDM

Analyze new trends and approaches in the field of SDM elements

tool support

[less suitable SDM elements]

tool support

Choose improvement scenarios for SDM elements and adapt/ create new elements

SDM element introducer (e.g. lead user, authority)

Execute improvement scenarios (introduce new or adapted SDM elements)

Methodology expert

Figure 3. SDM improvement workflow

Second activity is Analysis of SDM. Some of the analysis can be performed during execution of the project, but most is performed at the end of the project when a methodology expert analyses all the evaluations gathered from SDM users. Based on the evaluations and the analysis each SDM element can be placed on the scale of its social and technical suitability in SDM evaluation model (see Figure 2). This way we can identify less suitable SDM elements that need adaptation or replacement. We plan to create an analytical tool that will enable methodology expert to monitor and analyse SDM value. Improvement of SDM is the third activity that is performed only on SDM elements that were identified as less suitable. To improve these SDM elements a methodology expert analyses suggestions made by SDM elements users. He also analyses new trends and approaches in the field of these SDM elements that he can find in different publications. Based on the analyses he then chooses proper improvement scenarios for each SDM element and adapts or creates a new SDM element. Improvement scenarios include a suitable implementation strategy. Based on the implementation strategy a methodology expert selects an appropriate SDM element introducer who is responsible for SDM element introduction into a development team. Straightforward and easily


9

adopted improvements can be implemented immediately during a project execution, but we expect the organisation will implement most of SDM improvements post-mortem and use the improved SDM on the next similar project. An organisation should put competent SDM users at the centre of SDM design, using and building simple, open SDM suited for improvisation38. Therefore, the presented workflow is based on a user involvement in SDM creation. Users can directly evaluate and provide own suggestions to improve SDM elements they use. Competent user involvement in SDM creation is important for two reasons. Firstly, we expect users to be experts in their field so their suggestions will provide at least a good starting point for SDM element improvement. Secondly, user involvement is important for increasing the rate of adoption of new SDM elements. The research in DOI theory shows that an innovation diffuses more rapidly when adopters can participate actively in customizing the innovation to fit their unique situation33. Therefore we expect that SDM users who can actively participate in customizing SDM elements will adopt such SDM elements more rapidly. 6. CONCLUSIONS AND FUTURE WORK We have presented partial results of the research in progress, in which our goal is to define a framework for organisations that wish to improve their SDM, and consequently to contribute to some increase in the SDM use in practice. So far, we have established a theoretical background for the so called two-dimensional evaluation of SDM. The first dimension is technical suitability of a SDM for a particular project and the second is social suitability of the SDM for a given development team. We believe that by considering both dimensions organisations may be able to improve the value of their SDM. As explained in the paper, an important contribution that distinguishes our approach from other attempts in this field is that it merges two aspects and that it focuses on SDM elements rather than on the methodology as a whole. To support the evaluation we have designed a SDM evaluation model, which can be seen as a conceptual background for measuring and understanding the current position of the SDM in an organisation (in terms of its technical and social suitability). The next step will be to define scenarios that will tell how an organisation that has been evaluated using the SDM evaluation model can move towards socially and technically suitable SDM. Currently, the model is being employed in an organisation, in which we have previously discovered its SDM is used only partially. We expect the evaluation will enable us to identify the most appropriate improvement scenarios for SDM elements that will appear as less useful and to improve the value of the organisation’s entire SDM. Another step in our research will be to develop detailed improvement scenarios based on the consideration of the strategies for introduction of new or adapted SDM elements into an organisation. We believe the strategy used may considerably affect the adoption rate of the changes made on SDM elements21, 36. Although we believe, the presented model has a strong potential we are also aware that it can not be used in every software development organisation. Firstly, an organisation must own formal SDM suitable for adaptation and improvisation, and secondly, we expect SDM users to have positive attitude towards organisation’s SDM. SDM users must be willing to participate in SDM evaluation and creation since the application of the model is based on the involvement of competent users.

10

D. VAVPOTIČ ET AL.

7. REFERENCES 1. D. Avison, G. Fitzgerald, Information Systems Development: Methodologies, Techniques and Tools, Third Edition (McGraw-Hill Education, 2003). 2. B. Fitzgerald, An empirical investigation into the adoption of system development methodologies, Information & Management 34, 317-328 (1998). 3. M. Huisman, J. Iivari, Systems Development Methodology Use in South Africa, Ninth Americas Conference on Information Systems (2003). 4. M. Huisman, J. Iivari, The individual deployment of systems development methodologies, Lecture Notes in Computer Science, Springer 2348, 134-150 (2002). 5. M. Huisman, J. Iivari, The organisational deployment of systems development methodologies, Information Systems Development: Advances in Methodologies, Components, and Management, Kluwer, 87-99 (2003). 6. J. Wynekoop, N. Russo, System Development Methodologies: Unanswered questions and the researchpractice gap, Proceeding of the 14th International Conference on Informtion Systems, 181-190 (1993). 7. S. Brinkkemper, M. Saeki, F. Harmsen, Meta-modelling based assembly techniques for situational method engineering, Information Systems 24(3), 209-228 (1999). 8. A. Cockburn, Selecting a project’s methodology, IEEE Software 17(4), 64-71 (2000). 9. B. Fitzgerald, N. L. Russo, T. O'Kane, Software Development: Method Tailoring At Motorola, Communications of the ACM 46 (4), 64-70 (2003). 10. F. Harmsen, S. Brinkkemper, H. Oei, Situational Method Engineering for Information System project Approaches, Methods and Associated Tools for the Information System Life Cycle, Elsevier Science, 169194 (1994). 11. B. Henderson-Sellers, Method engineering for OO systems development, Communications of the ACM 46(10), 73-78 (2003) 12. J. Highsmith, Adaptive software development: a collaborative approach to managing complex systems (Dorset House Publishing, 2000). 13. H. A. Hofstede, T. F. Verhoef., On the feasibility of situational method engineering, Information Systems 22(6/7), 401-422 (1997) 14. S. McConnell, Rapid development: Taming Wild Software Schedules (Microsoft Press, 1996). 15. G. Miller, Sizing Up Today’s Lightweight Software Processes, IT Professional 3(3), 46-49 (2001). 16. J. Ralyte, R. Deneckere, C. Rolland, Towards a Generic Model for Situational Method Engineering, Proceedings of 15th International Conference on Advanced Information Systems Engineering (2003). 17. C. Rolland, V. Plihon, Using Generic Method Chunks to Generate Process Model Fragments, Proceedings of the 3rd IIE Int. Conf. ICRE’96, USA, (1996). 18. D. Vavpotic, M. Bajec, M. Krisper, Software development methodology evaluation model, Proceedings of Twelfth international conference on information systems development: Constructing the Infrastructure for the Knowledge Economy, Australia, 2003, (article in press). 19. R. G. Fichman, C. F. Kemerer, The assimilation of software process innovations: An organizational learning perspective, Management Science 43(10), 1345-1363 (1997). 20. M. J. Gallivan, Organizational adoption and assimilation of complex technological innovations: development and application of a new framework, ACM SIGMIS Database 32(3), 51-85 (2001). 21. M. J. Gallivan, Strategies for implementing new software processes: An evaluation of a contingency framework, Proceedings of the 1996 ACM SIGCPR/SIGMIS conference on Computer personnel research, 313-325 (1996). 22. M. J. Gallivan., The influence of software developers’ creative style on their attitudes to and assimilation of a software process innovation, Information & Management 40, 443-465 (2003). 23. G. C. Green, R. W. Collins, A. R. Hevner, Perceived control and the diffusion of software process innovations, Journal of High Technology Management Research 15(1), 123-144 (2004). 24. E. Mustonen-Ollila, Methodologies Choice and Adoption: Using Diffusion of Innovations as the Theoretical Framework, Diffusion Interest Group in Information Technology, Helsinki, Finland (1998); http://www.mis.temple.edu/digit/past_meetings/digit1998/olila.pdf. 25. S. L. Pfleeger., Understanding and improving technology transfer in software engineering, The Journal of Systems and Software 47, 111-124 (1999). 26. M. B. Prescott, S. A. Conger., Information technology innovations: a classification by IT locus of impact and research approach, ACM SIGMIS Database 26(2-3), 20-41 (1995). 27. P. Rawstorne, R. Jayasuriya, P. Caputi, Issues in predicting and exploring usage behaviours with the technology acceptance model and the theory of planned behaviour when usage is mandatory, Proceedings of the twenty first international conference on Information systems, Brisbane, Australia, 35-44 (2000).


11

28. C. K. Riemenschneider, B. C. Hardgrave, F. D. Davis, Explaining Software Developer Acceptance of Methodologies: A comparison of Five Theoretical Models, IEEE Transactions on Software Engineering 28(12), 1135-1145 (2002). 29. J. A. Rodger., P. C. Pendharkar, G. D. Bhatt, Diffusion theory and the adoption of software innovation: common errors and future issues, The Journal of High Technology Management Research 7(1), 1-13 (1996). 30. S. Sharma, A. Rai, An assessment of the relationship between ISD leadership characteristics and IS innovation adoption in organizations, Information & Management 40, 391-401 (2003). 31. A. Cockburn, Agile software development (Addison-Wesley, 2002). 32. M. Niazi, D. Wilson, D. Zowghi, A maturity model for the implementation of software process improvement: an emperical study, The Journal of Systems and Software (article in press, available online 30 December 2003). 33. M. E. Rogers, Diffusion of Innovations, 5th Edition (Free Press, 2003). 34. M. Callon, Actor-Network Theory: The Market Test, Actor Network and After Workshop, Centre for Social Theory and Technology, Keele University, UK (1997). 35. A. Tatnall, A. Gilding, Actor-Network Theory and Information Systems Research, Proceedings 10th Australasian Conference on IS, 955-966 (1999). 36. R. Agarwal, M. Tanniru, D. Wilemon, Assimilating Information Technology Innovations: Strategies and Moderating Influences, IEEE Transactions on Engineering Management 44(4), 347-358 (1997). 37. S. Brinkkemper, K. Lyytinen, R. J. Welke, Method Engineering – Principles of method construction and tool support, Proceeding of the IFIP TC8, Atlanta, USA (Chapman & Hall, 1996). 38. I. Aaen, Software Process Improvement: Blueprints versus Recipes, IEEE Software 20(5), 86-93 (2003).