Agile development methodologies introduced to Norwegian ICT companies.

TDT4520 Software Engineering, Directed Study - Autumn 2007 Agile development methodologies introduced to Norwegian ICT companies. A part of the EVISOFT project. by Snorre Nævdal Supervisor: Reidar Conradi Co-supervisor: Geir Kjetil Hanssen

Abstract The software development discipline has become increasingly complex. Even though the practice has continiously evolved to remedy the consequences of this complexity, projects are plagued with missed deadlines, exceeded budgets or even total failure. One of the remedies that has evolved is different development methods. The methods that has recieved the most attention lately has been labeled light or agile methods. The first part of this study presents this evolution of software engineering in general and in software development processes in particular. Firstly the difference between the traditional and agile methods are explored, followed by a closer examination of specific agile methods. The agile methods considered are explained in more detail and summarized using 8 properties found important in the litterature. In order to further study the use of agile methods and especially in a Norwegian setting a set of interviews was performed. A total of 21 companies was contacted and resulted in 7 interviews from companies differing in both size and business areas. Prior to the interviews a list of research questions and a interview guide constructed, these helped guide the interview and narrow the field of research. The aspects that the interviews focused on were customer involvement, the use or consideration of agile methods, typical project characteristics, valued development method properties and development method variations. The results of the interviews are presented as answers to the research questions and show that there are only two companies that use agile methods daily, but that all but two companies have considered it. The results also show that none of the companies have the customer involvement that is recommended for using agile development methods, and that customer interest in which method is used is close to non-existent. A majority of the companies adapt or make changes in their existing development methods depending on the project, but only one company change the entire method. The most desirable property in a development method was by far the ability to produce quality software, but for the companies using agile methods the simplistic method of developing came a close second. When looking at the projects timespan and size it was discovered that the participants that uses agile methods has smaller teams, use less time and includes more iterations. This can be an indication that agile methods are best suited in smaller and less complex systems, or with above average skilled developers. It has also become clear that there are variations in the day to day workings of the participating companies that are not taken into account in any of the explored development methods. I

Preface This project is a part of the course TDT4520 Software Engineering, Directed Study. The objective of this course is to introduce the students to state-of-the-art topics within software engineering and the methods used to further reaserch on these topics. This is achieved by giving the students a choice of projects where each project focuses on domains of current interest. This report is part of the EVidance based Improvment of SOFTware engineering (EVISOFT) project. The project has as its goal to make improve the processes within software engineering, and to do this to such a degree that it becomes economically benifitial. I would like to thank my supervisor, Professor Reidar Conradi at the Department of Computer and Information Science, NTNU for his guidance and help in getting me going and guiding me through this process. I would also like to thank all the anonymous respondents in the interviews for their contribution to this study and Geir Kjetil Hanssen, Torgeir Dingsøyr and Øyvind Hauge for their inputs and help in finding relevant research material. II

Contents 1 Introduction 2 1.1 Motivation....................................... 2 1.2 Project context..................................... 2 1.3 Problem definition................................... 3 1.4 Report outline..................................... 3 2 Prestudy 4 2.1 Software engineering.................................. 4 2.2 Software development processes............................ 6 2.2.1 Traditional methods.............................. 6 2.2.2 Agile methods................................. 6 2.2.2.1 Agile manifesto............................ 7 2.3 Traditional methodologies............................... 9 2.3.1 Waterfall model................................ 9 2.3.1.1 History................................ 9 2.3.1.2 Fundementals............................ 10 2.3.2 Incremental and iterative models....................... 10 2.3.2.1 Histoy................................. 10 2.3.2.2 Fundementals............................ 11 2.3.3 Capability Maturity Model (CMM)...................... 12 2.4 Agile methodologies.................................. 12 2.4.1 extreme Programming (XP)......................... 13 2.4.1.1 History................................ 13 2.4.1.2 Fundementals............................ 13 2.4.1.3 Characteristics............................ 14 III

2.4.2 SCRUM..................................... 15 2.4.2.1 History................................ 15 2.4.2.2 Fundementals............................ 15 2.4.2.3 Characteristics............................ 17 2.4.3 Crystal..................................... 18 2.4.3.1 History................................ 18 2.4.3.2 Fundementals............................ 19 2.4.3.3 Characteristics............................ 19 2.4.4 Dynamic Systems Development Method (DSDM).............. 20 2.4.4.1 History................................ 20 2.4.4.2 Fundementals............................ 21 2.4.4.3 Characteristics............................ 22 2.4.5 Feature Driven Development (FDD)..................... 23 2.4.5.1 History................................ 23 2.4.5.2 Fundementals............................ 24 2.4.5.3 Characteristics............................ 24 2.5 Summary........................................ 25 3 Research 27 3.1 Research goal and questions.............................. 27 3.2 Research approach................................... 28 3.3 Research design..................................... 29 3.3.1 Interview.................................... 29 3.3.2 Sample and context.............................. 29 3.3.2.1 Participating companies....................... 32 3.3.2.2 Respondents............................. 32 3.4 Research process.................................... 33 4 Results 35 4.1 RQ1: To which extent are agile development methods in use, or have been considered as the primary development method?.................... 35 4.2 RQ2: To what degree does the customer influence the development method?... 35 4.3 RQ3: Is the customer an active participant in the development process?..... 36 4.4 RQ4: Do the development method vary depending on the projects properties?. 37 IV

4.4.1 Adaptation................................... 37 4.4.2 Variation.................................... 37 4.5 RQ5: What properties do companies value in a development method?...... 38 5 Discussion 40 5.1 General discussion................................... 40 5.2 Validity......................................... 42 5.2.1 Internal validity................................ 42 5.2.2 External validity................................ 42 6 Conclusion and further work 44 6.1 Conclusion....................................... 44 6.2 Further work...................................... 45 Glossary 46 References 47 Appendix 49 6.3 The interview guide.................................. 49 6.4 Sample context..................................... 51 6.4.1 Company 1................................... 51 6.4.2 Company 2................................... 51 6.4.3 Company 3................................... 52 6.4.4 Company 4................................... 52 6.4.5 Company 5................................... 53 6.4.6 Company 6................................... 53 6.4.7 Company 7................................... 54

List of Tables 1.1 Project outline..................................... 3 2.1 Agile methods...................................... 12 2.2 An overview of some key characteristcs of XP.................... 15 2.3 An overview of some key characteristcs of Scrum.................. 17 2.4 An overview of some key characteristcs of Crystal.................. 20 2.5 An overview of some key characteristcs of DSDM.................. 23 2.6 An overview of some key characteristcs of FDD................... 25 3.1 Research questions................................... 28 3.2 Initial responses..................................... 33 4.1 Methods used and agile methods considered..................... 36 4.2 Motivation for adapting and/or changing development method.......... 38 4.3 Properties valued highest by the companies..................... 38 5.1 Project differences................................... 41

List of Figures 2.1 The software development lifecycle.......................... 5 2.2 The agile lifecycle.................................... 8 2.3 The waterfall model as described by W. W. Royce [1]............... 10 2.4 The spiral model as described by Barry W. Boehm [2]............... 11 2.5 A flowchart of an XP project (http://www.extremeprogramming.org/)..... 13 2.6 The Scrum life-cycle (http://www.controlchaos.org/).............. 16 2.7 Factors that influence the selection of crystal methodology............. 18 2.8 How DSDM differs from traditional approaches.................... 21 2.9 The 5 stages in FDD.................................. 24 2.10 A summary of the included agile methods...................... 26 3.1 A distribution of the company sizes from the original list.............. 30 3.2 A distribution of the company types from the original list............. 31 3.3 A distribution of the company sizes that agreed to participate........... 31 3.4 A distribution of the company types that agreed to participate.......... 32 3.5 An overview over the numer of developers in each company............ 33

Acronyms EVISOFT EVidance based Improvment of SOFTware engineering. SINTEF The Foundation for Scientific and Industrial Research at the Norwegian Institute of Technology (NTH). NTNU The Norwegian University of Science and Technology. UiO The University of Oslo. ICT Information and Communication Technology. IEEE Institute of Electrical and Electronics Engineers BDUF Big Design Up Front RUP Rational Unified Process CMM Capability Maturity Model. CMMI Capability Maturity Model Integrated. XP extreme Programming RAD Rapid Application Development IS Information System OOPSLA Object-Oriented Programming, Systems, Languages & Applications ACM Association for Computing Machinery DSDM Dynamic Systems Development Method MoSCoW M - MUST have this, S - SHOULD have this if at all possible, C - COULD have this if it does not affect anything else, W - WON T have this time but WOULD like in the future. FDD Feature Driven Development TTM Time To Market TDD Test Driven Development ISO International Organization for Standardization

Chapter 1 Introduction This chapter presents the research objective, the definition of the problem and a report outline. 1.1 Motivation The software development discipline has become increasingly complex. Even though the practice has continiously evolved to remedy the consequences of this complexity projects are plagued with missed deadlines, exceeded budgets or even total failure [3]. One of the remedies that has evolved is different development methods. The methods that has recieved the most attention has been labeled light or agile methods, these represent a conceptual framework that focuses on using iterations throughout their projects and include a variety of described methods like XP or SCRUM. Most of these evolved in the mid 1990s and were first and foremost a reaction against the bureaucratic or heavy methods most commonly used then and now. When these agile methods are suitable have beed debated since their conception and even though there exist a few guidelines these are not always consistent and rarely entirely agreed upon [4]. 1.2 Project context This report is part of the EVISOFT project. It is a joint project between the following research institutions: The Foundation for Scientific and Industrial Research at the Norwegian Institute of Technology (NTH) (SINTEF), The Norwegian University of Science and Technology (NTNU), SIMULA research center and The University of Oslo (UiO). It is partly financed by the Research Council of Norway (Norges Forskningsråd) and currently sponsored by the following norwegian Information and Communication Technology (ICT) companies: ABB, DNV Software, EDB, FIRM, Geomatikk, Konsberg Spacetec, Objectnet, Software Innovation, Telenor and Vital. These sponsors all contribute by commiting themselves to spend time on testing pratices recommended or supported by the EVISOFT project. The EVISOFT project is the successor of the project SPIKE (2003-2006) which in turn was the 2

successor of PROFIT (2000-2002). All these projects share a common goal, namely to improve processes in software-intensive companies. The project is going to achieve this is by monitoring and collecting evidence from the contributing ICT companies while they use state-of-the-art tools, methods or processes. While monitoring these companies the project will gain knowledge that after analysis might reveal strategies that can ensure future sucesses or predict possible failures. 1.3 Problem definition The original project description was as follows: SCRUM is one of the most popular agile methods along with XP. In EVISOFT there are four companies that are introducing SCRUM to their development process, and stip. Geir Kjetil Hanssen are going to study these in his doctoral study. This project will try to find the keys to a successful SCRUM implementation by using one of the four companies in a case study. Due to time constraints and the state of the SCRUM implementation in these companies this definition was replaced with the following: Survey what development methodologies Norwegian ICT companies uses, in which context they are used, and what attributes the companies value when choosing their development method. Keep added focus on the use of agile deveopment methods in particular and why / why not these are used successfully. 1.4 Report outline This report is divided into 8 parts. Each of these parts are summarized in table 1.1. Title Description 1 Introduction The introduction will introduce the reader to the problem, its definition and motivation behind the project. 2 Prestudy This section will look through the history of software engineering in general and software development processes in particular. 3 Research The goal of the research is presented along with the research questions, which approach was choosen, the design used, and lastly how the process itself went. 6 Results The results of the research is presented as answers to the research questions. 7 Evaluation The interviews and their results are discussed further along with the validity of the research. 8 Conclusion This section presents the conclusion and comments about what could be appropriate further work. Table 1.1: Project outline 3

Chapter 2 Prestudy This prestudy will survey literature on the subject of development methodologies in general and agile (aka light ) in particular. We will take a closer look on a few agile methodologies and will present the basic idea behind the approaches and investigate what seperates them from traditional approaches and each other. 2.1 Software engineering Software engineering is defined as The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. This defintion was proposed by the Institute of Electrical and Electronics Engineers (IEEE) in 1990 [5], but the term software engineering has regardlessly suffered from wide misused due to its ambiguous meaning and the misunderstandings as to what the term implies. As a result of informal use the term has been used to label processes that more accurately can be described as programming, system analysis or computer science. The discussion regarding software engineering and its application is still not settled, there are people that believe that a more appropriate and accurate name is software development. This name is one of the alternatives that resulted from the popular argument concerning whether the field is mature enough to warrant the use of the term engineer. The name software development is currently thought of as the combination software engineering and software marketing. Software marketing entails items that is not commonly associated with the development of software, but are nevertheless important to ensure the success of any development project [6]. Software marketing is also often called software requirements analysis and consists of several different activities where the main objective is to record, analyze, and manage requirements important to the stakeholders within the project. Over time there has surfaced a variety of methododologies that aims at making it easier to replicate successes and avoid pitfalls. Software development process is a collective term that include all of these methodologies and is defined as an organized set of activities performed to translate user needs into software products [7]. 4

Figure 2.1: The software development lifecycle Most of these process methodologies goes through a series of steps or phases and they tend to do this either iteratively, sequentially or in a combination of the two. The stages that are most commonly used and all well-known are displayed in figure 2.1. This circle is often called the software delvelopment life-cycle and represents the stages a development project can be in from start to finish. A more detailed description of each individual stage is presented in the following list: Planning - Establishing a plan as to how the system is to be implemented. This can consists of activities like defining the project scope and developing and maintain a plan for the project. Analysis - The stakeholders and developers collaborate to gather and comprehend the various requirements necessary to make the project succeed. Design - The design phase is where the blueprint of the system is developed and issues like architectural design and the systems model is addressed. Implementation - Executing the design into a physical system by building the architecture and model decided in the previous stage. Testing - Testing the developed system. analysis are met. Check to se if the requirements found during Deployment - The system is deployed in a production setting where training in using the system is given and a user guide is created. 5

Maintenance - Keeping the system up to date with the changes in the organization and ensuring that it meets the goals of goals of the stakeholders. 2.2 Software development processes There are several synonyms that refer to the process of developing software, in addition to software development process the term life-cycle process, software process are often found in litterature and all refer to the same basic idea. In order to get more reliable and stable results when developing software several different models, also refered to as development approaches or development frameworks, has been described by experienced developers. Most of these models propose a variation of principles, methods, techniques or tools to use during the process and which the authors have experienced success using. 2.2.1 Traditional methods The expression traditional when writing about development models is commonly understood to refer to the earliest models that were documented. Processes that have evolved from these models, but still retain the classical characteristics are also considered to be traditional. The common conceptions of most of these traditional approaches is that the models used tend to simplify and characterize processes that in reality are unpredictable. The process sounds good in theory, but does not always work as advertised in pratice. This leads to many arguments on how this approach differs from the way developers actually perform effecient work. These traditional approaches are mostly based on Big Design Up Front (BDUF), meaning that they rely on thoroughly documented and planned decisions made up front in order to succsessfully manage a development cycle. Since the introduction of faster moving technologies such as the internet software industry and the mobile application environment these efforts has been criticized for beeing to time-consuming and for no longer giving the benefit it intended. The emphasis on up front planning and sequential execution also inhibits the processes from easily adapting to changing prerequisites and requirements [4]. The waterfall model when created had as one of its goals to to fix the problem of changing requirements. The solution was to freeze the requirements and not allowing any change after development was started. Practitioners proved however that this was not as easily done as anticipated. A study by Nandhakumar and Avison argue that traditional approaches are treated primarily as a neccessary fiction to present and image of control or to provide a symbolic status [8]. An even more condemning characteristics was presented by Truex, Baskerville and Travis. In their article they state that it is possible that traditional approaches are merely unattainable ideals and hypothetical straw men that provide normative guidance to utopian developmment situations [9]. These are some of the views that resulted in a search for alternative methodologies and motivated the emergence of agile software evelopment methods. 2.2.2 Agile methods The definition of the word agile is as follows: 6

Having the faculty of quick motion; nimble, active, ready. 1 The rise of agile methodologies is a reaction to the commonly used and often called traditional approaches of developing software, despite it beeing a reaction, the methods are not entirely new. The biggest source of ideas lies in previously faulty models and the biggest driving force is evolution. Previously failed or succeeded processes reveal their successes and failures through research or experience and thereby help the software development process improve. What makes agile development stand out from other evolved models are the values and principles that characterizes the agile way of thinking. As discussed in the previous section there are several shortcomings attributed traditional methods, in addition there are also new considerations that make these methods too heavy to be used efficiently with todays resources and demands. Techonologies are developed and introduced quicker by the day and as a response more and more products, people and businesses are getting used to products involving heavy software development. This results in a customer that is increasingly unable to define their needs up front and who at the same time expect more from the finished product. This trend made heavy approaches inadequate and resulted in practitioners and consultants independenlty develop a wide range of alterantive methods and practices [4]. Many of the agile processes uses what is called evolutionary delivery which has the following definition: the development of usable software sub-systems in very small steps, with user requirements being continually re-assessed after each delivery [10]. This is illustrated by figure 2.2 which depicts how the life-cycle of an agile development project can be carried out. Another key principle agile development projects rely on is the close cooperation with the customer, many methodologies does this by making a representative of the customer a member of the team that is developing the software. This is important to keep the project responsive to continuous feedback and thereby ensure many of the principles valued by the agile community (see 2.2.2.1). This is however also one of the key point made against agile development. The sceptics are not sure one customer has sufficient knowledge in areas vital to a good project, and that it is highly unlikely that this representative will be available all of the time needed by the developers. The sceptics also argue that the lack of BDUF will result in the lack of a good architecture, and might make the customer reluctant to commit to something not thoroughly planned and estimated. 2.2.2.1 Agile manifesto In February 2001 a group of these practitioners gathered to discuss alternative development methods and try to find common ground. These were representatives from several of the well-known methodologies and others sympathetic to the need of finding an alternative to the traditional approaches. These meetings led to the realization that even though many of the participants were competitors daily they had compatible values and shared the belief that a development environment is at its best when it does more than talk about people as our most important asset but actually acts as if people were the most important, and lose the word asset [11]. Jim Highsmith writes in his summary that Alistair Cockburn proclaimed what probably many of the participants had been thinking early on in these meetings when he said I personally didn t expect that this particular group of agilites to ever agree on anything substantive [11]. This however, was not the case, the group named themselves The Agile Alliance, abandoning the earlier used term light or light-weight, and all agreed on and signed The agile manifesto. 1 dictionary.oed.com, 24.09.07 7

Figure 2.2: The agile lifecycle This four item list is a statement about which values are common for all the participants of this meeting. The manifesto states the following [11]. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Jim Highsmith Steve Mellor Mike Beedle Andrew Hunt Ken Schwaber Arie van Bennekum Ron Jeffries Jeff Sutherland Alistair Cockburn Jon Kern Dave Thomas Ward Cunningham Brian Marick James Grenning Martin Fowler Robert C. Martin These signatories are representatives from XP, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming. They go on to describe the following list of principles which they all agree upon are important in any development project 2. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2 http://agilemanifesto.org/principles.html 8

Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity the art of maximizing the amount of work not done is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 2.3 Traditional methodologies 2.3.1 Waterfall model 2.3.1.1 History One widely known model that incorporate and helped defined the most common development stages is the sequential model first described by Winston W. Royce in his paper Managing the development of large software systems [1]. Even though he argued against this model writing the..the implementation descrived above is risky and invites failure., and proposed a iterative variation where feedback could influence subsequent phases, it was the model now known as the waterfall model that has recieved the most notice and use. Using the waterfall model purely sequentially have been and still is a very popular choice for developers, and have for some become the reference to any process that rely heavily on rigidity. One reason for this popularity came with the DoD STD 2167, a military standard of the American Department of Defense for Defense System Software Development. It promotes the use of one-pass document-driven waterfall process which in turn influenced a number of national and international standards still active today. 9

2.3.1.2 Fundementals A figure of the waterfall model and its stages as proposed by W. W. Royce can be found in Figure 2.3. The waterfall model is based on an approach also known as BDUF which is intended to take advantage of the fact that well defined requirements and design will save time and effort in later stages of the development. As a result of this the waterfall model is best suited in projects where requirements are stable, which makes it easier to find a good design that deals with what is predicted to be the biggest problems from the start. Figure 2.3: The waterfall model as described by W. W. Royce [1] 2.3.2 Incremental and iterative models 2.3.2.1 Histoy Incremental development is a development strategy where different parts of the system are beeing developed at different times and integrated into the system when completed. The alternative to incremental development is to integrate all parts of the system at once. Iterative development uses improved scheduling to set aside time to look over and improve developed parts of the system. The typical difference is that incremental development releases the product of each increment to the users while iterative development examines each iterations output for improvement. One does not necessarily imply the other but the combination of the two are often considered beneficial. The two terms merged in practical use after the introduction of Rational Unified Process (RUP) in the mid 1990s, when the authors selected the term iterative development, and iterations to mean any combination of iterative and incremental development. The two practices are also the cornestone to all agile methodologies [12]. 10

2.3.2.2 Fundementals The spiral model is a good example of what is considered an iterative development model. It was first described by Barry Boehm in his article titled A Spiral Model of Software Development and Enhancement in 1988. The model was introduced as the solution to some of the problems discovered with using straight forward sequential processes. This was not the first model that discussed iterative development, but it was the first that addressed the importance of why development should be done iteratively. The spiral model combines elements from the waterfall model and prototyping-in-stages and tries to combine the benefits from top-down and bottom-up concepts [2]. The spiral model is by many believed to best suit large, expensive and complicated projects. Figure 2.4 show an overview of the stages used in each iteration and how the iterations evolve as the project proceeds. Figure 2.4: The spiral model as described by Barry W. Boehm [2] 11

2.3.3 Capability Maturity Model (CMM) Another framework used to represent traditional approaches is the CMM or its equivalent Capability Maturity Model Integrated (CMMI). The goal of CMM is to ensure process consistency, predictability and reliability. The model uses a 5 level model to envision how far each organization has matured, and is claimed by its proponents to be easily tailored to fit environments ranging from a two- to three-person projects in start-up companies to 500-person real-time, life-critical systems [13]. 2.4 Agile methodologies When the agile manifesto was published it made it easier to categorize which methodologies was rightly named agile and which was not. One of the first to be defined and probably the most widely known of these are XP. The introduction of XP made it the first popular ligh-weight method which in turn has made its introduction the starting point of a variety of agile software development approaches. Since then there has been invented or reinvented a number of similar methodologies that seems to fall into the same category. A list of the most well-known methods and the year it is believed they were created is listed in table 2.1. Name Created SCRUM 1986 Crystal 1990 Dynamic Systems Development Method 1995 Extreme Programming 1996 Feature Driven Development 2000 Table 2.1: Agile methods To enable easier comparison between the agile methodologies and the traditional approaches a table of some key characteristics has been defined in list 2.4. These characteristics can help the reader get a quick overview of the models possibly make it easier to evaluate their usefulness in different settings. First appeared The year the methodology first appeared. Team size The recommended size of the pojects team. System criticality Limitations or preference regarding the developed systems criticality. Iteration length If iterations are used, what are their recommended lenght Distributed teams Are distributed team supported. Defined processes How well are the processes internally defined. Prior knowledge needed How much prior knowledge is required to use the model correctly and understand its processes. Responsive to environment How responsive is the development model to changes in the environment. 12

Documented experience If there is documented experiences using the model, and what kind. Comments Additional comments if any. 2.4.1 extreme Programming (XP) Figure 2.5: A flowchart of an XP project (http://www.extremeprogramming.org/) 2.4.1.1 History XP is without a doubt the best documented and perhaps the most well-known agile method to emerge in recent years. The method was introduced in full by Beck, Jeffreys et. al. in 1998 and further populaarized by Beck s: Extreme Programming Explained: Embrace Change in 1999. This method hit home with many developers who were tired of the shortcomings experienced in traditional approaches and wanted something new, something extreme [4]. 2.4.1.2 Fundementals XP has 12 rules to follow when implementing. These are easily understood and true to the method itself by beeing concise and to the point. These twelve rules are: The Planning Game At the start of each iteration the stakeholders in the project meat to discuss and prioritize requirements for the next release. The requirements are called user stories and are captured on stoy cards. These story cards should be understandable for all the participants. Small Releases The first version of the system is put into production after the fist few iterations. After that new versions are released after anywhere from a few days to a few weeks. Metaphor Customers, developers and managers construct a metaphor or a set of metaphors around which they model the system. Simple Design The design kept as simple as possible by the developers. 13

Tests Developers all work test-first: that is, acceptance tests are written prior to the actual code. Customers also write functional tests which all needs to be passed at the end of each iteration. Refactoring As the work progresses the design should evolve to keep it as simple as possible. Pair Programming The developers are paired together and urged to write code together on the same machine. Collective ownership All code is owned by all developers, meaning all developers can make changes to any part of the code if neccessary. On-site customer A customer work together with the development team to answer questions, perform acceptance tests and to ensure that the development progresses as expected. 40-hour Weeks Each iteration should be planned in such a matter that there is no need to put in overtime. Open Workspace Developers work in an open workspace where there are individual workstations around the periphery and common development machines in the center. The details behind these rules are simple and might seem awkward and perhaps even naive at first, but soon become a welcome change 3. A flow chart of the XP process is found in figure 2.5. According to Cohen et. al. practitioners agree to the fact that the strength of XP is not the twelve practises alone, but what emergent properties arising from their combination [4]. To determine which projects could benefit from the use of XP we list an overview of such a project characteristics in table 2.2. 2.4.1.3 Characteristics 3 http://www.extremeprogramming.org/, 04.10.07 14

Name Applies to XP Author Kent Beck First appeared 1996 Team size From 2-12, but team as large as 30 has reported success. Depedent on co-location. System criticality It is mostly agreed that XP in itself is not limited to any criticality Iteration length Shortest iteration length of all mentioned agile methods, 2 weeks. Distributed teams Focus on communication, distributed teams not supported. Prior knowledge needed Very simple and self explanatory rules and practices combined the ability to make changes where necessary makes XP one of the easiest agile method to start using. Defined processes Very richly documented process, but leaves room for adaptations which might require much insight. Documented experience This is the most documented of the approaches, which means there many to experiences which are well documented. Here are a few: [14],[15] and [16] Comment With the smallest of all iteration lengths, XP is very responsive to changes. It it also very adaptive in such way that it is easy to integrate parts of it into an existing process. Its practises focuses on development. Table 2.2: An overview of some key characteristcs of XP 2.4.2 SCRUM 2.4.2.1 History SCRUM was first refered to by Ikujiro Nonaka and Hirotaka Takeuchi in the paper The New New Product Development Game in which they presented their ideas and reasearch in process theory. This article was published in 1986 and noted how small cross-functional teams historically produced the best result. In the early 1990s both Ken Schwaber and a group led by Jeff Sutherland develeoped two approaches that were very similar to what was already described by Nonaka and Takeuchi and in 1996 they jointly presented a paper describing Scrum for the first time at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) convention. The model now known as Scrum is a combination of their writing, experience and the industries best practises. 2.4.2.2 Fundementals The figure 2.6 shows the scrum life cycle. Projects using scrum are split into sprints (iterations) all consisting of the following stages [17]: Pre-sprint planning All the work that is yet to be done is kept in the release backlog. Before each sprint a plan as to which requirements, functionalities or features is to be implemented this sprint is decided by the projects stakeholders. The tasks in the backlog is often of high 15

Figure 2.6: The Scrum life-cycle (http://www.controlchaos.org/) abstraction so a sprint goals is also agreed upon to help guide the development for each sprint. Sprint After the completion of the pre-sprint planning the development of the current sprints release starts. At this stage tasks in the sprints backlog are frozen and remain unchanged for the duration of the sprint. Each team memeber chooses the tasks that they want to work with and begin development. Each morning a short meeting is held to ensure that the project progresses as planned. This meeting is essential to the success of Scrum as it helps enhance the communications between the stakeholders. These meetings are used to identify problems, update the projects status and ensure the entire team has the same goal. Post-sprint meeting After each sprint there is held a meeting to discuss the the projects progress and to demonstrate the current system. In the white-paper titled Controlled Chaos : Living on the Edge, Advanced Development Methods represented by Ken Schwaber has summarized the following key priniples of scrum [17]: Small working teams that maximize communication, minimize overhead, and maximize sharing of tacit, informal knowledge. Adaptability to technical or marketplace (user/customer) changes to ensure the best possible product is produced. 16

Frequent builds, or construction of executables, that can be inspected, adjusted, tested, documented, and built on. Partitioning of work and team assignments into clean, low coupling partitions, or packets. Constant testing and documentation of a product-as it is built. Ability to declare a product done whenever required (because the competition just shipped, because the company needs the cash, because the user/customer needs the functions, because that was when it was promised...). 2.4.2.3 Characteristics Name Applies to SCRUM Author Ken Schwaber, Jeff Sutherland et.al First appeared 1986 Team size Development personnel are split into teams of up to seven people. System criticality Scrum does not explicitly address the issue of criticality. Iteration length Originally suggested sprint lengths from 1 to 6 weeks, durations are commonly held at 4 weeks. Highly responsive to changes. Distributed teams No built in support for it, but there are not any reasons why teams cannot be distributed. Prior knowledge needed There are several good books that describe the fundementals in detail and also many companies that offer the training and certification that ofte is needed to take the role as SCRUM master. Defined processes SCRUM provides a good framework that manages the development process but does not provide any practices for how to handle the development in itself. There are however a few well defined processes within SCRUM. Documented experience There are quite a few experience reports, many of which combine SCRUM with other development methodologies. I ve included these three: [18], [19] and [20]. Comment It has recently become one of the more widely known methodologies and has lately been tried integrated with XP since they complement each other and share many core values. Table 2.3: An overview of some key characteristcs of Scrum 17

2.4.3 Crystal Figure 2.7: Factors that influence the selection of crystal methodology 2.4.3.1 History The crystal family of development methods was developed by Alistair Cockburn in the early 1990s. He believes that one of the major problems in software development is the lack of communication and has as his philosophy to replace written documentation with face-to-face communication and in that way reduce the reliance of written work products. He also states The more frequently you can deliver running, tested slices of the system, the more you can reduce the reliance on written promissory notes and improve the likelihood of delivering the system [21]. The way he proposes to handle projects with different attributes is to use a range of methods that are tailored to the excact need of that particular project. Attributes in this case is the number of developers that need to cooperate and the criticality of the system that is developed. The family of methodologies are named crystal because of the similarity between the the two main attributes of a project, size and criticality, and their resemblance to the main attributes of a mineral, color and hardness. The different versions of crystal is compared to different facets of a gemstone, all sharing the same core. Cockburn describes the connection between the range of methods and a projects attributes in the following manner: Larger projects, which require more coordination and communication, map to darker colors (clear, yellow, orange, red, and so on). Projects for systems that can cause more damage need added hardness in the methodology, as well as more validation and verification rules. A quartz methodology is suited to a few developers creating 18

an invoicing system. The same team controlling the movement of boron rods in a nuclear reactor needs a diamond methodology-one calling for repeated checks on both the design and the implementation of their algorithms.[22] 2.4.3.2 Fundementals In figure 2.7 4 you see how the different factors in a project would influence which methodology to choose. AS you add people to the graph you move along the x-axis to darker versions of crystal. The more critical the projects deliveries are, the higher on the y-axis you move. Very critical projects will be suited for a harder version of crystal, meaning more restraints are added and a less agile approach used. As of today only three methods are constructed. These are crystal clear, crystal orange and crystal orange web, where only the two first have been proven in practise. The following policies are common to both crystal clear and crystal orange. Incremental delivery on a regular basis Progress tracking by milestones based on software deliveries and major decisions rather that written documents Direct user involvement Automated regression testing of fucntionality Two user viewings per release Workshops for product- and methodology-tuning at the beginning and in the middle of each increment 2.4.3.3 Characteristics 4 http://alistair.cockburn.us 19

Name Applies to crystal Author Alistair Cockburn First appeared 1990 Team size The crystal family is said to accomadate any team size (1-1000). Crystal clear up to 6 developers and crystal orange up to 40 developers. System criticality Crystal supports 4 basic criticality levels. These are defined to be when the failure results in the loss of life, the loss of essential money, the loss of discretionary money and the loss of comfort. Crystal clear can be used only when talking about the three last categories and crystal orange the last four. Iteration length For highly critical and large projects the each iteration can take as long as 4 months. Crystal clear has a recommended length of 2-3 months and crystal orange has from 2-4 months. Distributed teams Neither crystal orange nor crystal clear has this support, but it is to be taken into account in a later version. Prior knowledge needed Since the crystal family include many different approaches, some of which are not yet defined, this is one of the more demanding approaches when it comes to prior knowledge. Defined processes Crystal clear and crystal orange are as mentioned the only defined process as of today. These are in turn properly defined. Documented experience There a little documented experience of developers using methods in the crystal family. The book [22] that is considered to be the origin of crystal clear contains some information about it in its practical use and the motivation its development Comment The crystal family is fairly new and has yet to achieve the popularity of similar methodologies. What sets crystal apart from others however is the realization that there should be a range of methods to choose from where size and criticality are the important factors. Table 2.4: An overview of some key characteristcs of Crystal 2.4.4 Dynamic Systems Development Method (DSDM) 2.4.4.1 History DSDM is, according to its website, a framework based upon Rapid Application Development (RAD). RAD is an approach developed by James Marting during the 1980s as, most other agile methods, a response to non-agile models, and had as key point to increase the speed of development by using methods like iterative development, rapid-prototyping and CASE-tools. DSDM was developed in 1990s by a group of Information System (IS) specialists that combined their best-practice experiences. They founded the DSDM consortium, a non-profit organisation, which both maintain and owns the framework. Several DSDM framworks has been published, 20

the first was completed in 1995, and the latest in 2006 5. 2.4.4.2 Fundementals The fundemental idea behind DSDM is to make software on time and on budget. The way DSDM proposes to do this is to make the vary the amount of requirements included in the software instead of changing the prize or the number of developers working on it (see 2.8) as is usual. To accomplish this the consortium has defined nine key principles that guide the users of the framework and help get them in the right mindset. These are [23]: Figure 2.8: How DSDM differs from traditional approaches. Active user involvement is imperative DSDM Teams must be empowered to make decisions The focus is on frequent delivery of products Fitness for business purpose is the essential criterion for acceptance of deliverables An iterative and incremental approach is necessary to converge on an accurate business solution All changes during development are reversible Requirements are baselined at a high level Testing is integrated throughout the lifecycle A collaborative and co-operative approach between all stakeholders is essential The process itself is divided into three main phases, pre-project, project life-cycle and postproject. The project life-cycle is by far the most extensive and consists of 5 more sub-phases called feasability study, business study, functional model iteration, design and build iteration and 5 DSDM Public Version 4.2 (www.dsdm.org) 21

implementation. The first two are sequential, and only done once. The last three are iterated over while developing. To help users follow the DSDM principles, a couple of techniques are included in the life-cycle phase, these are: Timeboxing Timeboxing is used to support one of the main goals of DSDM, namely to complete projects on time and withing budget. The principle behind timeboxing is to divide the project into smaller portions that each are given a budget, a timeframe in which to complete a set of requirements. The requirements are priotized using the MoSCoW prioritisation scheme. MoSCoW Prioritisation A prioritisation scheme that relies heavily on the theory that 80% of the system comes from 20% (the pareto principle) of the requirements. MoSCoW stands for M - MUST have this, S - SHOULD have this if at all possible, C - COULD have this if it does not affect anything else, W - WON T have this time but WOULD like in the future.. Controlled prototyping Making a prototype of the complete system early on makes it easier to involve end users, and get valuable feedback that can be used to save time and improve requirements. Facilitated Workshops DSDM argues for the use of a workshop as an arena for stakeholders to meet and discuss progression, problems, requirements. The use of workshops makes it easier to manage and improve communication skills within a team. 2.4.4.3 Characteristics 22

Name Applies to DSDM Author DSDM Consortium First appeared 1995 Team size DSDM consortium recommend a minimum of two up to a maximum of six people in each team. A project can consist of several teams. System criticality There are no recommendations concerning system criticality and where DSDM is best suited. However DSDM focuses on Time To Market (TTM) an attribute that aren t that important when dealing with high risk systems. Iteration length Iterations are considered as timeboxes and their length is decided beforehand. A typical timebox and can last from a few days to a few weeks. Distributed teams There are no explicit claim that DSDM does or does not support distributed teams. Prior knowledge needed DSDM beeing more or less a commercial framwork it requires that your company becomes a member of the consortium and that the people that are using the framework are certified and properly trained. Defined processes The processes within DSDM are clearly defined and extensively documented. Documented experience Most of the documented experience are published within the consortium where you need to be a member to get access. There is however some articles ([24], [25]) and a book [26] that contains experience reports on companies that used DSDM. Comment There are little research done on this method outside the consortium and a lot of the material one might find useful you need to be a member to view. Table 2.5: An overview of some key characteristcs of DSDM 2.4.5 Feature Driven Development (FDD) 2.4.5.1 History FDD was devised by Jeff De Luca in cooperation with Peter Coad in the late 1990s. It started after De Luca was put in charge of completing a large development project for Singapore Bank and hired Coad to assist with the object modeling [27]. Using their experience they developed a set of processes that map, manage and build features. After the successful completion of this project there has been several implementations of FDD and a description of the approach was presented in the book Java Modeling in Color with UML, written by Peter Coad, Jeff De Luca and Eric Lefebvre in 2000. 23

2.4.5.2 Fundementals FDD consists of 5 basic stages shown in figure 2.9. Of there five stages there are only two who are iterative, nameliy design and build. The processes are described as follows: Develop an overall model The FDD starts with the developing of an overall model of the system. This is done by team stakeholders and domain experts who work together to create a walkthough of the system. Build a features list The team then creates a list of features which represents the system. Features are small parts of the system that are all useful to the client. Plan by feature The list of features is the prioritized and categorized into what is known as design packages, these packages are then passed to those who implement the system and each developer gets responsibility for one or more classes. Design by feature / Build by feature This is where the iterative part of the development starts. The cheif programmer chooses a subset of features that can be implemented in no more than two weeks. These features are then designed in detail, built, tested and integrated into the system. Figure 2.9: The 5 stages in FDD 2.4.5.3 Characteristics 24

Author Jeff De Luca First appeared 2000 Team size From 2-12, but team as large as 30 has reported success. System criticality FDD are one of the few agile methods that claim to be suitable for development of highly critical systems Iteration length Typical iteration length is one to three weeks. Distributed teams Not supported, but using FDD the participants are more losely coupled that other agile methods. Prior knowledge needed It prides itself as beeing a method that is easy to understand and easy to start using. Very little prior knowledge is needed. Defined processes FDD focuses mostly on the phases concerning design and development. These are well defined, but lack thorough documentation. Documented experience There are very litle freely available experience reports of FDD. It is still considered to be a well proven methodology its proponents. Comment It is a fairly new method that has gained the support of many practitioners by beeing based on industry bestpractises and because of it beeing easy to use and adapt. Table 2.6: An overview of some key characteristcs of FDD 2.5 Summary The discipline of software development is growing rapidly and is causing people to look for ways to improve the underlying processes. As the discipline continues to gain experience the people looking for better processes turn to ones that has been proven successful in the past and use these to create methods that can be reused in other settings and still attain success. Many of these methods has been an reaction to what has been the most widespread method in use, their popularity and their accaptance has been growing. When reviewing the characteristics of the agile methodologies included in this report you can see that they all differ in their approach, their strengths and their waeknesses, but they still keep true to the agile principles. All these differences makes it clear that the phrase there are no silver bullets [28] is as true now as it was when written in 1987. What Fred Brooks meant by this is that it is unlikely that there will appear a revolutionary technology or process that enables the software industry to develop at the same pace as the hardware industry does. Table 2.10 show a summary of the main characteristcs found in the agile methododologies I have included in this report. They are sorted by age and the definition of the rows are as follows: Age What is the methods age Team size What is the recommended team size Criticality Which levels of criticality is this method suitable for Iteration length What is the reccomennded iteration length Distributed teams Are distributed teams supported 25

Figure 2.10: A summary of the included agile methods Prior knowledge How much prior knowledge is needed to start using the method Defined processes Are the processes thoroughly defined. Documented How much documented experience is there 26

Chapter 3 Research This part of the report contains an overview over the research done in this project. It is divided into for parts which contains a short description of the research questions and how these were created, the motivation behind the choice of research approach, the considerations made when designing the research process and lastly how the process itself was executed. 3.1 Research goal and questions The definiton of the problem mentioned as mentioned in 1.3 is as follows: Survey what agile development methodologies Norwegian ICT companies uses, in which context they are used, and what attributes the companies value when choosing their development method. In order to better define the research questions a thourough prestudy was required. The goal of the predstudy was therefore to explore which development methods exist and by doing so more easily determine which qualities they require in order to be adapted successfully. There is written a lot of litterature on the subject, but much of it is either purely descriptive or accounts for successful implementations where the context is poorly described. In An introduction to agile methods, David Cohen et.al writes [4]: It is interesting to note that there is a lack of literature describing projects where Agile Methods failed to produce good results [...] this may be a result of a reluctance to publish papers on unsuccessful projects, or it may in fact be an indication that, when implemented correctly, Agile Methods work. While writing the prestudy a list was put together over what was found to be the most evident characteristics and limitations the methods had in common. The research questions are based on the items in this list combined with the definition of the original problem and are all listed in Table 3.1. 27

Name RQ1 Definition To which extent are agile development methods in use, or have been considered as the primary development method? The initial research question will determine whether agile development methods is in use today or has been considered a viable choice for the future. RQ2 To what degree does the customer influence the development method? Many of the projects announced by major companies include demands limiting the developers choice of tools, processes and methods. This research question will try to discover if this kind of influence or any influence at all is common in Norwegian companies. RQ3 RQ4 Is the customer an active participant in the development process? Customer involvement is a crucial part in most all agile methods. This research question is ment to explore whether customer involvement in any setting is customary by Norwegian companies today. Do the development method vary depending on the projects properties? This research question looks into which way properties like size, criticality, team co-location and time budgets affect the choice of development method and whether it is habitual to change or adapt the development method accordingly. RQ5 What properties do companies value in a development method? This last research question is ment to discover which properties the companies interviewed value most when choosing their development method. The properties found to be mentioned the most in the litterature was development time, cost, code quality, how well defined internal processes are and complexity. Table 3.1: Research questions 3.2 Research approach Research within the field of software engineering have three commonly used approaches; casestudies, experiments and surveys. A case-study is most often used to monitor or observe already existing or the introduction of new processes, tools, methods etc.. It usually includes a comparison to measurements called the baseline, this comparison is used in order measure the effects of the process, tool, etc.. An experiment is a controlled investigation conducted formally with and very spesific constraints. It makes it possible to control all the variables that might interfere with the results, making them easier to interpret. A survey is an investigation, usually performed in retrospect by analysing collected data, most often collected by the use of interviews or questioneers. It was quickly decided that the best research approach for this project was a survey. The reason was that it is the least time consuming to prepare, execute and analyze. It is also the most suitable method when considering what was plausible to hope for in terms of company interaction. According to Class Wohlin et. al. a survey can either be descriptive, explanatory or exploratory. A desriptive survey is where the research questions are already known and the survey tries to describe a situation or characteristics of a population. Explanatory surveys are used when one tries to find the relationships between observations. Exploratory surveys are used when the research questions are not clearly defined, and often performed when the topic is not clearly 28

understood [29]. This project can be said to use a descriptive survey. There are two main types of research paradigms that have different approaches to empirical studies. Quantitative research is concerned with studying objects in their natural setting [29], and is in the case of surveys represented in the form of an interview. Quantitative research is mainly concerned with quantifying a relationship or to compare two or more groups [29], and are in cases of surveys done using questionnaires. The difference between these two are often said to be the collected data, with qualitative research the data returned is text, and with quantitative research the data returned is numbers. To use a quantitative approach would have demanded more participating companies which is difficult and time consuming to obtain. It also demands a thourough preperation and a lengthy process of analysis. The choice of doing a survey is therefore considered to put this project into the category of qualitative studies. 3.3 Research design This section will further explain the reasoning behind the structure and design of the actual interview performed. It will also take a closer look on the selection of the sample used and present some basic information about the companies included in the sample and the details of the companies that ended up participating. 3.3.1 Interview The interview was designed based on the research questions and the information gained doing the prestudy. It was decided to use a combination of a general interview guide approach and an standardized, open-ended interview in order to ensure an easier analysis and a speedier interview process[30]. In order to do this an interview guide was created which gave a quick overview over which topics that should be covered and included some opening questions that could help the respondents get started. Most answers to these questions would make it easier to continue with follow-up questions that might not apply to all the respondents and therefore not be as easily put in the guide. The guide was written in Norwegian and can be found in Section 6.3. 3.3.2 Sample and context In order to get as generalized results as possible it was necessary to get interviews from an as wide as possible variety of companies. As with most other decisions concerning the research approach the time constraints limited the range of sampe choices and the number of interviews possible. In the case of what sample to use, choosing a convenience sample was the by far easiest and therefore choosen. A convenience sample is an nonprobability method used for picking respondents. It is most often used as an inexpensive estimation of the result where, as the name implies, the most convenient sample is picked [29]. To find the companies needed in this project a doctoral research fellow, Øyvind Hauge, was consulted. He has previously been part of a project that made a comprehensive list of suitable companies for another survey concerning the use of open source in an industrial context. Their 29

list was put together using all companies registered as under the category services affiliated with information technology in the Brønnøysund Register Centre and a convenience sample already available. In the resulting list they contacted approx. 1000 companies to discover if they were in fact involved in software development, they recieved 700 answers and of these only 550 answered that they were. After discarding all companies with less than 10 employees a list of 430 companies remained. In order to get the diversity we wanted in company size and type Øyvind sorted his list by size and picked out every twentieth company to contact for an interview. This resulted in a list containing 21 companies which we will for now treat as a random sample and view as a representative sample when it comes to the distribution of size and type of Norwegian ICT companies. This list contained name, contact information, the number of employees in total and the type of the companies. Figure 3.1 displays the distribution of these 21 companies divided into the three size categories; companies with an employee count between 10 and 24, between 25 and 99 and more than 100. Figure 3.1: A distribution of the company sizes from the original list The company type was determined by the industry code registered in the Brønnøysund Register Centre. Figure 3.2 displays the distrbution of these types. There were 5 different types registered in the original list, these were software development, computer whole-sale and consultancy, database management, other technical consultancies and electronic data processing. These codes are all subtypes of the industry code called services affiliated with information technology, the following text is used to describe the industry code: This category includes the following expertize: Software development, testing, altering and support. Planning and design of computer systems that integrate hardware, software and communications technology. The controlling and management of customers computer systems and/or electronic computer processing facilities and also other proffesional and technical computer related activities 1. 1 Translated from the Norwegian definition. 30

Figure 3.2: A distribution of the company types from the original list Figure 3.3: A distribution of the company sizes that agreed to participate 31

3.3.2.1 Participating companies Of the original 21 companies there were only 7 that participated in the interviews, this did not however significantly change the distribution of neither the company size or type. The most significant change was that none of companies that were listed to be working with database management were available for interviews. The resulting and final distributions are shown in Figure 3.3 and 3.4. Figure 3.4: A distribution of the company types that agreed to participate After the initial contact it became clear that some of the companies listed were not involved in enough software development to make a good subject in this interview, it also gave the companies that were interested the possibiliy to explain what kind of development their company was involved in. All of the companies except one were comfortable by the description found in the Brønnøysund registers. Considering the research of this project the number of employees are not as important as the number of actual developers working in that company. The interview provided both an updated count of employees and the number of developers, and are presented in Figure 3.5. The companies has been made anonymous on the request of all but two. A more detailed description of the companies and a summary of each interview is found in Appendix 6.4. 3.3.2.2 Respondents One person from each company was interviewed and the average age of all seven respondents was 41, varying from 30 to 51. Four of the respondents were IT managers, two had the title senior 32

consultant and the last had the title cheif consultant. Three respondents had a masters degree, three had bachelor degrees and one respondant did not have any education past high-school. All of the six respondents with higher education had their principle degree in informatics or computer science. 3.4 Research process All companies was first contacted and given information about the project and asked if they would be interested in participating. Table 3.2 displays what responses the initial calls yeilded. The companies that was interested proposed a suitable respondent and a convenient time and date for the interview was agreed upon. The interview guidelines was then sent as an e-mail to the respondent to give him / her time to prepare. All of the respondents were asked, prior to the interview, if they had objections to it beeing recorded. Only one objected and was therefore not recorded. In order to analyse the results of the interviews summaries of them was prepared and used as a basis to get the overview needed. These summaries are included in the Appendix 6.4. Response Occurences Interested 7 Not intersted 6 No time 6 No response 2 Table 3.2: Initial responses The interviews were performed between the 12. and 22. of November 2007. Since only 4 of the 21 companies had offices in Trondheim there were unfortunately not enough time to visit all the respondants and do the interviews face to face. All of the interviews except one were Figure 3.5: An overview over the numer of developers in each company 33

therefore performed over the phone, the last respondent returned the answers in written form. The interviews took from 10 minutes to nearly an hour. The time used seemed to be affected by the amount of preperation the respondent had done prior to the interview, and their interest in the subject of the interview. 34

Chapter 4 Results This chapter presents the results of the research done in this project split into sections covering each of the five research questions. 4.1 RQ1: To which extent are agile development methods in use, or have been considered as the primary development method? Of the seven companies interviewed there were two companies that used what is considered agile methods a majority of their projects. One of them used a modified SCRUM process with what they called a little bit of everything in it, and the other had adopted Test Driven Development (TDD) three months prior to the interview. A third company reported to switch between development methods depending on the project objective, their main development efforts used what he thought originally was a version of RUP, but had recently started to used SCRUM when doing smaller maintenance tasks or updates. Of the four companies that were not currently using agile methods three answered that their use of development method was constantly beeing evaluated. When asked if they had considered an agile alternative two of them answered they had considered XP, and one reported that they were not familiar enough with agile methods to consider it a real alternative. The final company had not discussed changing their development method recently and added that they were satisfied with the one they had. A overview over the responses is found in Table 4.1. 4.2 RQ2: To what degree does the customer influence the development method? The delivery of large projects might put constraints upon the delivery and the method, tools or processes used in developing a product. This research question intended to find if this is a 35

Company Method Considered agile Company 1 TDD FDD, SCRUM Company 2 Spiral No Company 3 RUP TDD, XP Company 4 Waterfall SCRUM Company 5 Waterfall No Company 6 SCRUM XP Company 7 RUP / SCRUM Many Table 4.1: Methods used and agile methods considered common practice by our participants. Of the seven companies there were only one that had heard of such a requirement beeing given from a customer. The requirements made by the customer had been on documentation rather than methods or tools, but had nevertheless made the impact on the development method used in that project. He emphasize however that this was not common for customers to do. All other six companies told of no such interest beeing shown by the customer, and furthermore four of the six companies explained that they assumed most of their customers did not have the expertise to see the significance. 4.3 RQ3: Is the customer an active participant in the development process? Customer interaction is one of the cornerstones of agile development methods, this ensures the ability to deliver working software in short iterations and is in itself a specific item in the agile manifesto (see 2.2.2.1). The involvement of the customer to the extent wanted can however be difficult, some agile methods suggests that in order to make the co-operation successful a knowledgeable representative from the customer needs to be part of the development team. Of the interviewed companies there were only three that answered that they had scheduled contact with the customer between releases, of these three the interval between meetings varied between once every two weeks to once every three months. When asked if a more contact with the customer was needed only one of these companies said it was. This participant said that even though their use of SCRUM proposed high levels of customer involvement this was difficult to achieve due to customer limitations. They had however choosen to make the developer in charge of customer relations act on behalf of the customer where this was needed, a compromise that had worked well so far. Another of the participants answered customer meetings almost always means added or changed features which again mean delays and used this as an argument for why more frequent meetings were not something they saught after. The remaining four participants said that there was little or no scheduled activity with the customer between releases. Two of these companies pointed out that there was the occasional e- mail or phone call from customers, where requirements had changed or maintenance was needed. 36

4.4 RQ4: Do the development method vary depending on the projects properties? As seen in the prestudy most development methods are connected to specific project types where it has been proven to give good results. Some of the methods claims to be usable in most settings, but it is commonly recognized that these still give better results if a number of project characteristics are met. A resonable effect of this might be to vary the method used depending on the projects characteristics, this is to some extent confirmed by the participants of the interviews. There were only one of the companies that never changed or adapted their development method. This was largely because their projects had so far been similar and suited their development method. The remaining 6 companies all made it clear that they adapted their method when the project required it, but only one company changed the method used. A summary of the responses found is located in Table 4.2. 4.4.1 Adaptation There were five companies in total that answered that they adapted their methods depending on the project, the motivation for doing so was either the size of the project or the projects objective. There were three companies that said they needed to add both tools and roles in a project exceeding a certaing size in terms of development effort. If the project involves more then 7 employees we need to assign at least one person to administrate the projects tools and be responsible for all testing. A more common scenario was the need for tools that made the distribution of tasks and responsibilites easier, and a more clearly defined projects manager. The remaining two companies did not alter their method according to the development effort, but rather according to the objective of the project. Both companies removed processes, and roles in maintenance projects or in cases where the delivery were only small updates. One could argue that this is cases where the the project size is significantly reduced. When asking one of the companies if this was the correct assumption, the answer was that this was inaccurate since especially the maintenance projects had often needed just as much development effort as their other projects. 4.4.2 Variation Only one of the interviewees had experience with varying the development method between projects. They had recently began to introduce SCRUM into projects where only minor adjustments in existing software was needed. They previously had adapted their development process according to objective, but had decided to change it completely to experiment. This he reported worked well with only minor problems during the transition. 37

Company Adapt used method Change method Company 1 Based on size No Company 2 Based on type No Company 3 Based on type No Company 4 Based on size No Company 5 Based on size No Company 6 Based on size No Company 7 Based on size/type Yes Table 4.2: Motivation for adapting and/or changing development method 4.5 RQ5: What properties do companies value in a development method? There are several key aspects that need to be taken into account when choosing a development method. What was found to be the most often mentioned properties in the littarature was development time (iteration length), cost, well defined processes and complexity. In addition to these there are requirements that has to be met in order to use certain methods, some of the agile methods for instance are suited to handle life critical systems, or distributed development teams as readily as traditional approaches. The ability to handle different kinds of projects is therefore also important to take under consideration. Propery Mentioned by companies Agile Traditional Quality assurance 7 2 5 Ease of use 3 2 1 Highly defined 3 1 2 Time-to-market 2 0 2 Flexibility 1 0 1 Low cost 1 0 1 Table 4.3: Properties valued highest by the companies One of the most coveted property discovered during the interviews was that the development method was easy to use and to introduce. The three companies that valued this property highest was also currently using methods described as easily understood. One of these companies responded we adopted TDD as a response to the growing complexity of our previously used method [spiral] and have by doing this we freed up approximately one years labour in managerial tasks, he goes on to say that this might not have been as easily achieved earlier with a more immature product. The most popular property was quality assurance, all companies mentioned that this was one of the properties they expected from their development method. This is a property all methods strive to maintain and can not as such be used as a selection criteria. There were 3 companies that wanted methods where the processes within was rigorously defined, and two that valued time to market. Other properties that were mentioned as important by one of the participants was flexibility of the method in terms of adaptation to project characteristics. Another company felt that the familiarity to the method was very important in order to reduce time used to teach the method 38

to new developers. An overview over the most valued properties and the currently used methods by the companies that valued them are located in Table 4.3 and discussed in the next chapter. 39

Chapter 5 Discussion This chapter consists of two sections, one that discusses the results found in the interviews and tries to tie this together with the relevant trends found in the prestudy and one section that looks at what can be the threats to the results validity. 5.1 General discussion One of the results of these interviews has been the insight into the readiness of Norwegian companies to take advantage of agile development methods. As discovered in the prestudy there are both benefits and drawbacks to using these methods, and this knowledge can be used to assess how existing processes can be improved and is therefore important in any process improvement initiative. Of the 7 companies there were only 2 who had not considered agile development, and these two had not made any serious contemplation of changing development method in the last two years. Of the other 5 companies all had on one time or another considered agile development, and the methods most mentioned were FDD, XP, SCRUM, and TDD. The results of the interviews also show that, despite the knowledge of agile methods, there are few that has taken the step as to start using them. The two companies that uses agile methods on a daily basis used TDD and SCRUM. Agile methods are known for their straight to the point approach and are lighter than traditional approaches without the need for much documentation and tools to enable the day to day workings of a development team. The ease of use was one of the properties most valued, but still there were only two that used agile methods on a daily basis. One reason could be that the companies are not aware of distinct benefits of agile development methods or rate their drawbacks as more important, but an equally important problem seemed to be that many consider any change in the method to cause inefficiency until the replacement method matured. This causes one to consider the familiar and currently used method easier than any new unfamiliar method. This assumption is partly backed up by the fact that among the companies that used agile methods all reported to have an agile advocate that initiated the change and used their knowledge to make the transition easier. The indignation towards change is however a natural disposition and cannot be attributed neither traditional of agile methods, the important question is therefore how one can make any such transition easier and make it easier for companies to choose the correct method of development. 40

Another property that was valued in a development method was flexibility, meaning the ability to be usable in multiple project contexts. This was only mentioned by one company despite that there were a majority of companies that changed their method between projects. This ability to scale up the process when dealing with a large or complex problem is most suited for the bureaucratic methods where the number of developers do not affect the efficiency of communication. The agile methods are better at scaling down, solving smaller projects efficiently using a more informal approach. The lone company that changes its development method entirely takes advantage of both these aspects, switching from traditional approaches to SCRUM when the problem becomes small enough. The drawbacks of this are overhead when switching methods, and maintaining developers that are equally comfortable with both methods. Of the companies interviewed there were also two that answered that their development method needed litle or no change between projects because of their similarity in characteristics. The choice is therefore easier if there is mainly one kind of projects that needs to be taken into account, but there is no clear supremacy in any of the three discovered approaches. The litterature on agile development points out a few differences from that of traditional development, when looking for confirmation that these were in fact correct when dealing with the companies in this sample the following was found. All three companies that used these methods had co-located teams, as did the four remaining companies. That it is an important item in the agile list can hardly be disputed, and our results does nothing more than confim that it is common. The same is shown when exploring the iteration length, and team size (see Table 5.1). The two agile companies have considerably shorter iteration length and smaller team sizes than the average of the other companies. While the iteration length of all companies is approx. 7 months, the average for the two agile companies was only 2 months. The team size on average of the agile companies was 4 while the average of the remaining companies was 10. This again shows that these companies are in sync with that of other agile developers, and that they are thereby gaining the benefits this entails. An important aspect of these benefits, however, is that in total, the average length of an agile project is less than half the length of an average traditional project. This shows that even though the agile companies have shorter iterations and smaller teams, they also have shorter projects with more releases. This translates into less development hours used and might affect the type of projects these companies can handle. The aspect of project size, and complexity is also mentioned in the litterature as a limitation of agile development methods, but if this is a direct result of the development method or just a strategic choice of projects the companies handles is not clear. The responses from the interviews do however give an indication that this might be the case. Item Agile average Traditional average Team size (developers) 3,5 10,1 Total project length (duration in months) 4,5 10,6 Iteration length (duration in months) 2 6,9 Table 5.1: Project differences During the interviews the level of customer involvement was also discussed. The customers involvement in choosing the development method and their level of commitment in the actual development process was the two main areas of questioning. The responses that was recieved made it clear that there are few projects that require a specific CMM level or an ISO certified life cycle process, there were only one company that had changed its development method in order to more easily supply the documentation required by their customer. The ISO certifications does probably only apply to larger or more complex systems than the ones the companies interviewed 41

are involved in. This does also mean that there are only a minority of Norwegian companies that are affected by such requirements, and that such requirements are seldom a very important factor when choosing a development process. As presented in the results different qualities are sought-after by the respondents, the only conclusion that can be derived from table 4.1 is that of all interviewed companies all, as expected, value quality highly. What you also notice is that two of three companies using agile methods value ease of use highly. This impression was reinforced by the respondents during the interviews, when trying to explain qualities or differences in methods, they all emphasized their ease of use and the positive response this had gotten from their developers. This might indicate that lightweight processes and their workings grow in appeal after the initial getting used to. 5.2 Validity This section is structured and defined as reccommended in [29]. Since this research is done qualitatively and the purpose of this qualitative studies is to explain and understand a phenomenan, both the conclustion validity and the construct validity are excluded. The ability to generalize results is also not that important and makes the statistical validity insignificant in this project. 5.2.1 Internal validity Internal validity is related to whether the results are valid for the population the sample is taken from. There is a risk that some of the companies did not answer truthfully in order to make themselves and their company appear favourable. Three companies requested that the results should be made anonymous, presumably in order to not disclose details that might be considered harmful. This was requested while making the first contacts with the companies. This was first considered to just apply to the companies mentioned, but after mentioning it to the remaining companies the ones interested also agreed that this was a good idea. This was then told to all the respondents which hopefully resulted in more honest answers. There will however always be a risk of dishonest answers considering that it cannot be completely anonymous when the interviewer at least knows who the interviewee is. Some of the questions included terms that do not have any one clear definition, or might not be previously known by some of the respondents. When asked, these terms was explained more thoroughly and the underlying theories presented. There is however a risk that some respondentes did not ask for a proper explanation or that two respondents have differing ideas as to what one term might entail. This risk of this could have been reduced by either clearify all such terms prior to the interview or restrain from using them all togheter. 5.2.2 External validity External validity is related to whether the results are valid for other populations. The main threat to external validity is the sampling of respondents to the survey. There are much uncertainty if the population we started with, a list of 450 Norwegian companies, could represent the population of all Norwegian ICT companies. When reducing the sample to the 21 42

contaced companies this further increases the uncertainty. The statistical power of the interviews are also very low, with only 7 responses. This makes it difficult to draw any general conclusions. This effect is enhanched by the use of a convinience sample, which makes any kind of statistical generalization difficult, if not impossible. 43

Chapter 6 Conclusion and further work This chapter presents the final conclusion and presents the discovered possibilites for using some of the results for further work. 6.1 Conclusion The information gained from the interviews show some difference between the participating companies, the results that are presented shows us that, in our sample, a majority of companies have considered using an agile method in their development process despite the fact that none of the companies interviewed have the degree of customer involvement described as important in most of the methods and the agile manifesto. None of the companies had experienced any customers that required a specific development method, but most of the companies adapted or changed their method depending primarily on the projects size, type and duration. They did this mostly in response to their current method not beeing sufficient in all cases. One of the companies changed their entire method between projects. This company was also the only one that mentioned flexibility as one of their highly valued properties. The most highly valued property was the implementation of high quality software, agile method users also valued the newly found simplicity in their methods. The differences between the companies became clearer when reviewing their projects characteristics. The variations in average team-size, duration and iteration length makes the agile companies stand out from the rest. They seem to do their development in smaller teams, with smaller iterations using less time. Which can only be explained in either supremely talented workforce or smaller projects. This also indicate that agile methods might not be as easily used in large and complex systems, or with teams of average developers. What the interviews have made clear is that there are a difference between the participating companies with their practice and the way both traditional and agile methods projects are presented in the litterature. Some of the projects did not have a customer or they might not have any requirements. The developers also often needed to work on several projects at the time, not working on the same project every day. These variations seems to make some methods more inadequate than others, but none of the methods explored in this study have clear guidelines that handle such exceptions. 44

This study has given some overview in the area of Norwegian developers and their thoughts on development methods in general. Even though there are differences between the companies, they all search for the same thing, a process that enables the delivery of high quality products on time, and on budget. There is no silver bullet so in the end it depends on prioritisation of properties and choosing one that suits your project portfolio and both management and developers are satisfied with. 6.2 Further work To further seek the characteristics needed in order to successfully introduce agile methods a more detailed view of a single company would be helpful. An exploration of the details that either make a company succeed or fail will make it easier to pinpoint the reasons behind the outcome. Details to include could be technology, project complexity, type or oberservations concerning their efforts, this would make it easier to put together a more nuanced picture that could be analyzed. To further the research on the results found here there are a few interesting aspects that could be explored. Firstly it would be interesting to se if there was any difference in software quality depending on team size or iteration length. It would also be interesting to see if a company can combine the use of several methods to counteract the drawbacks of each method used individually, and if it can be done efficiently. One could also ask what development methods are suited for projects where continual development is impossible, or for projects consisting of 1-2 developers. 45

Glossary Agile Having the faculty of quick motion; nimble, active, ready. 1 The agile manifesto (see Section 2.2.2.1) has since its creation been widely regarded as the canonical definition of agile software development and its pinciples. Software engineering The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software [5]. Software development process An organized set of activities performed to translate user needs into software products [7]. Pareto principle The program-design version of the law of diminishing returns. The 80/20 rule says that roughly 80% of the problem can be solved with 20% of the effort that it would take to solve the whole problem. 2 Evolutionary Delivery The development of usable software sub-systems in very small steps, with user requirements being continually re-assessed after each delivery [10] 1 Oxford English Dictionary, dictionary.oed.com, 24.09.07 2 Free Online Dictionary of Computing, http://foldoc.org/?eighty-twenty+rule, 23.10.07 46

References [1] W. W. Royce, Managing the development of large software systems: Concepts and techniques, Technical Papers of Western Electronic Show and Convention (WesCon), pp. 1 9, 1970. [2] B. W. Boehm, A spiral model of software development and enhancement, IEEE Computer, vol. 21, no. 5, pp. 61 72, 1988. [3] J. S. Reel, Critical success factors in software projects, IEEE Software, vol. 16, no. 3, pp. 18 33, 1999. [4] M. L. David Cohen and P. Costa, An introduction to agile methods, Elsevier, vol. 62, 2004. [5] IEE, IEEE standard glossary of software engineering terminology, IEEE Standards Description: 610.12-1990, 1990. [6] J. W. M. Alain Abran, Guide to the software engineering body of knowledge. IEEE Computer Society Press, 2004. [7] K. Rigby, Definitions and general criteria for technical management, http://sparc.airtime. co.uk/users/wysywig/gloss.htm, 2007, visited 09.10.07. [8] J. Nandhakumar and J. Avison, The fiction of methodological development; a field study of information systems development. Information Technology and People, vol. 12, no. 2, pp. 176 191, 1999. [9] R. B. D. P. Truex and J. Travis, Amethodical systems development: The deferred meaning of systems development methods. Accounting, Management and Information Technology, vol. 10, pp. 53 79, 2000. [10] T. Gilb, Principles of Software Engineering Management. Addison-Wesley Professional, 1988. [11] J. H. et.al, History: The agile manifesto, http://agilemanifesto.org/history.html, 2001, visited 25.09.07. [12] A. A. Cockburn, Using vw staging to clarify spiral development, Humans and Technology, 1997. [13] M. C. Paulk, Extreme programming from a cmm perspective, IEEE Software, vol. 18, no. 6, pp. 19 26, 2001. 47

[14] J. Rasmussen, Introducing xp into greenfield projects: lessons learned, IEEE Software, vol. 20, no. 3, pp. 21 28, 2003. [15] D. Karlstrøm, Introducing extreme programming - an experience report, Proc. 3rd Int l Conf. Extreme Programming and Agile Processes in Software Eng, pp. 24 29, 2002. [16] C. Poole and J. Huisman, Using extreme programming in a maintenance environment, IEEE Software, vol. 18, no. 4, pp. 42 50, 2001. [17] Controlled chaos : Living on the edge, White Paper, Advanced Development Methods, May 1996, http://www.controlchaos.com/download/living%20on%20the%20edge.pdf. [18] Scrum and xp from the trenches, White Paper, CRISP, 2007, http://www.crisp.se/henrik. kniberg/scrumandxpfromthetrenches.pdf. [19] N. Rising, L. Janoff, The scrum software development process for small teams, IEEE Software, vol. 17, no. 4, pp. 26 32, 2000. [20] G. Smits, Hubert Pshigoda, Implementing scrum in a distributed software development organization, AGILE 2007, pp. 371 375, 2007. [21] K. Highsmith, J. Orr and A. Cockburn, Extreme programming, E-Business Application Delivery, pp. 4 17, Feb 2000. [22] A. Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams. Addison- Wesley Professional, 2004. [23] Dsdm, enabling businees agility, White Paper, DSDM Consortium, 2007, http://www. dsdm.org/knowledgebase/download/100/official dsdm overview presentation pdf.pdf. [24] A. Airth, Accelerated Solution Centers - Implementing DSDM in the Real World. Springer Berlin / Heidelberg, 2002. [25] D. Barritt, Iec 61131 and dsdm in real-time process control applications, Computing & Control Engineering Journal, vol. 13, no. 2, pp. 94 100, 2002. [26] J. Stapleton, DSDM: The Method in Practice. Addison-Wesley Longman Publishing Co., Inc, 1997. [27] J. D. Luca, Jeff de luca s biography, http://www.nebulon.com/pr/bio.html, 2007, visited 20.10.07. [28] F. P. Brooks, No silver bullet - essence and accident in software engineering, IEEE Computer, vol. 20, no. 4, pp. 10 19, 1987. [29] M. H. M. C. O. B. R. A. W. Claes Wohlin, Per Runeson, Experimentation In Software Engineering - An Introduction. Kluwer Academic Publishers, 2000. [30] D. Valenzuela and P. Shrivastava, Interview as a method for qualitative research, http: //www.public.asu.edu/ kroel/www500/interview%20fri.pdf, 2007, visited 23.11.07. 48

Appendix 6.3 The interview guide 49

Undersøkelse om smidige utviklingsmetoder Om undersøkelse Undersøkelsen gjennomføres som del av et fordypningsprosjekt høsten 2007 ved Instituttet for Datateknikk og Informasjonsvitenskap (IDI) på NTNU. Oppgaven består i å kartlegge bruken av smidige utviklingsmetoder i norske IKT bedrifter. Denne undersøkelsen er en viktig del av oppgaven som vil gi innblikk i hvilke metoder som blir brukt i norske bedrifter i dag samt motivasjonen bak valget av disse. Informasjonen som kommer frem i denne undersøkelsen vil bli bruk i arbeidet med å utforme Snorre Nævdal, en 5. års student ved IDI, sin fordypningsoppgave. Dersom det er ønskelig vil informasjonen bli behandlet konfidensielt. Informasjon om intervjuobjektet Navn Stilling Alder Høyeste utdanning Informasjon om selskapet/avdelingen Navn på selskapet Avdeling Kundeprofil Intervju Antall utviklere i din avdeling Antall ansatte i Norge Hvor mange jobber sammen på et typisk prosjekt? Hvis flere, er disse samlokalisert? Hva er typisk lengde på et typisk prosjekt? Hvor lang tid går det mellom utgivelser til kunden? Antall måneder, månedsverk, etc. Har måten å utvikle programvare på i din bedrift vært oppe til diskusjon de siste 2 år? Hvis nei, er dere fornøyd med måten dette gjøres på? Kjenner dere til alternativer? Hvis ja, hvilke alternativer er undersøkt? Har selskapet / avdelingen klare utviklingsmetoder for programvareutvikling? Hvis nei, har det vært aktuelt? Hvordan foregår en typisk utviklingssyklus? Hvis ja, kan prosessen klassifiseres (inkrementell, smidig (agile), vannfall, evolusjon, annet.)? Er den navngitt? Trengs det mye opplæring for å introdusere nye medarbeidere til utviklingsmetoden? Hvis ja, er denne opplæringen noe alle kan gjøre Varierer utviklingsmetoden fra prosjekt til prosjekt? Hvis ja, varierer disse ut fra prosjektets faste egenskaper (størrelse, kritiskhet, tid, kostnad)? Hvilke egenskaper synes du er viktig at en utvikingsmetode fokuserer på? Lav utviklingstid, lav kostnad, høy kvalitet, høy trivsel, standardiserte prosesser, annet Stilles det krav av kunde angående hvilke metoder som bør benyttes? Hvis ja, hvilke krav? Hvis nei, er dette noe du tror kunden ville vært interessert? Er du fornøyd med måten programvareutviklingen håndteres på i dag? Hvis nei, hva kunne vært bedre?

6.4 Sample context The following section presents in more detail the results of the interviews done in this project. Each company is described in turn and the most important results are included. All interviews were done in Norwegian so any quote is freely translated. 6.4.1 Company 1 This company has 20 developers of a total of 32 employees. A rough estimate of the time budget of a typical project was 6 months, there were several projects that lasted significantly shorter, but the largest projects had taken or were planned to last even longer. A project involved commonly between 3-5 developers. There were several developers that worked on more than one project at any given time, which made it possible to shift their efforts towards the highest prioritized project. After they had changed their development method, the average time between releases were 2-3 months. They currently used TDD as their primary development method. They changed their method a year ago, and went from having a process called they called modified ad. hoc. towards the agile alternative they now used. Both XP and FDD had been considered as alternatives, but the familiarity some of their developers had to TDD had been decisive. When asked what the most valued property was considered to be the answer was this would probably differ from person to person, but what most people has commented to me is how they like the absence of processes few understand or agree with. He goes on to say that this might be because their current method simply is easier to use and understand, but also might be an effect of beeing recently introduced and thereby explained more thoroughly. When it comes to customer involvement the interviewee explained how this differs among customers, some are interested in a close collaboration and other just want to be handed the completed product. There were no current customers that that thought would consider to participate actively in the development process. There had however been a project that had so strict documentation requirements that it had affected their development method, this he considered to be a rare occurance. They were altogether pleased with their method, but were sure that it would evolve with the company to become even better in the future. 6.4.2 Company 2 THe second company has 15 developer of a total of 26 employess. Their developers were divided into to seperate groups, where one focused on maintenace and updates of existing products and the other of development of new products or major extensions/updated to existing ones. Only the last of these groups had internal projects, the size of these could vary between 5-10 developers. If the need arose one of the developers would switch group for a time. Their typical project lasted 12 months, they did not have any deliveries in between, and did not divide the project into seperate increments, or deliver in iterations. Their development method was characterized as a modified waterfall model. The interviewee also compared it to the spiral model, but was not confident about what the particular differences was. Their method had been with them as long as the interviewee had been employed and they had a three weeks course for all new developers joining their team, this course included the introduction to their development method, but this was not considered its main purpose. They also had one developer that were 51

their guru on this method so all questions and suggestions for changes went through him. When asked which properties they valued most it was made clear that the ability to keep down the defect density, along with having a clear checklist of steps and processes in the development was the most important, and the resason they kept their existing method. It was not always clear who the customer was, and therefore involvment by the customer in the development process was rare. Most input came during the specification of the requirements. There had not been any customers with preferences towards their use of either tools of methods. In all the developers were very pleased with their development method and had not seriously thought of replacing in the last two years. 6.4.3 Company 3 This company has 35 employees and of them there are 20 developers. Their average project consist of approx. 10 devlopers where some with pericular expertise often divide their time between several projects. Their last two projects had lasted 6 and 10 months which was said to be representative for most of their development projects. When smaller maintenance or update tasks were needed the developer responsible for the system usually did it alone or in pairs. The projects the interviewee spoke of had been released to the customer two times while in development, when asked if this was the usual iteration length between releases he answered that this depended entirely on the customer, and the workload at the time. They considered the most valuable property in a development method to be the ability to ensure of high quality delivered code be it by methods or tools, and short time to market. They used a tailored variation of RUP and were confident that it was simple enough to understand, but at the same time complex enough to ensure the properties they wanted. The introduction of their current method had been done 6 months prior to the interview and it was therefore said that some aspects of their method might get better by time. Before switching they had also considere some agile methods, the ones the had been ranked the highest was FDD and XP. Currently they adapted their method slightly depending on the project type, but was pleased with the scalability of RUP. Due to some delays the managers were however not pleased with the current time to market. When asked about customer collaboration the answer was that he thought they had the average amount of customer input, there were planned meetings where progress and requirements was discussed, and on average at least one partial delivery before the projects completion. None of our customers have asked for closer collaboration or showed interest in which tools or methods we use, this might be common in larger projects, but I can t see the need for in the kind of development we do. 6.4.4 Company 4 This was one of the larger companies in the sample with a total of 90 employees and of these 35 developers. It was explained how their development cycle lasted between 6-8 months and that their traditional development method did not support iterations. Their last completed development effort had lasted almost 7 months, and they had in that time had monthly update reports to the customer. When asked if closer collaboration was needed the answer was simply No. 52

They had looked into changing methods very recently, mostly because of a proponent of SCRUM had held a developers meeting where he introduced the method and prior experience with it, this had started a debate that had not reached any conclusions yet. When asked what properties they wanted a development method to provide, both low time to market and high code quality was mentioned. When considering these two properties they were reasonably pleased with their current method, even though it might be a bit to slow for the smallest tasks. When asked if they adapted their method between projects the answer was a simple Yes. As one of the shortest interviews, this interview had an abrupt ending were the interviewee had some kind of emergency, he then curtly apologized and said goodbye. A second attempt to conclude the interview also failed. 6.4.5 Company 5 This company was one of the smaller in this sample with a total of 35 employees where 12 worked as developers. They were used to working in small teams of between 2 and four developers. They used what they described as a regular development method, that when explained seemed like a variation of the waterfall model. Their average development cycle lasted between 8-12 months, but the respondent emphasized that this depended more on customer requirements than method limitations and that it could be considerably shorter. Multiple releases was not common, but again depended on the customer. All of their developers were located in the same office space. The respondent were not familiar with the term agile methods, and could not give a clear answer as to whether this had been considered an alternative. We are happy with the way development is done today, and have therefore not looked for any alternatives. Their most valued property with their current development method was the low cost and it effectiveness. The respondent also said discussed how their developers knew well their current processes, and explained that this probably was one of the reasons behind its success. The respondent could not find any aspects that needed improvement or was missing. There had not to date been any customer interested in the development processes or tools. The common scenario was a monthly progress report, in addition there could be any number of meetings were additional requirements or features were discussed. Some customers were more interested in the development than others, but continuous involvement had not and would probably not be something suited for their company. 6.4.6 Company 6 Company number 6 are the smallest company interviewed. Their development department consisted of not more than 4 employees of the total 24. They were also one of the 2 companies that used agile methods on a daily basis. Their method was described as tailored SCRUM and had been introduced 8 months ago. When changing to SCRUM it had been one of the two agile alternatives considered, the other was XP. They had also considered traditional spiral models, and more incremental waterfall, but due to the fact that the newest employee was a certified SCRUM master the choice became easier. A typical project lasted on average 3 months and consisted of between 1-4 of the developers. They had close collaboration with the customer and tried make at least two releases on each small projects and a release a month on the larger projects. 53

The respondent considered their current method very simple and pointed to their procedures as the most important reason. When asked what the most important properties of the development methods they considered the answer was short time-to-market, close customer collaboration and easily understandable, no nonsense procedures. Their projects required close customer collaboration, but it has of yet been restricted to frequent meetings and not participation in the development team as such. They had not recieved any requirements where specific methods was needed, they had on their own realized that their projects types required an agile method. Their method did change somewhat depending on the project size, larger projects required more participants and roles or responsibilities needed to be distribute differently. The respondent told they were pleased with their current method, but mentioned several shortcomming they discovered early using unmodified SCRUM. The largest challange they had presently was the ability to use any method efficiently on teams consisting of 1 or 2 developers. 6.4.7 Company 7 The last company are the largest of the seven and has a large base of employees throughout Norway. The respondent in this company delivered his responses via e-mail so the possibility to extract detailed information was limited. The department the respondent worked in consisted of 26 developers, although most of their projects are usually done in collaboration with other departments. Using the last two projects as a basis their total development time was approx. 18 months. This included three releases making each iteration last 6 months. They were in between development methods at the moment, experimenting with SCRUM and at the same time using a method based on RUP. The respondent was mostly satisfied with their current approach, but would happily welcome a larger degree of agility. He also states that the method used largely depended on the project characteristics, it could cause alterations in existing methods or justify the use of agile methods. The most valued properties was the flexibility to be usable in different project types, easy to use without unnecessary focus on time consuming routines not directly constributing to either the quality or progress of the development. The need for quality assurance was also higly prioritized. The respondent did not know of any customer requirements specifying the method used, but assumed that the important thing was to have a method and use it. 54