Agile project management

Agile project management - The software development processes Master thesis, 15 hp, SYSM02 informatics Presented: 2011-06-16 Authors: Niklas Berndt Emily Jönsson Supervisor: Agneta Olerup Examiner: Björn Johansson Hans Lundin

Abstract Title: Authors: Agile project management The software development processes Niklas Berndt Emily Jönsson Publisher: Supervisor: Examinations: Institute of informatics, Lund s University Agneta Olerup Björn Johansson Publication year: 2011 Hans Lundin Thesis type: Language: Key words: Master thesis English Project methodology, Agile, Scrum, Usefulness, Values, Principles, Change, Practice Abstract This study focus on finding how project usefulness is connected to the Agile software development process. In order to narrow the broad research area down we have decided to only focus on the most adopted methods within software development, Scrum. The research model consists of values, principles and a project process model describing how an Agile/Scrum project process ought to be together with project usefulness found in models and guidelines. Five interviews, within three different companies, were made in order to find out what their Scrum process looks like and to find project usefulness. Our findings was then discussed and analysed in comparison to the research model. A suggestion on what different features in the Scrum project process results in project usefulness is illustrated. The different features in a Scrum project process that results in the most project usefulness are: working with sprints and the daily Scrum. Daily Scrum result in more flexibility, a learning environment and more productivity. Working with sprints results in more flexibility, a closer customer relationship, a more customized product and more productivity. i

Contents 1 Introduction...1 1.1 Research focus... 2 1.2 Purpose... 3 1.3 Delimitations... 3 2 Models and guidelines...4 2.1 Traditional project methodology... 4 2.2 Agile Project methods... 6 2.2.1 Values... 8 2.2.2 Principles... 10 2.3 Scrum... 14 2.3.1 Roles... 15 2.3.2 Daily Scrum... 15 2.3.3 Scrum process... 16 2.3.3.1 Pregame... 17 2.3.3.2 Game... 20 2.3.3.3 Postgame... 21 2.3.4 Usefulness with Scrum... 21 2.4 The difference between traditional project and Agile projects... 22 2.5 Research model... 24 3 Method...29 3.1 Selecting a method... 29 3.2 Sample... 31 3.3 Interview guide... 32 3.4 Interviewing, transcribing and analysing... 35 3.5 Validity and reliability... 36 3.6 Ethics... 37 3.7 Criticism of the sources... 38 4 Findings...39 4.1 The companies... 39 4.1.1 Company A... 39 4.1.2 Company B... 40 4.1.3 Company C... 41 4.1.4 Summary of company findings... 42 4.2 Values... 43 4.2.1 Summary of Value findings... 44 4.3 Principles... 44 4.3.1 Summary of Principle findings... 46 4.4 Scrum processes... 47 4.4.1 Company A... 47 4.4.2 Company B... 49 4.4.3 Company C... 50 4.4.4 Summary of the company Scrum processes... 52 4.5 Usefulness... 53 ii

5 Discussion and Analysis...55 5.1 Values... 55 5.2 Principles... 57 5.3 Scrum process... 61 5.3.1 Before Scrum... 61 5.3.2 Pregame... 62 5.3.3 Game... 64 5.3.4 Postgame... 66 5.4 Usefulness... 67 5.5 Features in the Scrum processes that result in project usefulness... 69 5.5.1 Agile values and principles connected to the Scrum process... 69 5.5.2 How the Scrum process is connected to project usefulness... 72 6 Summary...74 7 Conclusion...80 Appendix...82 Interview guide in Swedish... 82 Interview guide in English... 84 Transcription... 86 7.1.1 Interview A1... 86 7.1.2 Interview A2... 89 7.1.3 Interview B1... 95 7.1.4 Interview C1... 103 7.1.5 Interview C2... 107 References...114 iii

Tables and figures Table 2.1: Ought's and Are's of projects. (Blomberg, 2003)... 4 Table 2.2: The Ought's from Agile values... 10 Table 2.3: The Ought's from Agile principles... 13 Table 2.4: Comparison between Waterfall and Agile, (Morien & Wongthongtham, 2008, pp.230)... 22 Table 2.5: Values in our research model... 25 Table 2.6: Principles in our research model... 26 Table 2.7: Usefulness with Agile/Scrum in our research model... 28 Table 3.1: Introduction questions... 32 Table 3.2: Agile questions... 33 Table 3.3: Scrum questions... 34 Table 3.4: Closure question... 35 Table 4.1: Summary of company findings... 42 Table 4.2: Summary of value findings... 44 Table 4.3: Summary of principle findings... 46 Table 4.4: Summary of the company Scrum processes... 52 Table 4.5: Summary of usefulness findings... 53 Table 5.1: Research model of values with empirical findings... 55 Table 5.2: Research model of principles with empirical findings... 57 Table 5.3: Research model compared to empirical findings of usefulness... 67 Table 6.1: Summary of Agile features connected to the Scrum process features... 79 Figure 2.1: Scrum phases... 14 Figure 2.2: Scrum methodology, (Schwaber, 1995, pp.10)... 16 Figure 2.3: Scrum process, (Abrahamnsson, et al., 2002, pp. 28)... 17 Figure 2.4: Research model for Scrum process, (Abrahamnsson, et al., 2002, pp. 28)... 27 Figure 4.1: Scrum process for Company A... 48 Figure 4.2: Scrum process for Company B... 50 Figure 4.3: Scrum process for Company C... 51 Figure 5.1: Pregame phase... 62 Figure 5.2: Game phase... 64 Figure 5.3: Postgame phase... 66 Figure 5.4: Agile features incorporated to the Scrum process model... 70 Figure 5.5: Scrum features connection to project usefulness... 72 Figure 6.1: Summary of Scrum processes... 75 Figure 6.2: Summary of values... 76 Figure 6.3: Summary of principles... 77 Figure 6.4: Summary of usefulness... 78 Figure 7.1: Scrum features connection to project usefulness... 80 iv

1 Introduction This chapter begins with presenting the background to a contemporary and relevant subject, Agile project methodology. Next the research, focus together with the delimitations for this thesis will be provided. In the 1980 s many software applications were akin to basic methods seen in factory production many programmers had to create large amount of code that was needed to run the software and what was ordered was usually delivered (Alleman, 2002). In recent years software development has changed; pressure from the market, changing requirements, the Internet and more powerful programming languages has set a higher level for software developments projects. Over time methods such as waterfall, the spiral model and process programming evolved and were replaced by new processes/methods (Alleman, 2002). There was a need for operations that were efficient in responding to a changing environment while at the same time productive and this is where Agile methods were introduced (Aaen et al, 2007). Agile system development methods are relatively new and founded on the Agile manifesto. The whole idea of the Agile manifesto, was invented in February 2001 by a group of seventeen noted software process methodologists (Chow & Cao, 2007; Highsmith, 2001). The different methodologists all represented an already existing method, for example Extreme Programming, Scrum, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. They all had especially one thing in common; they wanted to advocate a better way of developing software (Chow & Cao, 2007). The methodologists wanted to come up with an alternative to the already existing way of documentation driven, heavyweight software development processes, and to find a common ground (Highsmith, 2001). The authors of the Agile manifesto do not want people to see the Agile movement as an anti-methodology, their aim was to restore a balance between modelling, documentation and planning (Highsmith, 2001). Anderson (2004) claims that the Agile methods, an umbrella term for the methods mentioned above, were developed in order to enable faster, cheaper, better software development with ontime, on-budget delivery of the agreed scope. Agile methods are often mentioned in the context of the lightweight activities when used to manage the development or acquisition of software (Alleman, 2002). Alleman (2002) describes lightweight activities include requirements, design, coding, documentation and testing processes, when using a minimal set of activities and/or artefact to reach the end goal which is a working software system. 1

Right now, Agile methods are popular and this has resulted in many user groups, books, articles and increased popularity of the annual Agile Development Conference as more organisations start to adopt the Agile development method (Morien & Wongthongtham, 2008). However, Dybå and Dingsøyr (2008) claim that researchers need to increase both the quality and the numbers of studies focusing on Agile software development. There are many different Agile methods, as stated above, but there is very little known about them, for example how to practice them and the result when adopting one of them. Some researchers have also argued that the research and information within Agile project methodology is seen as vague in academic circles (Chow and Cao, 2007; Abrahamsson et al., 2003). Alleman (2002) and Abrahamsson et al. (2003) discuss this vagueness as a gap of theory, in the sense that practitioners or consultants have authored most existing publications. In other words, there are books and articles found on this subject, but there are not many scientific writings. Most of the literature is normative and based on experience from consultants and/or practitioners. There is thus a need for scientific reports collecting information and making a summary of all normative information about Agile methods and also to make comparisons with the practical use. Scrum is the most widely adopted Agile project management method and is applicable on software projects (Björkholm & Brattberg, 2010; Abrahamsson, et al., 2002). The aim of the Scrum method is to deliver as much quality software as possible within a limited time span, typically a month (Beedle, et al., 1999). Similarly, Abrahamsson et al. (2002) notes that Scrum is the best-known method developed for managing the system development process. This method has also been very successful when used at leading edge software companies (Schwaber, 1995). However most empirical studies and papers about Scrum have been published after the year 2007, which means that the topic is relatively new and perhaps therefore still a bit unfamiliar (Hossain, et al., 2009). Since Scrum is the most applied of all Agile methods, and Agile methods are a group of methods that are generally considered as vague in academicals circle, Dybå and Dingsøyr (2008) suggest that Scrum ought to be more closely looked at. 1.1 Research focus Agile project management is a relatively new group of methods and more research needs to be made within this area, since it is unfamiliar and most literature written is seen as vague in academically circles. It is seen as vague because much of what has been written about Agile methods is normative, reviewing how the project process ought to look like not what it looks like. We therefore identify a gap here, between the normative literature and what the Agile methodology project process looks like in practice, thus a lack of scientific research about Agile methods in practice. So, we believe there is a need for a scientific study of how Agile methods are used in practice. There is also lack of information about the outcome, when applying an Agile method. There are several project usefulness factors describes in the normative literature, 2

but it needs to be considered in context, how the Agile software development process is connected to project usefulness. By project usefulness, we mean different advantages or benefits that a project can achieve when using Agile methodology in a software development project. Therefore the focus of this thesis will be on what the Agile software development process looks like and find out how project usefulness can be connected to it. Main question: How is project usefulness connected to the Agile software development process? Sub questions: What does the process, when applying Agile software development process, look like? What are the features in an Agile software development process, and what are the project usefulness that can be identified when applying Agile project methodology? 1.2 Purpose The purpose of this study is to identify features in the Agile software development process that are important for achieving project usefulness, in order to contribute to a more scientifically accepted basis in the area of Agile software development methods. By looking at the Agile software development process and how it is applied in practice we will be able to find differences and similarities to how the models and guidelines are prescribed. 1.3 Delimitations According to Dybå and Dingsøyr (2008) more information about Agile methodologies is needed, especially about Scrum. Since Scrum is the most applied of all Agile methods, more information is needed about it and because of the increasing interest in using Scrum within software development we have decided to only focus on Scrum. This thesis will concentrate on software development projects using Scrum and focus on the project development process and the usefulness within it. This thesis will only discuss project usefulness associated with Agile/Scrum methodology. Potential disadvantages with the Scrum methodology will not be evaluated during this study. Nevertheless, we are aware of them. 3

2 Models and guidelines This chapter initially focuses on traditional development project, continues with Agile methods, and finally compare the traditional approach with that of Agile methods. When addressing Agile methods, there will be a certain with a focus on Scrum. At the end of this chapter our research model will be presented. 2.1 Traditional project methodology Blomberg (2003) argues that the project in itself is no given object or fact, the social phenomenon that is a project does not exist in any social or historical space. The project exists within the modern organisation as an institute of how things work, or at least ought to work. The word project means different things for different organisations and in order to understand the definition of a project there is a need to understand the use of the word, project, and what a project really is. (Blomberg, 2003) Blomberg (2003) discusses projects and statements regarding projects, comparing discursive statements, the ought s: what the books and text are telling us a project is and base-relations, the are s: what our experience tells us of project understanding. Table 2.1: Ought's and Are's of projects. (Blomberg, 2003) Ought Are Comment The project ought to be a unique and well limited operation The project ought to have clear, firm and joint goals. Successful projects ought to be well planned Every project has a prehistory Project uses material and financial resources. Projects lead to long-term consequences. Goals change over time. Goals can never be joined. We do not know what we want. Successful projects are often unplanned Unsuccessful projects are often well planned. A project does not need to be limited of unique, when a project start depends on whom you ask and clear boundaries between the project and organisation is as evolving as the project itself. Pre-set goals doesn t explain the project or processes and goals seldom stay the same but evolve with the project, the same goes for competing goals. The influence of different members changes the goals of the project. Planning is not equal to success, planning can hinder the projects ability to adapt. 4

Successful projects ought to be within the time and cost frame. Project ought to be a superior organisation form. Successful projects seldom keep their budget Successful projects have more time claimed then planned. There are no objective criticisers for Successful projects. Making everything into projects will lead to a shortterm cost-hunt. Project management that is by the book hinders change and innovation propensity. As many project often has a deadline the time pressure is hard leading to the project being on time, but over budget and with more time spent on the project than planned. Project is not a superior organisation form, efficiency and profit will in the long-term fall. Just having a successful project is not equal to profit. The organisation needs to be able to understand and handle the result of the project. There need to be continuity between projects and between project and the on-going organisation. With table 2.1 Blomberg (2003) makes a comparison between how a traditional project ought to be and what it really is, it is clear that project in practice rarely are what they ought to be. Since this thesis aim to compare what the models and guidelines prescribes in the Agile methodology with the practical use of it this table is useful to us. What the models and guidelines prescribe is in our thesis what an Agile project should be, ought's, and the practical use of it is what it really is, are's. In order to have a successful project you need management to make sure that the project outcome is tied to the project process (Macheridis, 2009) and make sure to find an efficient solution to administrate and control tasks to the lowest usage of resources (Borum, 1980). There are a number of ways to look at project management, but a common thing to do during development is splitting up the project into phases. Starting with the definition phase where the problem is identified, broken down into as small parts and possible and analysed. Followed by a planning phase where the way to solve the problem is decided and the timeline of the solution is created (Macheridis, 2009). When all the planning is done it is time to actually solve the problem, this is done in the implementation phase, and when the problem is solved the project enter a reflection phase where the project team evaluate its own work (Macheridis, 2009). One of the better-known development methodologies is the Waterfall model, a model similar to a real waterfall. The model employs four steps for every phase each phase being separated by a waterfall to emphasize the transition to the next coming phase (Macheridis, 2009). But there is also the Spiral methodology where the projects move in a spiral, integrating the different phases with each other. In another method, Incremental methodology, every phase of the project needs to make the system create more functional (Macheridis, 2009). This linear way of thinking during projects has also been further developed when entering the implementation, or production, phase. Taylorism named after Fredrick Winslow Taylor (Avison 5

& Fitzgerald, 2007) was developed in where each job is broken down into its smallest components and rearrange in a way that transform the job into the most efficient way of doing the job (Avison & Fitzgerald, 2007). An example of this is the assembling of a car on a production line. Taylorism has inspired other methodologies such as the Just in time, where an integrated supply chain and a highly adaptive manufacturing plant allows for a build-to-order approach, in contrast to the build-to-stock with large inventory systems (Neill, 2003). This gives the producer a chance to manufacture things when needed and not just store the products in a storage house. Also making sure that the resources are used in an efficient way (Macheridis, 2009). All these methodologies are similar in their sequential linearity (in being sequential). They focuses on and analyses the problem and after that start to plan the solution to the problem. When the implementation later is done the teams involved in the implementation reflect on their own work. Then it starts again with a new problem to be solved. However, what should you do if something changes during the project? Start again from the beginning, ignore the change or be flexible in your project methodologies so the project can harness the change and grown with it? This is where the Agile development methodology's thrives, in development projects where change is a certainty and the need to adapt to these changes is crucial. 2.2 Agile Project methods The Agile Software Development Manifesto was created in February 2001 by seventeen experienced developers (Highsmith, 2001) who wanted to show that facilitating change is more effective than attempting to prevent it. Learning to trust in the projects ability to respond to unpredictable events is more important than trusting in the projects ability to plan for disaster (Highsmith & Fowler, 2001). The Agile Development Manifesto contained two sections, first is the Values that argued for the core focus of the Agile Development Manifesto and the second part described principles of how to work in an Agile way (Highsmith & Fowler, 2001). The name Agile means flexible, which is a suitable name for a method designed to change as the conditions change (Björkholm & Brattberg, 2010; Macheridis, 2009; Avison & Fitzgerald, 2006; Anderson, 2004 ). When applying an Agile method there are some advantages that appears. As the name indicates, the project process becomes more flexible, and in some cases more productive as well (Björkholm & Brattberg, 2010). The short iterative cycles used in Agile software development processes contributes to a more flexible and productive way of working in projects. The Agile methods are also aiming to create a closer customer relationship (Björkholm & Brattberg, 2010; Martin, 2003; Schwaber, 1995). When working within an Agile methodology a close customer relationship is required. The customer should be involved in the entire project process, since the customer is a big part and is seen as an asset in the project. So when applying an Agile methodology a closer customer because the customer ought to be involved during the 6

entire Agile software development process. The products that are developed are often more customized, the products are developed after the customer needs and changed with the needs as well (Björkholm & Brattberg, 2010; Martin, 2003; Schwaber, 1995). Since the customer is a part of the whole Agile project development process the customers are involved almost all the time and able to speak their mind if they like or dislike anything. In this way it becomes easier for the developing teams to make a product more customized, since they have a close relationship with the customer. Björkholm and Brattberg (2010) suggest that the teams are happier when working Agile, since it focuses on the creativity and collaboration within the team. Some authors even claim that the Agile software development is cheaper than traditional developing processes (Björkholm & Brattberg, 2010; Anderson, 2004; Neill, 2003). There are some situations where Agile methods are not appropriate. Everybody within the developing team and the customers must be willing to use these methods, because Agile methods demands a close relationship between the customer and the developing team (Björkholm & Brattberg, 2010). This method can be seen as demanding since there is much pressure on the parties working so close together. The parties involved in an project development process must be aware of that these types of methods requires much and close collaboration (Björkholm & Brattberg, 2010). So, it might be hard to success with an Agile method if the team or the customer are unfamiliar with this way of working. (Björkholm & Brattberg, 2010). Since the system development process is complex, and with the market constantly changing the need for a flexible method is crucial (Schwaber, 1995). Agile methods are according to Macheridis (2009) able to adapt to different market changes and to take advantage of all changes, turn them in to something positive. In Agile methodology the changes are not seen as threats and obstacles, which implies that Agile project methodologies are flexible. Software development projects needs to be organized, managed and executed in a way that allow them to sense and respond to unpredictable events in their environment (Aaen et al., 2007). This also implies that Agile methods are flexible, they are able to sense and respond to the changing environment. In order to see the change and work with it project managers need to, not just say that people are the most important asset to a project but also mean it and use the people to develop software (Highsmith, 2001). The use should be based on the principal of using minimal set of activities and artefacts to achieve the end goal, being a rapid and flexible way of developing software (Alleman, 2002). In addition, when you put people and their interaction in focus you must make sure that the face-to-face communications, between the clients, developer and project team leader is optimal (Morien & Wongthongtham, 2008). To be able to practice the different features of Agile project the project management need to interpret the different values and principles (Macheridis, 2009). Alleman (2002) has interpreted these values and principles into a more practical use; these will be shown and compared to the Agile Manifesto values and principals. 7

2.2.1 Values Agile methods guide the processes in a way in which the project is built while going forward in the process (Alleman, 2002). Alleman (2002) explains how Agile methodology can be interpreted with five different underlying values: Communication the communication within and outside the project needs to be constant. This is important and contributes to the social aspects for the project participants. Simplicity The simplicity aims to the approach of the project of addressing critical success factors. Feedback In order to know if the project is going the right direction feedback is required. Courage The decisions and changes needs to be done with courage when handling the projects direction and steering, to have courage when deciding to engage or not in an activities or artefacts. Humility The manager need to engage the stakeholder/project owner to get the information they got, because the manager does not know everything. Taking advantage of having an engaged stakeholder/project owner increases the possibility to close the gaps between both parts. The Agile manifesto is interpreted to have four main values that outline the main idea of the Agile project management that focus on a better way to develop software and help others do it as well (Björkholm & Brattberg 2010, Avison & Fitzgerald 2006, Martin 2003, Neill 2003, Highsmith & Fowler 2001, Schwaber 1995): Individuals and interaction over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan. Individuals and interaction over processes and tools. People and the ability to interact with other project members are important. You can be a highly skilled programmer or any other member in the team, but if you cannot communicate with others and work as a team the project runs a high risk of being late or not even finishing. It is important to start bulding the project team because just creating an environment for the team members to work in does not automatically build the team (Martin, 2003). Of course, you should not forget the processes and tools but the important thing is to ask yourself what more assets you have in the project (Highsmith & Fowler, 2001). Programmers, testers, project managers, modellers and customers develop the software, and they need to be able to interact and work together effectively, tools and processes are still needed but remember a fool with a tool is still a fool (Ambler, 2006). 8

Working software over comprehensive documentation. Software should be documented, if not it can lead to misunderstanding of the software or render the software unusable. But documentation is not connected with success either, the documentation must be written in a way that can be understood and updated with the latest version of the software, otherwise the documentation will hinder you software more than help it. When working with documentation in the project team it is important to remember the first point of the Agile manifesto, interaction. Interacting with team members and not just referring them to the documentation will make the project flow better. (Martin, 2003) Documentation is an important part of development but not more important than working software (Highsmith & Fowler, 2001). Documentation has its place, to guide the understanding of how and why a system is build and how to work with it, but without working software there is no need to explain the system (Ambler, 2006). Customer collaboration over contract negotiation. A contract provides the boundary for the parties to work, but a contract can never clearly state what the customer wants (Highsmith & Fowler, 2001). Involving the customer in the project and not just let the customer be the name on the list that tells the team members what to do (Martin, 2003). Successful projects involve customer feedback on a regular and frequent basis, rather than having a contract that states what is needed the customer can work closely with the project and their development team and give them feedback on their work. A contract is of course needed, but when doing it both customer and provider should keep the collaboration in mind and make sure that the contract allows change and collaboration. (Martin, 2003) Responding to change over following a plan. Planning is good, but it can make you blind for change (Highsmith & Fowler, 2001). Being able to respond to change and development within or outside the project is essential for a software development project, and often determine the risk of failure for the project (Martin, 2003). There is always a need for a plan, but plans need to be flexible and ready to adapt to changes and instead of planning the entire project in detail, maybe plan the next two weeks and what the project should be working with during that time. By doing this you only invest time in planning things that are sure to be developed, because with the ongoing change within software development project it is hard to know what actually needs to be developed in 3 months. (Martin, 2003) These values are something that almost everyone instantly will agree with but rarely follows in practice (Ambler, 2006). This is something we want to look more closely into: how is the process used in practice and how useful is Agile project methodology in practical software development projects. From the values we have created ought statements and looked at which of the statements the authors agree with (Table 2.2). Every is included in at least one statement, every statement that has four or more author s agreement will be used for the research model to later be compared to the empirical data, the use in practice. 9

Table 2.2: The Ought's from Agile values Ought s, from values Björkholm & Brattberg (2010) Avison & Fitzgerald (2006) Martin (2003) Alleman (2002) Highsmith & Fowler (2001) Schwaber (1995) Working software ought to be prioritized over comprehensive documentation in an Agile software development project. Customer collaboration and feedback from them ought to have high priority in an Agile software development project. Seeing change and responding to it ought to have high priority in an Agile software development project. Communication and interaction between the teams and within the teams ought to have high priority in an Agile software development project. An Agile software development project ought to be working in the simplest way possible. X X X X X X X X X X X X X X X X X X X X X X X 2.2.2 Principles From the five values Alleman (2002) created principles to use when working and using Agile processes, these principles where specifically used for ERP development and management and Alleman (2002) argues that the principles are Assume Simplicity, as the project evolves the simplest solution is often the simplest one. Embrace Change, evolving with the requirements will make the solution better. Enabling the next effort, the solution needs to survive the change that might come after the development is finished. Incremental change, instead of doing everything at once, do small parts fast (Alleman, 2002). Maximize stakeholder value; best way of meeting the stake holder's need is to involve them in the project. Manage with a purpose; identify the purpose of the stakeholders need. Multiple project views, present the project in different formats so everyone understands. Rapid Feedback, The time between action and feedback and feedback to action must be as little as possible (Alleman, 2002). Working software is the primary goal, an activity that does not contribute to the goal should be examined to determine its value. Travel light, the needed effort to maintain the solution must be balanced with their value (Alleman, 2002). The Agile Development Manifesto has created twelve principles extracted from the four values (Avison & Fitzgerald, 2007; Martin, 2003; Highsmith & Fowler, 2001; Schwaber, 1995). The first principle is (1) Our highest priority is to satisfy the customer through early and continuous 10

delivery of valuable software. Customers do not care about Unified Modelling Language (UML) models or documentation, they care about working software (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). A project should (2) Welcome changing requirement, even late in development. Agile processes harness change for the customer competitive advantage. Change is an everyday thing, it is something that will happen and rather than resisting change it should be welcomed and its effect should be calculated (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). And even though there might be a constant change the project need to (3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the short time scal. Iterative planning has been used before, but by making the process cycle as small as possible customers can see results and give feedback more often (Highsmith & Fowler, 2001). (4) Business people and developers must work together daily throughout the project, allowing developers and business people to take part in each other s work will make the development better and give the customer more value from its system. Instead of completing a final requirement list during day one of the project, compile a list of the customers requirements. Howerver, give the developers the option to add and change that list while interacting with the customer (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). When the project and development has started it is important to (5) Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done. Trust is the key, and the managers most trust his or her developers and the developers must trust that the manager s decision is based on just causes. (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). (6) The most efficient and effective method of conveying information to and within a development team is face to face conversation, you can create as much documentation as you want, but with face to face conversation you present knowledge to the other. (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). (7) Working software is the primary measure of progress. Creating value for the customer is the focus, and the customer wants to see working software not diagrams or documentation of software that is planned (Highsmith & Fowler, 2001). (8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Hard crunching to reach the deadline is not the way to go, having 40 hour week with a good working pace and a constant work flow while everyone is healthy is the way to go (Highsmith & Fowler, 2001). (9) Continuous attention to technical excellence and good design enhance agility. As with the requirement list design is not something that you do, and then leave it to start developing, design is continuously done during the software development (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). (10) Simplicity-the art of maximizing the amount of work not doneis essential, any task can be done in a number of ways, the most important thing is that it s done in the simplest way (Highsmith & Fowler, 2001). (11) The best architectures, requirements and designs emerge from self-organizing teams, the best architectures, requirements and design does not come from early planning but from iterative planning and use (Highsmith & Fowler, 2001). (12) At regular intervals, the team reflects on how to become more effective, then tunes and 11

adjust its behaviour accordingly. Constantly improving, reflection and refining is important in Agile software development, trust in people not just to do their jobs, but to improve them self when needed (Björkholm & Brattberg, 2010; Highsmith & Fowler, 2001). From the principles we have created ought statements and looked at which of the statements the authors agree with (Table 2.3). All principles are represented in a statement and every statement that has four or more author s agreement will be used for the research model to later be compared to the empirical data, the use in practice. 12

Table 2.3: The Ought's from Agile principles Ought s, from principles Björkholm & Brattberg (2010) Avison & Fitzgerald (2006) Martin (2003) Alleman (2002) Highsmith & Fowler (2001) Schwaber (1995) The highest priority ought to be satisfying the customer through early and continuous delivery of valuable software. Changing requirement ought to be welcomed, even late in development the change ought to be harnessed for the customer competitive advantage. Working software ought to be delivered frequently with a preference for the short time scale. Business people and developers ought to work together daily throughout the project. Projects ought to be built around motivated individuals, give them the environment and support they need, and trust them to get the job done. Face-to-face conversation ought to be the preferred way of communicating. Working software ought to be the primary measure of progress. The sponsors, developers, and users ought to be able to maintain a constant working pace indefinitely. Technical excellence and good design to enhance agility ought to be continuous attended. Simplicity ought to be favoured, the art of maximizing the amount of work not done, is essential Self-organizing teams ought to give the best architectures, requirements and designs. At regular intervals, the team is ought to reflects on how to become more effective, what was good and bad and respond to this. The needed effort to maintain the solution ought to be balanced with its value. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Is the Agile methodology the best way to go? This is hard to answer for anyone except those involved in the project. The methodology most fit the task and not be force to work in the all project (Lindvall et al., 2002; Neill, 2003). 13

Lindvall et al. (2002) also summarized their findings of lessons and experienced from Agile management describing things that can be different or just worth noticing. Lindvall et al. (2002) argue that any team could be Agile, regardless of size in contrast to Neill (2003) who suggest that in order for the interaction to work the team should be as small as possible. The participant of Lindvall et al. (2002) workshop argues that experience of Agile project is important, but experience of system development is more important and that reliable and safety-critical projects can be conducted with Agile methods, the testing need to be planned and requirements need to be available early (Lindvall et al., 2002). Neill (2003) also discuss about the need for great people in the project and Lindvall et al. (2002) support the claim of that the people, communication between the people and the culture within the project is the three most important success factors. 2.3 Scrum Scrum is the most widely adopted Agile system development method (Hossain, et al., 2009), the pattern for this method was developed by Jeff Sutherland when he tried to come up with a pattern for how productive team really works (Björkholm & Brattberg, 2010). The name Scrum is a metaphor from the sport rugby (Schwaber, 1995), and was first written about in an article by Hirotaka Tekeuchi and Ikujiro Nonaka year 1986 where modern development was described as rugby instead of relay race as the waterfall model is compared with (Björkholm & Brattberg, 2010). The Scrum methodology consists of three different phases: Pregame, Game and Postgame, within these phases there are some other subphases: Planning, Architecture, Development and Closure (Abrahamsson et al., 2002). In every subphase there are different tasks or steps that needs to be done. Figure 2.1: Scrum phases To understand how the Scrum process works it is important to know what happens in the different phases. There are also a few terms that are central in order to understand Scrum such as roles, sprints, product backlog, sprint backlog, definition of done and daily Scrum. In this chapter we will discuss the three phases and the different terms, some of the terms will be explained in the text about the phases. 14

2.3.1 Roles There are the stakeholders, such as: users, developers, customers and business management (Björkholm & Brattberg, 2010). The stakeholders are what Schwaber (1995) calls the external party. These are ones that will be affected by the project and the release of the new developed systems and the internal party are the ones developing the product for the external party. The people in the external party are all the people that are involved in the project because they have expectations on the result and some are also going to use the finished product. There is also a role in these types of project called the product owner; the product owner is usually the customer. This person s responsibility is to make sure that the developing team know what to do, this person does not decide how to do it, because that is the developing teams own work. The developing team gets a what-to-do-list, a prioritised backlog list, from the product owner and then they do the time estimation and decide how it will be done (Björkholm & Brattberg, 2010). The team consists of developers and in every team there is a Scrum-master, this is the internal party. They are seen as one role, all developers together, they are not seen as individuals. The Scrum-master is a part of the developing team, but he/she has an own role (Björkholm & Brattberg, 2010). It is the Scrum-masters responsibility to make sure that the developing team can work effective, structure and solves the small problems for the team. Schwaber (2004) claims that the Scrum-masters authority is mostly indirect, making sure that the decided process is followed, and that the team is following Scrum as it is in models and guidelines This part will not be discussed or analysed further, it only exist in order to give understanding about the roles in a Scrum process. 2.3.2 Daily Scrum When working with Scrum the team also has daily Scrum meetings, this is a meeting of fifteen minutes where each team member addresses some questions. These are the three basic questions that team members answer during these daily Scrum meetings (Björkholm & Brattberg, 2010; Hossain, et al., 2009; Beedle, et al., 1999): What did I do yesterday? What will I do today? What impediments are in my way? In order to keep the meetings short they are held standing in front of a Scrum-task-board were all tasks are visible, which tasks needs to be done, which ones are in progress and which ones are done (Björkholm & Brattberg, 2010). As the name indicates these meetings are held every day, so that the project members can give the other members information about how the project is going, for example issues found, what to do next and items completed. Beedle, et al., (1999) calls this knowledge socialization, this has a deep cultural transcendence, and promotes to a selforganized team structure where the development process is evolved on a daily basis. Everybody who wants can come to these meeting, but it is important to keep the focus on obstacles, and they are held in order to help the team coordinate (Björkholm & Brattberg, 2010). 15

2.3.3 Scrum process Figure 2.2 is Schwaber (1995) picture of what Scrum methodology looks like. All the phases: Pregame, Game and Postgame are represented in this model. Pregame Planning & System Architecture, Game Sprints and Postgame Closure. This models shows that both Planning & System Architecture and Closure are linear, these two parts are comparable to the waterfall process (Schwaber, 1995). The sprints however are not linear, they are iterative, all steps in this phase goes on and on until they are seen as done and the project can move to the last phase: Closure. Figure 2.2: Scrum methodology, (Schwaber, 1995, pp.10) 16

Abrahamsson, et al. (2002) have made their own interpretation of the Scrum process, figure 2.3. This model is based on Figure 2.2, the pregame and postgame phases are both linear and in the game phase it is the sprint that is iterative. This model is much more detailed and shows the project process in a more detailed way. Since it is more detailed, newer and originates from Schwaber (1995) s model we are going to use this model in our research model. Each phase will be explained more detailed in the coming subchapters. Pregame Game Postgame Figure 2.3: Scrum process, (Abrahamnsson, et al., 2002, pp. 28) 2.3.3.1 Pregame Schwaber (1995) explains that in the pregame phase there is the subphase called planning, and it includes for example planning the definition of a new release, delivery dates and functionality based on known product backlog, development of a comprehensive product backlog list and assessment of risk and appropriate risk controls. You could say that this phase includes everything from planning the schedule and costs for the project to get the approval and funding from the management (Schwaber, 1995). What is important to remember is that there must be a definition of done (DoD), and it is defined in this phase. The DoD tells how much needs to be done on a product, a task or in a sprint in order to declare it as finished (Björkholm & Brattberg, 2010). Is the task done when the programmer is done with coding, or is it done when the coding and testing is done or is it done when the coding, testing and documentation is written? This is something that the team needs to figure out and decide on in the beginning of a project, in this pregame phase. 17

In this phase a product backlog is developed, and this backlog will give the structure for the sprint backlog developed in the game phase. These types of backlogs contain the customer requirements and information about the cumulative work remaining in the shape of for example daily burn down charts showing all information needed, some sorts of to-do-lists. It is not just the customers requirements in these backlogs, requirements from all the stakeholders and the developing team are also in the product backlog (Abrahamsson et al., 2002). Only the highest prioritised requirements are placed in the product backlog, and the product owner does the prioritising. The product owner gets information from different stakeholders; people interested in this specific project, and are then able to do the prioritizing (Björkholm & Brattberg, 2010). However, it is the developing team with a Scrum-master in the front that are going to do the time and cost estimation, as written when the different roles were explained. The product backlog consists of a list with requirements as they see in the beginning of the project, and therefore some changes and updates are expected. If any changes needs to be made they are changed during the project, when having the daily Scrum-meeting and in the retrospective meetings, and not after the project is done (Abrahamsson et al., 2002). The product backlog includes everything needed for the whole project, all the tasks that needs to be done, and sprint backlog just holds requirements/tasks for every sprint. The planning phase will look a bit different depending on if the project is to develop a new system or to work with an already existing system. If the system is new, then the phase also will include conceptualization and analysis, and if it is work with an already existing system the planning only consists of limited analysis (Schwaber, 1995). When working in the game phase all work is done iteratively, and this means doing something repeatedly until it is considered done. However, it is in the Pregame phase, subphase planning, that the iterative planning is made. Iterative planning is split up into four steps, (1) initial exploring, (2) spiking, splitting and calculating velocity, (3) release planning and (4) the halfway point (Martin, 2003). The halfway point is not the last thing that happens, it is continuously updated during the project development process. Martin (2003) describes the four steps as following: 1. Initial Exploration. When the project start the developers and customer try to identify all the really significant user stories they can and as the project process continues new users stories will be added and this flow and collaboration don t stop until the project is over. The stories are divided into a number of points and the points are showed on a story card that represents that cost of the story. The points focus on telling time it would take to develop the user story, with eight points being double the time of four points. 18

2. Spiking, Splitting and Velocity. Having too small or too big stories is not good as these are particular hard to estimate, splitting bigger stories and merged small stories will make the estimation better. But when doing this it is important to re-estimate the point value of the merged or splitter story, not just subtract or add. But just having points is not enough to calculate how long time something will take, the velocity of the project is needed, how many points per day does the project manage to develop. And from that estimations can be done of how long it will take to develop a story. 3. Release Planning. With the velocity, number of points and cost of each point the customer can get a feel of the cost of a story. They can also look at the business value of each story and prioritise them. This gives the project a total numbers of stories and with story to start with, and when this is done the project starts to do an iteration plan. The iteration plan usually is two weeks long and the prioritised stories are fit into the plan, as long as they fit the velocity on the development team. When the project might prioritise doing this some stories as it makes more sense to do one practically story before another. The iteration ends when the two weeks have passed, even if all planned points aren t done, and the stories are sent to the customer for feedback and possible changes that the project needs to take into account. For the next iteration plan the project takes into account how many points was done during the last iteration and plan from that. Until finally all stories are done and project is finished. 4. The halfway point. Halfway into the iteration the project team holds a meeting; at this point half of the planned stories should be done. If half the stories aren t done this need to be looked at and reported to the customer to make sure that they know so the customer has the option to pull stories back or re-prioritize. By using short iterative planning and planning life cycle from 2 weeks to 1 month the project will be ready for the change that might come up and with Agile development methods and iterative planning warning signs can be spotted early in Agile projects (Lindvall et al., 2002) and be harnessed into the project. Besides planning this phase also consists of doing the architecture of the project, design how the backlog items will be implemented, system architecture modification and high-level design (Abrahamsson et al., 2002; Schwaber, 1995). The architecture is made based on how the product backlog looks like. The authors also write that in this phase the team will also try identify any problems or issues in developing or implementing the changes/the new system and also to identifying the necessary changes that needs to be done with the backlog items. The name of this subphase is the architecture or high level design as the authors also calls it. Much of what happens in these two phases is connected to identifying what the rest of the work with the project will look like and try to figure out everything in advance. 19

2.3.3.2 Game After the pregame the game phase begins with its only subphase: Development sprints (Schwaber, 1995). This phase is an iterative cycle of development work and in this phase the group needs to have a few considerations in mind, variables of time, requirements, quality, cost and competition. It is the interaction with and between all these variables that defines the end of this phase. What has been planned in the previous phase is going to be realized in this phase for example reviewing the release plans (Schwaber, 1995). Since it is hard to know everything in advance this phase is treated as a black-box, and the team is always ready for something unexpected to happen (Abrahamsson, et al., 2002). In software development there are different stages: Requirements, Analysis, Design and Delivery, in the developing sprint. Within traditional software development these stages are used as a comfortable way of tracking milestones. These stages also exist in Scrum-projects, but all stages are mapped to a sprint or a series of sprints within Scrum. Beedle et al., (1999 gives an example of what this look like: So, for example, the Requirements stage may use one Sprint, including the delivery of a prototype. The Analysis and Design stages may take one Sprint each. While the Evolution stage may take anywhere from 3 to 5 Sprints. (Beedle et al., 1999, pp.638) In this phase the project-process is broken down into different short time intervals called sprints (Björkholm & Brattberg, 2010; Beedle, et al., 1999; Schwaber, 1995). The whole project often consists of three to five sprints and each sprint usually last a month but can also last a week. In every sprint there are one or more teams working with some specific assignments concerning: development, wraps, review and adjust, how long a sprint lasts depends on the complexity of the work in each sprint (Schwaber, 1995). Using sprints is the Scrum-way to do time estimation, estimate how much time one assignment needs/takes (Björkholm & Brattberg, 2010). Every sprint begins with planning and ends with a review (Hossain, et al., 2009) and a retrospective meeting (Björkholm & Brattberg, 2010). When planning a sprint the team members have a meeting, the meeting is dedicated to plan the whole sprint and also go in to details about how and what the process is going to look like. How many meeting that needs to be held and how often are decides within the architecture phase (Schwaber, 1995). A sprint planning meeting is often a time-boxed meeting, can last up to four hours (Hossain, et al., 2009). When a meeting is time-boxed it means that the meeting are supposed to be x number of hours NOT more, even if everything has not been said during the meeting it will still not continue. When the sprint comes to an end there will be a review meeting, showing of a demonstration, and as the name of the meeting indicates the project group will evaluate the state of the business by showing of a demo for the stakeholders of the project (Hossain, et al., 2009; Schwaber, 1995). At this meeting it is important that the stakeholders give feedback on the demo: what they like, what they do not like and if they have any other requirements. According to the Scrum methodology it is good with changes, because this will help the customer get exactly what he/she wants, it will be more 20

customized in that way (Björkholm & Brattberg, 2010). After showing of a demo a retrospective meeting will be held for the developing team. On a retrospective meeting all backlogs are evaluated, new backlogs items might be introduced and the way some backlog items were implemented might change depending on the review (Schwaber, 1995). There are no predefined rules or guidelines for what the process within the different sprint should look like, that is why Scrum uses meetings in order to complete the allocated activities (Beedle, et al., 1999). And all sprints will be iterated until they are satisfied fulfilled, and that is when the product is seen as finished and ready for distribution (Schwaber, 1995). 2.3.3.3 Postgame In the postgame phase it is time to give the project a closure by making preparation for the release, and this includes final documentation, pre-release stage testing and finally release of the software/system (Schwaber, 1995). This is the closure phase, when the variables mentioned in the subphase Development sprint and DoD are fulfilled the project is declared as closed by the management and the project has entered the phase of closure (Abrahamsson, et al., 2002; Schwaber, 1995). A few things still needs to be done, such as integration, system test, user documentation, training material preparation, and marketing material preparation (Schwaber, 1995). 2.3.4 Usefulness with Scrum Martin (2003) and Schwaber (1995) claim that Agile methods are aiming to create a better customer relationship, this also include Scrum, because each team in a Scrum project consists of some full time developers and an external parties. These parties are included in the development process, as opposed to traditional projects, since they are seen as assets. Making them a part of the project increases the probability that the release content and timing will be appropriate, useful and marketable (Schwaber, 1995). Schwaber (1995) describes some other advantages with the Scrum methodology, for example, Scrum helps the developers to be more creative when coming up with a solution. They are themselves in charge over the task they have been given or the task the have taken, so they can do the task how they wish to do it as long as the task gets done. Since they can be creative and because Scrum teams are supposed to be small, few developers involved, this is an excellent learning environment (Schwaber, 1995). The developers are able to share tacit knowledge with each other, they have the opportunity to ask and learn more about what the other ones in the team are doing and also learn from their problems since they talk about this on a daily basis. Scrum also gives the opportunities to learn how to make a better project during the project, since they have both daily meetings and retrospective meetings in every sprint during the whole project. The next subchapter will look at the Agile development methodology, and compare it to the more traditional way of working in projects. 21

2.4 The difference between traditional project and Agile projects So should you use the more traditional methods when managing your development project or Agile? This straightforward question does not have an easy answer. Agile methodology is not better or worse than more traditional it is just a way of working in a project under some circumstances (Dybå & Dingsøyr, 2008). Forcing Agile development methodologies into a project where circumstances aren t fit for Agile methodology can give you more problems than solutions in the same way that traditional methodologies are not appropriate for projects with high risk of change. The need to look at the problem at hand, the surroundings, the team and the customer and go from there to find out what fits your project the best, and in order to do this you need to understand what sets Agile development methodology apart from traditional approaches. Morien and Wongthongtham (2008) summarized the differences of Agile development methodologies with the traditional approach of Waterfall, this will be presented in the table below (table 2.4). Guiding words, Focus and Project structure is was will be focused on when comparing traditional project and Agile projects. Table 2.4: Comparison between Waterfall and Agile, (Morien & Wongthongtham, 2008, pp.230) Guiding words Focus Project structure Waterfall Waterfall is guided by a manufactured and engineered workflow. Waterfall put focus on following the plan and making sure there is documentation. Everything is planned, cause that might happen and effect they might have, and planning to prevent interruption. Agile Agile is guided by an organic workflow with sudden changes. Agile put focus on the people in the team and their ability to create working code. The workflow is not planned and by doing so you gain a more adaptive approach to change. One of the key features of Agile methodology is to embrace the change that might occur during the project life cycle because change is a part of the project, while a more traditional approach will lead to cost of change growing with every day that passes (Neill, 2003). This is why you use iterative planning when using Agile methodologies, this is one of the ways that you can plan your Agile projects, but iterative planning is one of the more commonly used (Martin, 2003). By using short iterative planning and planning life cycle from 2 weeks to 1 month the project will be ready for the change that might come up and with Agile development methods and iterative planning warning signs can be spotted early in Agile projects (Lindvall et al., 2002) and be harnessed into the project. If everything is planned from the start and the project 22

is forced to get a product that is expected. The change that appears might have made the final product even better if change is incorporated, and with Agile methods change can be incorporate. When using Agile methodology the company have the people in the team as their source of working capacity. What they can produce in a week is what the company can produce, so keeping the team motivated is a key priority in the Agile development methodology (Neill, 2003). Traditional management will continue to say that employees are their most valuable assets, but still use them as replaceable tools. With Agile management the development team will be used not as a resource but as individuals that will work better in a motivated environment (Ambler, 2006). Dybå & Dingsøyr (2008) believe that Agile methods will be consolidated in the future, just as object-oriented methods were consolidated. Agile and traditional methods will have a symbiotic relationship, in which factors such as the number of people working on a project, application domain, criticality, and innovativeness will determine which process to select. However, the key is to value your options and know when to use which methodology (Lindvall et al., 2002; Neill, 2003). If the Agile Methodology is selected, working with people and make the project dependent of the people in the project is selected, without great people working in harmony the resulting system can be affected (Neill, 2003). When using Agile Methodology it is also important to trust the project members, not only for them do their job but also to improve upon it (Highsmith & Fowler, 2001) thereby letting go of some of the control. This is why the Agile methodology is scaring some more traditional managers, who just want to manage the project one process at the time according to the plan. What is best for the customer is delivering something on time as planned according to the more traditional managers. Not delivering in time and delivering the best thing for the customer and make sure that they have the control to finish the project (Highsmith, 2001). A problem is that some people in the team is not experience in a particular way of coding or are just starting up in the business, but with the help of pair programming, one of the tools used in Agile methodology where developers work together to solve a problem, a team member require less formal training (Lindvall et al., 2002). The team members needs to feel motivated and as a part of the project, this is something that can automatically come as an effect when using Agile methods as the development. If forced to interact with the planning team and the customer, this feeling can be hard to create in a traditional project where the developers just get a list of demands and have to develop them, they are not a part of the planning process, and they are just told what to do. By using Agile methods warning signs can be spotted early in Agile projects as you plan as it happens and have small life cycles on the planning, this gives you a small cost of change (Neill, 2003) as change can be implemented into the project fast and things that might have stalled the project completely just becomes a small delay. Abrahamsson et al. (2002) argue that traditional software development methodologies are not used in practice as they are to mechanistic to use in detail, what has lead to a sceptical view from the developers part to use new methods that can be hard to grasp and therefore remain. This has led to that for 20 years software development have been trying to manage their projects with 23

technical-rational approach using sequential life cycle, rigorous planning, upfront design and a constant drive to monitor and make sure that the plan is followed (Beznosov & Kruchten, 2004) and making sure that they are in control. This has served some projects well, to have a wellplanned design and architecture before the project even starts, but with a success rate of less than 50% there is a need to be able to manage the project so it can evolve as change comes (Beznosov & Kruchten, 2004). One part of the control that is used in more traditional approaches is the documentation, the Agile methodology embrace modelling and documentation, but not creating something that will just collect dust or be several hundreds of pages of never used text (Highsmith, 2001). When doing models and documentation there has to be a purpose to them, to make the customer better understand the architecture or hand over to the team that is now supposed to manage the developed system. However, forcing developers to do documentation that will go unused is not needed, good code and making sure that there are oral hand offs is enough documentation, if documentation is not required by the customer of course (Neill, 2003). 2.5 Research model In order to answer our first sub question: What does the process, when applying Agile project methodology, look like? we are going to do a similar comparison to the one Blomberg (2003) did with traditional projects between ought s and are s. We believe it is a good way of comparing how it should be, models and guidelines, with how it is, practice. The ought s that we are going to use in this framework comes from values and principles belonging to Agile methods. In our two tables (Table 2.5 and table 2.6) with values and principles we have only taken the ones that four or more authors have advocate. The ones we have removed do not have enough support in the literature according to us. The are s that we are going to use are similar values and principles coming from the empirical data. The are s column will be filled in after the empirical findings have been presented. With this part of our research model will are able to make a comparison between models and guidelines found in literature and practice. 24

Table 2.5: Values in our research model Ought s, from values Are s Comments Working software ought to be prioritized over comprehensive documentation in an Agile software development project. Customer collaboration and feedback from them ought to be high priority in an Agile software development project. Seeing change and responding to it ought to be high priority in an Agile software development project. Communication and interaction between the teams and within the teams ought to be high priority in an Agile software development project. 25

Table 2.6: Principles in our research model Ought s, from principles Are s Comments The highest priority ought to be satisfying the customer through early and continuous delivery of valuable software. Changing requirement ought to be welcomed, even late in development the change ought is to be harnessed for the customer competitive advantage. Working software ought to be delivered frequently with a preference to the short time scale. Business people and developers ought to work together daily throughout the project. Projects ought to be built around motivated individuals, give them the environment and support they need, and trust them to get the job done. Face-to-face conversation ought to be the preferred way of communicating. Working software ought to be the primary measure of progress. Technical excellence and good design to enhance agility ought to be continuous attended. Simplicity ought to be favoured, the art of maximizing the amount of work not done, is essential At regular intervals, the team is ought to reflect on how to become more effective, what was good and bad and respond to this. 26

We also need to look at the process, how our informants work with Agile/Scrum. With Abrahamsson et al. (2002) s model, figure 2.4, it is promote to compare the practice of working with Scrum to the models and guidelines prescribed about how to work with Scrum. This is also a way of comparing ought s, the model of Abrahamsson et al. (2002) and are s, what the practical use of Scrum looks like. Pregame Game Postgame Figure 2.4: Research model for Scrum process, (Abrahamnsson, et al., 2002, pp. 28) 27

To answer our second sub question: What are the important features in an Agile project, and what are the project usefulness that can be identified when applying Agile project methodology? we have summarised all project usefulness found in models and guidelines. Some of them are only for Agile or Scrum and some are for both. Since Scrum is an Agile method we believe Scrum inherits all project usefulness Agile has and vice versa. These values will be compared and evaluated together with the project usefulness found in the empirical data. With help from table 2.5, 2.6 and figure 2.4 we will also identify the important features in the Agile/Scrum project process. We are then going to try to connect the features to the found project usefulness, in order to find which important features are in order to achieve project usefulness. Table 2.7: Usefulness with Agile/Scrum in our research model Usefulness with Agile and Scrum Björkholm & Brattberg (2010) Macheridis (2009) Aaen et al. (2007) Avison & Fitzgerald (2006) Anderson (2004) Martin (2003) Neill (2003) Alleman (2002) Highsmith & Fowler (2001) Schwaber (1995) More flexibility X X X X X X X X Closer customer relationship X X X X X X More customized X X X Cheaper X X X Learning environment X More creativity X X More productivity X 28

3 Method This chapter will outline the approach of this thesis. Based on the research model an interview guide has been formulated. The purpose of this study, with help from the empirical findings, is to determine if the models and guidelines are consistent with the informants' views and try to draw parallels between each other. 3.1 Selecting a method In order to compare models and guidelines with practice we needed to find out how Scrum is used in practice, so we decided to make five different interviews within three different companies. We wanted to do comparative studies, various persons talking about the same subject, to see the whole picture of how Scrum really is used. How two people using Scrum in the same project sees the process and if their process is comparative to the other informants processes. Jacobsen (2002) calls this type of method små-n-studier, which is a comparative study. In a comparative study a small numbers of units are chosen, often not more than five or ten. The reason for using this type of method is that it gives us the possibility to go deeper when searching for information within every unit and it is also appropriate when the researcher wants to elucidate more than just one side of a subject (Jacobsen, 2002). We believe that the comparative studies are appropriate to use to see how the method Scrum actually is used in practice. We have selected interviews as the main data collection method. Denscombe (2009) claims that having interviews as a research method is suitable when a researcher wants to gain insight into a person's experiences, views and opinions. When the researcher wants to get information from the single person s perspective, interviewing is a good way to collect data and it is interesting to get data about how the different people see the same subject (Jacobsen, 2002). We were interested in how the single person sees and experiences Scrum and the work with this project method. The reason for us doing interviews is because when doing interviews it might be easier for both parties, in the way that there is not pre-defined answers and the questions can be explained if the informant does not understand them. For us as interviewers it is easier to express what we are asking about and to explain our questions, and for the interviewee it is easier for him/her since he/she would not feel constrained by a range of pre-set answers and he/she can also talk freely about the subject. Using this method also contributes to a more valid answer because there will never be a problem for the informant with not having an answer to choose that feels right or suits his/her opinion (Jacobsen, 2002). Interviews are also more targeted focus specifically on the 29

research question (Creswell, 2007). We also decide to make our interviews semi-structured, we had a number of questions that we wanted to ask the informants, and they were divided into different themes, as Bryman (2002) suggest. We divided our interview guide into four different themes: Introduction, Agile, Scrum and Closure. The reason for making the interviews semistructured was in order to make it possible for us to ask follow-up questions and not be tied up with the questions within the interview guide. It also helped the informant to be able to talk freely and he/she was not bound to answer all questions in a specific order and not be able to talk about something that was not in the interview guide (Kvale & Brinkmann, 2009). We believe that semistructured interviews also helped with the informant feel more comfortable in this special situation, since all questions asked came naturally. The following-up questions were all based on what the informant were saying during the interview, so there are some differences between what was asked in each interview. Our interviews were made face-to-face and they were all individual, no group interviews. We decided to do face-to-face interviews because it felt like the right method to use in our case. We believe it is easier to talk to someone that you can see, someone that you can have eye contact with and see how the persons react on the questions. We could have used Skype or another net meeting program where you have the opportunity to actually see the person you are talking to. However this requires that both parties, us as interviewers and the informant, have the necessary skill, knowledge of using a computer and a chat program in this case. So using these types of communication media was seen as a secondary solution for us, if we could not meet our informants face-to-face. If discussing Scrum, how the management/leaders of the Scrum team acted, is seen as a sensitive subject it is also better to use face-to-face interviews. According to Jacobsen (2002) it is better to have interviews about sensitive subject face-to-face, it makes it easier for the informant to talk about it, in comparison to telephone or internet based media. Another advantage with face-to-face interviews, in comparison to mail conversations for example, is that you get the answer directly; there is no need to wait for the informant to replay by e-mail (Kvale & Brinkmann, 2009). In order to give us an as accurate picture of how Scrum is used we felt it necessary to not only do one interview on every company/project, that is why we chose to conduct two interviews with two different people within the same company/project. As stated above we did interviews with five different people, these five persons were representing three different companies, two persons on Company A and two on Company C, and one on Company B. We wanted to investigate how people within the same projects perceive the project process, if they have the same experience of what was done, how it was conducted and what was important or critical. The reason for making the interviews individual was because we did not want the informants to be influenced of each other (Jacobsen, 2002). When doing a group interview the informants might get ideas or inspired of the other informants answers and maybe not speak from their own experience. 30

3.2 Sample We began with trying to find companies using Scrum within one or more projects. These companies were found with help from contacts working on companies using Scrum within one or more projects. Our contacts provided us with contact information to people working within a specific Scrum project. So, after selecting three companies we asked two people in each project if they wanted to be informants to this thesis. We strived for making two interviews on each company, but at Company B we could only do one interview. The selection of informants for the interviews was based on what knowledge they possessed to what extent they could contribute to the essay and on a four criteria basis. The informants needed to have: 1. Experiences with Agile project methodology have been a part of a project using Scrum. 2. Experience of leading this type of projects or be a part on the project 3. These projects, they had experience from, needed to be within software development. 4. In order to make the interviews face-to-face we needed the informants to be located in south of Sweden, in the region of Skåne. In every company/project we tried to find one person that had a leading position and another one who was a part of the project. In Company A we chose one Scrum-master, with experience of leading the project, and the other person chosen were a business analyst, with experience of being a part of the same project. In Company B we only found one person to interview, he/she was a product manager in the project we talked about and had experience of working with Scrum. This person did not only have experience of how the project was led, he/she was also a part of it and saw how they worked within it. In Company C we interviewed two people, one was head of development with staff liability for this project using Scrum, and the other one was technical expert, adviser and he/she also did some development. The only one not fulfilling all of the four criteria is the head of development on Company C, he/she does not fulfil criteria 2. However since he/she has staff liability for the project, chosen in Company C, and have insight in how they worked with Scrum we believe his/her knowledge about this subject is helpful in this thesis. This knowledge is comparable with the knowledge a Scrum-master or a project leader in the sense that these people see the whole project process, how the team works and knows why Scrum started to be used. The different companies and informants will be presented a bit deeper in the chapter Findings. 31

3.3 Interview guide Our interview guide was based on four different themes, as explained in Choice of methods : Introduction, Agile, Scrum and Closure. The questions we asked within the theme introduction is presented in table 3.1, questions about Agile is presented in table 3.2, questions involving Scrum in table 3.3 and the final phase, closure, with the last question is presented in table 3.4. The interview guide we used in the interviews may be found in the appendix in both English and Swedish. Jacobsen (2002) discusses a few mnemonic rules to think about when making questions for a survey, some of these rules were also applicable on the questions you ask to an informant on a face-to-face interview. For example make an introduction with harmless questions and also, that is why we started off with the introduction, some general questions about who he/she is, what and how much experience he/she got. Another mnemonic rule is to try the questions on someone, in order to see if they are easy to understand. We tested the questions on three different persons, non-related to each other. They were asked what they thought about our question, how they related to our thesis and also give examples on other questions to ask. This is the introduction theme shown in table 3.1. We started off with three harmless questions in order to help the informant start talking and also to let the informant tell us why he/she was the right person to interview, establish that he/she had fulfilled our the criteria s we decided for our sample. Table 3.1: Introduction questions Theme Question Connection to the research model Introduction What did/do you work with within this specific project? How long have you been working within this role? What type of project are you going to talk about, referring Agile/Scrum? In order to ensure the position the informant has in the project we ask about, and to see that this person was the right one to interview. Get an idea of how long the informant worked with those he/she is talking about, how much experience he/she has within this role. To ensure that there is a software development project informant is talking about. 32

The second theme was about Agile, what Agile means to the informants, what is special with Agile methodologies, why they decided to use Scrum and not the other methodologies within Agile (Table 3.2). For example, we asked What is Agile development processes to you, what does it mean? in order to get the informants are s of the values and principles so that we could finish our own ought s and are s model. The last questions was asked in order to find out if there are any usefulness with Agile methodologies, also so that we could compare and discuss the usefulness seen and discussed in models and guidelines found in literature. Table 3.2: Agile questions Theme Question Connection to the research model Agile What is Agile development processes to you, what does it mean? Please give example How long have you been using Agile management methods? (Answer for both your and the company's experience.) Which other methods have you, both the company and you as a person, used? (Both Agile and traditional) Why did you choose to switch from the methods you used before to Scrum? This question is asked in order to get informants approach to Agile development processes, in order to compare them to the different interpretations of the Agile Manifesto values and principles, the Ought s in the research model. This question asked in order Asked to get an idea of how much experience both the company and the informant have with Agile method. This question is asked in order to identify the methods used in excess of Scrum. In order to see what may have been deficient in previous methodologies. Find out if there are and specific usefulness, advantages or disadvantages with the different methods. The Scrum theme includes questions about the Scrum process, shown in table 3.3, how the different companies use Scrum, if anything is critical/necessary or unnecessary. With this information about how they works in Scrum we are able to draw a model of how the work looked then compare and discuss it to the other models, research model and the other companies. We also wanted to know if there were any specific advantages or usefulness seen in Scrum, something that the informant forgot to tell us when we asked about advantages/usefulness within Agile methodologies. 33

Table 3.3: Scrum questions Theme Question Connection to the research model Scrum How long have you been working with Scrum? (Answer for both your and the company's experience.) Why did you/your company decide to choose Scrum? Were there any expected advantages? What does the work within the project process, with Scrum, look like? (In all phases: Pregame, Game and Postgame) Which parts of the Scrum management process is the most critical? (Phases or parts that you cannot manage Scrum without.) Motivate Are there any part within Scrum that might feel unnecessary? (Phases or parts that you can manage Scrum without.) Motivate From your experience of working with Scrum, is there anything you want to change with the method? (Both positive and negative) This question is asked to obtain an impression of the experience of the informant and the company has to work with Scrum. These questions are asked to find out whether the informants see/saw some advantages to working in Scrum for this specific project. Why they chose to work in Scrum can also explain if /why Scrum fits in special projects. This is also connected to the research model, advantages part. In order to compare Abraham et al., (2002) s model, we need to know what our informants working process in Scrum and all phases look like. Connection to the research model consisting of Abraham et al., (2002) s model. This question is asked to specify which part is in development that are most important, to see if there are any part of Abraham et al., (2002) 's model that needs to be more focused on. This question is asked to identify potential lot in the development process that may be unnecessary, to see if there are any part of Abraham et al., (2002) s model that can be taken away. This question is asked in order to get the informant to try to evaluate their own work with Scrum's development processes. To see if there are anything that can be changed in the process and still have a successful ending. 34

We wanted also to have a closure phase, shown in table 3.4, in order to ensure ourselves that we had not forgotten anything. And with the questions in the closure theme our informants can tell us anything he/she thinks is valuable information about anything related to this thesis. Table 3.4: Closure question Theme Question Connection to the research model Closure Is there anything else you want to add to this interview? Anything we might have forgotten to ask you or just something you want to add. This question is to ascertain that we have not forgotten anything and also that we really did get all that the informant believes is important and/or interesting. 3.4 Interviewing, transcribing and analysing Before every interview we had sent out an e-mail with information about us, who we were, what the thesis was about and information about confidentiality and that we wanted to record the interview. All interviews were held at the informants work place, and the date and time was decided by the informant as well. In the beginning of every interview we started by informing the informant, similar information to the one we sent out, in order to make sure the informants were well informed about this whole process. We also asked if it was all right to record the interview, and told them that we wanted their approval to use the transcription before using it in the thesis. The interview was led by one interviewer, asking questions from the interview guide, and the other one was a secretary, which made sure that the audio recording is working properly, asking follow-up questions and also wrote notes during the interview (Denscombe, 2009). So if the recording device did not work or if the sound from the interview was unclear we had a backup, notes, to use. However our recording device worked well but there were some problems to hear what the informant were saying and then the notes came handy. When the informant read through the transcriptions they also made some comments if something was misheard and we corrected it. After every interview we transcribed it. The reason for transcribing it directly after the interview was that we had the interview fresh in the memory, and also in order to become better interviewers until the next interview. When you are listening to you own interview you can hear what you are doing good and what you can do better. According to Kvale and Brinkmann (2009) you cannot read how to become a better interviewer you need to practice it, and we believe we became better and better the more interviews we did. When transcribing we transformed the spoken language from the audio recording, and notes, into written language since it is easier to analyse written language (Jacobsen, 2002). Words that where not informative, pauses and body language where not included in the transcription, because they had no affect our result. The transcriptions are presented in tables with three columns: Row, Question/Answer and notifications. The rows are appropriate because is easier for us as writers to refer to a specific sentence and it is also easier for the reader to find where specific information can be found. In the 35

Question/Answer column we have made an Q in front of every sentence we as interviewer are saying, and a A in front of everything the informant are saying. In this way it is easier to understand who is saying what. In the Notifications column we have made some notes about what areas are treated. Av&p stands for Agile values and principles, Sdp stands for Scrum development process and U stands for usefulness with Scrum or Agile. The notifications were also very helpful when we analysed the data from the interviews, it became more structured and in that way it became easier to make comparisons to our research model (Kvale & Brinkmann, 2009). After the notifications were made we did a compilation with all information, in the chapter Result, all information was divided into two different areas; Agile and Scrum. A summary in the shape of a table is presented at the end, in order to make a review of what was said. The result was later on compared to the research model, as seen in the discussion/analysis. The literature research summary is our research model and in order to test the generalization in the research model the empirical studies will be compared with it (Kvale & Brinkmann, 2009). All interview transcriptions can be found in the appendix. 3.5 Validity and reliability In order to achieve data triangulation and a report with good quality we tried to use as many different sources seeing and explaining the same subject as possible (Seale, 1999). The different sources we have used consist of the five interviews and collected literature about the subject in form of books, articles, conferences and other normative literature. Since we have two informants in each project, except for Company B, this has helped us to see more than one side of the project. We are aware of the fact that more interviews, within every project, and analysing of for example documentation is preferable in order to achieve data triangulation. However we have strived for achieving it. To achieve researcher triangulation (Seale, 1999) we have both done transcriptions of the interviews and the ones we did not write ourselves we have read through. We have also checked each other s work, in order to see if we interpret what was said in the same way. In order to do this we made some test samples, randomly chose a part of the interview that we listened to and checked if it was transcribed correctly. In this way the risk of information get misinterprets will minimize, since the two of us are interpreting. In order to create as high validity as possible and a good chain of evidence we have chosen to add an extra column in the interview guide that tells how the question is connected to the research model. This shows the readers how we thought when asking the questions and on what way they are connected to the framework. We have also made it possible for other researcher to make a replica of this study, if they want, because everything we have done is told in the chapter Method together with motivations to why we did it. All informants were treated the same way before, during and after the interview in order to strengthen the reliability of this study, as Kvale and Brinkmann (2009) suggest. They all got the 36

same text about who we were and what this thesis was about, before the interview. In the beginning of the interview we read the text again, so that we knew that the informant really understood it. One of us was asking all questions, and other one was making notes, responsible for the audio recording and asking follow-up questions. The reason for recording the interviews was make it possible to listen to the interviews again and again in order to ensure that nothing said during the interview was missed. All informants also have had the opportunity to read through the transcription from their interview in order to make sure that we have not written anything that they did not mean/say. When reading through they could also check to see if any revealing information were there, and needed to be taken away. This is a good way to check both the quality and to be ethical correct, giving them the opportunity to see what we are going to publish in out thesis and correct the information. 3.6 Ethics On every interview we informed about whom we were, why we wanted to do an interview with them and what this thesis was about, so that the informants knew what they were participating in. A text with the same message was also sent out when we asked if they wanted to help us by being informants to our thesis. We also asked the informant if we were allowed to record the interview and transcribe it, and told him/her that everything he/she said was confidential. Since they were well informed and knew what they were taking a part of they had informed consent (Kvale & Brinkmann, 2009; Jacobsen, 2002). All information about who the informant is and what company he/she works is confidential, so we had to censure some of the text. In some cases the information is just removed, since it was not important to the thesis, and in other cases the information was rewritten. For example instead of writing where they had their main office we wrote that the main office were located in another city. The sensitive text was censured (Jacobsen, 2002), and all our informants have given their approval of using the transcriptions. 37

3.7 Criticism of the sources Since all empirical research is based on interviews with real human beings, and their answers to our interview questions can be affected on many thing that we do not have any control of (Kvale & Brinkmann, 2009). They can for example be affected on their memory, their mood on that specific day and how they experience me as an interviewer. According to Hultén et al. (2007) some informants tried to avoid extreme statement when they are interviewed. However, this is a phenomenon that we cannot say with certainty did not occurred. We are aware of this when analysing the data collected from empirics. Most of our literature is normative, this information have not been evaluated and thereby might be seen as unreliable data. However most literature written about Agile and Scrum is normative and presumptive and there is nothing we can do about it. We have tried to choose literature carefully, been very critical when choosing literature to use. We believe all literature is reliable since much is written by one or more of the founders to the Agile manifesto and/or Scrum. Our research model is much based scientific written and reviewed literature. As also seen in the research model we have compared the authors statements and taken the ones that is most used in the literature, has the most authors claiming/stating the same things. 38

4 Findings This part will present the result of the empirical study. The chapter begins with focusing on each company, the project the informants are talking about and what Agile and Scrum really means to them. The chapter will continue with presenting the values, principles and the Scrum process for each company. This chapter ends with presenting the usefulness found, by the informants, with both Agile and Scrum. Every subchapter ends with a summary of what was written. 4.1 The companies This chapter will present the companies, how they came to work with Agile development methods, why they chose this methodology and their view of what Agile development methods is and what usefulness they could find. 4.1.1 Company A Company A was started in the 1940s and has since then grown to 127 000 co-workers in over 40 countries. Company A participated with two interviews, informant A1 is responsible for products developed in Company A, but in this specific project he/she worked as head developer, Scrummaster and worked with the specific project for 2 years. Informant A2 worked as a business analyst and Activity leader for this project, his/her main responsibilities, as a business analyst, was to find out what needed to be developed and make sure that the right things were put through testing. As an activity leader, Informant A2 had the same responsibility as a mini project leader. The project that the informants from Company A talked about during the interview was a software development project of a customer order system. The project was ongoing for 2 years and it was the first time that both informants worked with a method within Agile methodology, Scrum. Company A saw Agile methodology as a way to bring all the developers together, so they did not sit by themselves all the time while doing their job. One problem that this specific project had was the physical absence of the customer; in this case, the customer was based in another county and had no mean or interest to be involved in the project. They had to assign a product owner within the project, one responsible for the product, who discussed changes with the customer about what they really wanted and how they wanted it prioritised. Noteworthy is that using Agile methodology is not a general change within Company A, this was individual initiative from some of the project members who wanted to try working with the Agile 39

methodology. This also forced the project to make some changes in their way of working with Agile methodology so it would fit Company A s way of working. However informant A2 felt that they could still respond to the changes of the project without breaking the rules of Company A. Informant A2 also saw the benefit of the working environment within the project team as it gave the members a better environment to work in. Company A had previously used the Waterfall model and now saw a way to make their work flow more flexible and ready for change that might occur and deliver more products. Both informants agree about that even thought they had a product owner it would have made the project work easier to have closer contact to the customer. Informant A2 acknowledges that the project became more flexible, but there was a need to control the flexibility so the cost of change did not get out of hand or that people where doing the right things. Company A also saw documentation as an important part of the project that was needed for reporting within the company and when handing over the product to the customer. 4.1.2 Company B Company B is company with its base in central Europe and operating in over 40 countries with around 110 000 employees and was founded in 1967. Company B participated with one informant for the interviews; informant B1 worked as a production leader for the specific project and also has experience of working with Scrum outside of this project. The project at Company B started to develop a web community where informant B1 had to teach the project team to work with Agile methods, Scrum in this case, as they had not done it before. The company was looking for a way to manage short and fast project and having them run simultaneously. They wanted all of these small projects to run on the same structure and platform, and also wanted to avoid long designing and planning phases that would elongate the projects even more. With the help of short iteration and retrospective Company B could make sure that they always were improving themselves, learning from every iteration. The ability to get the feeling of satisfied was something that informant B1 felt that he/she never were been able to create with other methods. Informant B1 also saw the benefit of the improved customer relation that Agile methods gave you. Since you need to work together with the customer you a able to create a close relationship with the customer faster, and by working alongside with the customer informant B1 also felt that they could customize the product more to the customers need. Informant B1 also saw Agile methods as more flexible as there is always a readiness for change and feedback from the customer containing change, and with the short iterations is not that hard to adapt the project to the change. In more traditional methods you had to manage all changes planned to be done, this took time and often lead to a negotiation between the change and the original plan. Informant B1 saw the benefit of cost reduction, because by working with a customer that can work with Agile methods informant B1found that the development will be more cost efficient in the long run. However according to informant B1 Agile methods cannot be called a cheap methods, it takes many recourses to work in this fast pace that is expected and to 40

keep a good quality also makes it cost more recourses. The company needs to make sure that they are having a good cash flow right from the start of the project. 4.1.3 Company C Company C is a large organisation with their base of operation in Sweden; the organisation has more than eleven thousand employees and sells their products in about one hundred countries, and has a history stretching back about 125 years of doing what they are doing. Company C participated with two interviews; informant C1 is a head of development in Company C and has reasonability over the developing team and informant C2 worked as a technical specialist and advisor in the project. The specific project in Company C is a software development project running over three and a half month, creating a system to manage price development in the organisation. Company C has used Agile development methodology for four years, before they used Waterfall model and Black Box method for developing software, the older methods were described as put in a specification and wait six months and see what comes out. (Informant C1, row 16). A list of demands in put into a project and six months later you get a product. The Waterfall method is still the general way to work within Company C so the Agile way of working had to be adapted to work with the Waterfall method. Company C choose to leave the Waterfall and Black box method because it was not successful in software development and there was no way to improve the work according to them. Company C s products are very specific and no general product, so the need to be able to adapt the product for the specific need of the customer, and one list of demands can never capture what the customer really wants. A positive thing Company C saw with the Waterfall method was that it was easy to predict the outcome of the projects. So Company C decided to start to use more Agile methods because the saw Agile as being more flexible, it was putting the customer in the centre of the development. And with short iteration where the end product was not always decided in the start of the project the need to involve the customer more into the work flow was also something they saw as a benefit with Agile methodology. Company C also thought that Agile methods gave the project team more responsibility in their work and with retrospective they could learn from past projects and iterations. Company C was clear over the fact that documentation is an important part of the project as also was needed for reporting within the company. 41

4.1.4 Summary of company findings Table 4.1 shows a comparison of the three companies and their way of looking at and working with Agile development methods. Table 4.1: Summary of company findings Company A Company B Company C Guiding words Focus Project structure Size Reasons for going Agile Having a controlled change and loose collaboration within the project. People working together to develop the product. The product is identified and what needs to be done is planned, but the project work in a way that let them have a controlled reaction to change. Large project expanding over years. Wanted to improve the development process and have a way to respond the change that might occur but still control it. Fast change with fast projects that could be designed as they were developed. People working together to develop a product fast. The work flow is not planned and the product evolves as work is done. Small projects that needs do be done fast. Wanted to be able to react to fast change and have several small projects running simultaneously. Responding to change and making sure that the change is what is best for end product. People working together to develop a product that fits the customer s need. The need of the customer and what needs to be done is planned, but the project work in a way that let them react to change if it is the best for the customer. Medium sized projects lasting over 3-6 months. Existing development methods was not working, with Agile the company could have a better control over their development and make sure the product developed fit the customer s needs. 42

4.2 Values When looking at the values of Agile development methodology it is clear that the first statement working software ought to be prioritised over comprehensive documentation in an Agile software development project is unsupported as two of the three companies want to create working software alongside with comprehensive documentation. Only one company, Company B, support this statement that working software is prioritized over documentation. Company A and Company C did not agree as they find documentation just as important as working software. In table 4.3 the statement number two however, Customer collaboration and feedback from them ought to be high priority in an Agile software development project, is supported as all companies agree with it. In the case of Company A they see the benefit of having an involved customer, but they lack the experience of having an Agile development project were the customer actually was involved. All three companies see the need and usefulness of involving the customer but they have different reasons. Company A thought that they would be able to create a better product and have it done faster with customer feedback and involvement. Company B wanted to involve the customer so the customer could be aware of the changes that might occur during the project and give their feedback on the changes. Company C wants to involve the customer, as this will allows them to be able to create a more customized product that fits the customer s need. Both statement three, seeing change and responding to it ought to be high priority in an Agile software development project, and four, communication and interaction between the teams and within the teams ought to be high priority in an Agile software development project, are supported since all three companies agree with the statement. When the companies work with Agile development methods they always see change from both within and outside of the project and the ability to respond to it as highly prioritised. Even though Company A and Company C sees a need to control the change it is still welcome in all phases of the project. In all cases this ability to respond to change was a main reason for using Agile development methods for starters. All three companies also agrees that interaction and communication within the project and with interests for outside the projects needs to be prioritised as this is one of the things that allow the project to move as quick as possible and respond to change. Company A, Company B and Company C make sure that there is interaction and communication by setting up daily meetings, retrospective meeting and make sure there is feedback from each other during demos and from the customer. 43

4.2.1 Summary of Value findings Table 4.2 shows a summary of which of the companies agrees with the statement regarding values or not. If the majority, two out of three, agrees with the statement it is seen as supported by the empirical data collected. Table 4.2: Summary of value findings Ought s, from values Company A Company B Company C Agreement or disagreement of statement. Working software ought to be prioritised over comprehensive documentation in an Agile software development project. X Two out of three companies do not agree with this statement so it is unsupported. Customer collaboration and feedback from them ought to be high priority in an Agile software development project. Seeing change and responding to it ought to be high priority in an Agile software development project. Communication and interaction between the teams and within the teams ought to be high priority in an Agile software development project. (X) 1 X X X X X X X X The majorities of the companies agree with this statement so it is supported. The companies agree with this statement so it is supported. The companies agree with this statement so it is supported. 4.3 Principles The principles, the way the companies actually strive for when working, is supported to some extent. Statement one, two, three, six, seven and ten are all supported as all three companies agree with these statements in table 4.3. All three companies strive to satisfy their customer and deliver working software on a regular basis, what differs is how the companies interprets regular basis. Company A and Company C have fixed and regulated iterations whereas Company B s iterations depend on the project that the team is working with. The iterations that Company B has can be a 1 In the case of Company A they see the benefit of having an involved customer, but they lack the experience of having an Agile development project were the customer actually was involved. However, they still agree with the statement. 44

lot shorter then both Company A and Company C that have about one month per iteration whereas Company B can have an iteration lasting for one month but also for one to two days. The companies also welcome change at all time, even late in the process, but both Company A and Company C has talked about controlling the change and welcome the change and strive to incorporate it but have a controlled way of incorporating it so the change that actually happens is to the best of the customer, project and project team. Furthermore the companies strives to make sure that as much communication is done face-to-face and make sure that the teams interact in a way that lets them reflect on their work, what has been good and what has been bad and prioritise to learn something from the mistakes done. Two of the four remaining statements, four and nine, are unsupported. No company strive knowingly towards working as simple as possible and focusing on what work is not needed doing. The same goes with the statement that business people and developers ought to work together daily throughout the project, there is an interaction between the two members in all companies, but not on a daily basis. Instead, the members meet up on the planning meeting for the project and separate iterations, during demos and retrospective meetings. Statement five, projects ought to be built around motivated individuals, give them the environment and support they need, and trust them to get the job done, is unsupported as only one of the three companies agrees with it. Statement five states something that all companies might want to strive for, but it not something that Company A or Company C reflects over. Company A shows that one of the main reasons for working with Agile methods is because the development team should have better interaction and work together to solve problems. Whereas Company B does not mention any benefits the people in the project might have and Company C does not mention it either. Statement eight, technical excellence and good design to enhance agility ought to be continuous attended, is something that yet again is not mentioned by the companies. All companies strive to make their version of Agile work to the best of its ability but they have no clearly stated way of doing so. 45

4.3.1 Summary of Principle findings Table 4.3 shows a summary of which of the companies agrees with the statement regarding principles or not. If the majority, two out of three, agrees with the statement it is seen as supported by the empirical data collected. Table 4.3: Summary of principle findings Ought s, from principles Company A Company B Company C Agreement or disagreement of statement. 1. The highest priority ought to be satisfying the customer through early and continuous delivery of valuable software. 2. Changing requirement ought to be welcomed, even late in development the change ought is to be harnessed for the customer competitive advantage. 3. Working software ought to be delivered frequently with a preference to the short time scale. 4. Business people and developers ought to work together daily throughout the project. 5. Projects ought to be built around motivated individuals, give them the environment and support they need, and trust them to get the job done. X X X X X X X X X 6. Face-to-face conversation ought to be the preferred way of communicating. X X X 7. Working software ought to be the primary measure of progress. X X X 8. Technical excellence and good design to enhance agility ought to be continuous attended. 9. Simplicity ought to be favoured, the art of maximizing the amount of work not done, is essential 10. At regular intervals, the team is ought to reflect on how to become more effective, what was good and bad and respond to this. X X X X The companies agree with this agreement so it is supported. The companies agree with this agreement so it is supported. The companies agree with this agreement so it is supported. The companies do not agree with this statement so it is unsupported. The majority of the companies do not agree with this statement so it is unsupported. The companies agree with this agreement so it is supported. The companies agree with this agreement so it is supported. The companies do not agree with this statement so it is unsupported. The companies do not agree with this statement so it is unsupported. The companies agree with this agreement so it is supported. 46

4.4 Scrum processes In this subchapter all of the companies Scrum processes will be presented, also a figure showing what the process look like. 4.4.1 Company A When Company A decided to work with Agile they began to work with Scrum, but according to informant A1 they could not use Scrum 100% since they could not differ too much from the rest of the company. Informant A1 said that before the project could even start there was a more traditional phase where the customer expressed a need, before the Scrum project was started you needed to analyse how big the project was going to be, changes that might occur, if there are any outside dependency s and basic idea of the product. This then created the list of demands that was presented to the Scrum team. This list of demands and definition of done is very important for the project, if it is not done correctly the Scrum team will have to contact the architect and product owner to answer their possible questions, if definition of done and demand list is made in the right way the Scrum team can work continuously for the same goals. The project started with a sprint planning before every sprint started, during the sprint planning the system architect for the project was present and told the team what needed to be done with a list of demands. This was then broken down into activities and every activity was given a number for how many hours it would take to do. After this the sprint is started, with all activities being logged in the backlog and put up on a physical Scrum board that the team used. Around this board the team then had their daily Scrum meetings where everyone had to answer the questions of what they did yesterday, what they were doing today and say if they had any problems. The sprint was then ended with a demo, where the product was shown to the product owner, and retrospective where things that had been good and bad were discussed and suggestions of improved where discussed. This was done four times for every release and in a year there were four releases, 16 sprints per year. All testing was also made parallel with all the other work within the sprints. 47

The project had one backlog for every sprint and a backlog for the entire project to make sure that they knew what needed to be done, in what order and what had been completed. The distributions of the activity s was within the project team members that decided for them self what they wanted to do, but they had to follow the prioritising within the backlogs. This was something that the Scrum-master had to keep up to date with as there where some less popular activities but that needed to be done. The priority of every activity was done by the product owner together with the customer, the product owner was a representative from the team but was also seen as a customer since the customer were based in another country. The team made the prioritising of the sprint backlog themselves. The documentation for the project had to follow the standard documentation of Company A to make sure that they meet the needs of the company and it was made continuous according to informant A1. Before Scrum Pregame Game Postgame Figure 4.1: Scrum process for Company A Informant A2 saw the need of clear frames for every sprint, iteration, and saw the potential of having more than one iteration going on at the time, but as this project only had one Scrum team it was not possible. For a successful use of Scrum informant A1 thinks that the sprint planning is very critical. If the sprint planning is bad, no one knows what needs to be done, and how it should be done. Informant A1 said that it takes much more time for the team if the developers and tester need to figure out for them self what all specification are instead of just ask the architect, that got the whole picture. Too short tutorial on what the specifications really are about, what is needed and the result will be that everything takes much longer time if developers and testers have to sit and work with it instead of talking with the architect who has an overall picture. (Interview A1, row 57) Informant A2 believes that someone needs to keep an eye of the planning meeting, since they often are unnecessary long. 48

None of the informants in Company A wanted to change anything with the Scrum methodology since most of it is very reasonable. However, informant A2 thinks that analysing should not be a part of the planning phase; it should be done before Scrum even begins. The reason for that is because in bigger project is it not possible to do the analysis within planning. Informant A2 also thought that it sometimes it felt like they had too many meetings, that is was unnecessary to tell everybody how much work has been done and how much it is left. However, he/she also explained that these, daily meetings for example, are important for the group dynamic, and retrospective is important in order to learn. 4.4.2 Company B When Company B works with Agile methods they use Scrum, informant B1 said that the main benefit with Scrum is that you have no bottlenecks in the workflow, everybody works simultaneously towards the same goal. The project starts with the customer contacting the company with their problem; this problem is then more analysed group of project leaders, architects and products leader. The problem is split up into features, every feature gets points for its size, and delivery date is decided. This is something that all involved does during a prep. period, preparations for the coming project is done. These features are the put into the company s portfolio that describe what projects the company has running at the moment and how far they have come, and it is regularly updated. The project manager did the prioritising together with the customer for all features within the portfolio. The features were then designated to a Scrum team that broke down the feature into even smaller features on a planning meeting. After that, they started to plan their iterations, on an iteration planning meeting, and make sure that a backlog is kept over the features. During the development that team had daily Scrum meeting with the three questions, what am I doing, what did I do yesterday and tell the group if they have any problems. The iteration then ended with a demo for the customer or customer representative and the Scrum team had a retrospective to end the iteration. The informant also said that after the product was declared done it was delivered, the one that was responsible for that specific part contacted the customer and the product was delivered. In charge of the Scrum meeting and iterations was a Scrum-master that took directives from the group of project leaders, architects and product leaders. The Scrum team also had an assistant and that keep note of everything alongside the physical Scrum board there was also a digital event handling system. 49

Figure 4.2 shows Company B s Scrum process, created from the empirical findings. Before Scrum Pregame Game Postgame Prioritise with customer Figure 4.2: Scrum process for Company B Scrum is already a very slim methodology so informant B1 would not like to neither skip any of the steps included nor say that anything is unnecessary. Informant B2 would not add any step in this process either, since if something is added into the process model it would not be applicable on so many different processes. 4.4.3 Company C Company C has used the Scrum method for 4 years, informant C1 calls it Scrum:ish. It is Scrum but adapted to Company C and has been tuned to the fit the needs of Company C. Informant C2 however said that the Scrum process they used was how the theory prescribes: Scrum was followed exactly as the theory prescribe (Interview C2, row 44) When working with the Scrum methods Company C integrates the Agile development methodology with the general model of the company by still having the first phase of the general project where the project and product is planned. During the first planning meeting the definition of done is also defined, but this definition can be change during the project to incorporate changes. This also lets the project team report back in a way that fits the company, the list of demands created in the planning phase is then brought to the Scrum team, consisting of two to seven members. The list of demands is broken down into user stories; these are prioritised together with the customer and broken down again into a list into stories, with size and needed time for every user story. Informant C2 also mentions that they have two backlogs; we can 50

assume that these backlogs are one product backlog and one sprint backlog. All iterations and their content are planned and the length of every iteration is defined. After this the project team starts the developing process, solving the given user stories for every iteration. The team meet up every day for a fifteen minutes of daily Scrum, together with the project leader, during this meeting every team member has to answer the three questions, what did I do yesterday, what do I do today and do I have any problems. The iteration is then ends with a demo for the customer and a retrospective do identify what when good and not good and how the team can improve for the next iteration. Then it starts again by planning a new iteration. In the project team there is no Scrum-master, the team acts as a Scrum-master and if there is, some decision the team cannot take or can agree on the project leader takes on the role of the Scrum-master. In addition, there is no physical Scrum board, this is kept as a digital Scrum board for the team to access on their computers. After the release of the product, it continues in a maintenance phase. Figure 4.3 shows Company C s Scrum process, created from the empirical findings. Pregame Game Postgame Figure 4.3: Scrum process for Company C Informant C2 claims that a company using Scrum needs to complement this framework, as he/she calls it, with some sort of technical practices in order to maintain high quality. Otherwise there is a risk of just deliver fast and not deliver right good products. He/she also said that retrospective and the daily meetings are very important and good in a quality sense, because they focus on what can be improved and continuous check the quality. Both informants said that they did not want to take any part away or change the process since it is so small anyway. Informant C1 however thinks that retrospective sometime can be a bit unnecessary, but he/she knows that it is important for the project. 51

4.4.4 Summary of the company Scrum processes In table 4.4 a summary of all tasks or activities are made by the companies in the different phases is given. With this table, it becomes easier to see how they are working in each phase, also to see how they are different and similar to each other. Table 4.4: Summary of the company Scrum processes Company A Company B Company C Before Scrum Pregame Game Postgame Needs from customer Analyse if Scrum fits this process Do the design/ architecture Make a DoD List of demands Set hours on all activities Product backlog o Prioritising with customer and product owner Sprint backlog o Prioritising with team Sprint planning Work in sprints o Test o Retrospective o Check DoD o Demo o Documentation Daily Scrum Problem from customer Analyse Prep. period o Features o Size o Deliv. date o What needs to be done Portfolio with features o Prioritising with customer Planning meeting Backlog Iteration planning meeting Work in sprints o Demo o Retrospective Daily Scrum Planning o Project o Product o DoD List of demands User stories o Prioritise with customer Stories o Size o Time Planning iteration Product backlog Sprint backlog Work in sprints o Demo o Retrospective Daily Scrum Release Delivered Release Maintenance 52

4.5 Usefulness The usefulness shown in table 4.5 shows what usefulness the companies have identified and stated during the interviews. All three companies felt that they became more flexible by using Agile development methods. To some extent, all three companies also saw the usefulness of getting a closer customer relationship with the help of Agile development methods but Company A had no experience with working with a customer, just a product owner so they base their agreement on speculation and not experience. Table 4.5: Summary of usefulness findings Usefulness with Agile and Scrum Company A Company B Company C Comments More flexibility X X X Closer customer relationship More customized X X Cheaper Learning environment More creativity X X X X X More productivity X X X X All three companies agree with this statement which implies that this statement is supported by the empirical data. Two out of three companies agree with this statement which implies that this statement is supported by the empirical data. Two out of three companies agree with this statement which implies that this statement is supported by the empirical data. None of the companies agree with this statement, which means that this statement is not supported by the empirical data. All three companies agree with this statement which implies that this statement is supported by the empirical data. Only one company agree with this statement which means that this statement is not supported by the empirical data. All three companies agree with this statement which implies that this statement is supported by the empirical data. Both Company B and Company C felt that the product they created became more customized to the customer by using Agile development methods, Company A could not reflect on this as they did not have the interaction with the customer that would be needed to be able to customize their product. Although all three companies called Agile development methods a cost efficient way to work as you developed a product that was done when it was done and did not need to be redeveloped because the customer was not happy as the customer was involved throughout the project. Nevertheless, Agile development methods takes a lot of resources, not more or less then more traditional methods but the Agile development methods is not cheaper according to the companies. 53

None of the three companies states or identifies learning environment as usefulness, but all three companies use retrospective as a way to learn from what they had done this lead to the fact that all three companies support the usefulness of learning environment without clearly stating it. Company A is the only of the three companies that identify the usefulness of more creativity as it becomes more fun to work with Agile development methods, according to informant A2. When it comes to more productivity all three companies claim that they see this usefulness, but they express themselves is different ways. All informants say that they delivers faster, that Scrum is a fast methodology, informant A1 said that they deliver more when using Scrum, informant B1 said that it is fast methodology and that good quality comes out of it, but that it also costs to get high quality. Informant C2 was the one standing out a bit with his/her statement about producing more, he/she said that Scrum without some sort of quality control might help produce much and fast, but produce lots of products with bad quality. 54

5 Discussion and Analysis In this chapter we will look at the value- and principle statements and create the ars s, in our research models, based on the empirical findings. The constructed Scrum process models, based on the empirical findings, will also be analysed and discussed phase by phase. The usefulness of Agile methods and Scrum will first be analysed and discussed separately. Finally the usefulness will be analysed and discussed in connection to the are s of values and principles and the Scrum process model summary of all companies. 5.1 Values Table 5.1 shows the ought s from the research model, and shows the are s from the empirical data (Chapter 4) and comments concerning the findings. Every statement will be discussed after the table. Table 5.1: Research model of values with empirical findings Ought s, from values Are s Comments Working software ought to be prioritised over comprehensive documentation in an Agile software development project. Customer collaboration and feedback from them ought to be high priority in an Agile software development project. Seeing change and responding to it ought to be high priority in an Agile software development project. Communication and interaction between the teams and within the teams ought to be high priority in an Agile software development project. Working software is important, but the need of documentation cannot be neglected. Customer collaboration and feedback is important in an Agile development project. Seeing change and responding to it is important in an Agile development project. Communication and interaction between the team and within the team is important in an Agile development project. Company B is the only of the three companies that agrees with this, the other two still see the need of documentation. The statement is then unsupported. Two of the companies, B and C, agree with this statement. So would Company A if they had the experience. The statement is then supported. All three companies agree with this statement and see this as one of the main things to use Agile methods. The statement is then supported. All three companies agree with this statement. The statement is then supported. 55

When looking at the table above, table 5.1, it is clear that the values supported by models and guidelines, ought s in the same table, also is supported by the empirical data, all but one: prioritising software over documentation. The models and guidelines support the claim that working software should be prioritised over documentation, although the authors do not say that you should skip it all together but they do think that it should not be as highly prioritised as working software. Both Company A and Company C think documentation is an important part of the project, not more or less important than working software but just as much. Company A and Company C has documentation as a part of their definition of done and the documentation acts as a mean to report further up in the companies. The fact that both Company A and Company C see the need to prioritise documentation on the same level as working software might be because they need to report within the company. Agile methodology can adapt to other methodologies and be used, however more traditional methods cannot adapt and still need the documentation for reporting and such. Company B has a structure within the company that allows the projects to prioritise working software over documentation, whereas Company A and Company C has not. Nevertheless, Company B s project and end product-size is smaller than Company A and Company C, so it could be interpreted that as the project and the end product grows in size so does the need for documentation. All three companies agree with the statement of the need to have an involved customer and to understand how important the customer s feedback is, although Company A cannot be used in order to support this statement since they the lack experience of an involved customer. By involving the customer, more companies feel that they can produce a product that will better satisfy the customer and get feedback on their work to enhance their own work, the product will then often be more customized. This is something that is crucial for an Agile development projects, the models and guidelines shows that when involving the customer you should be able to produce something that the customer will end up liking. This involvement should also lead to closer and better customer relationships. The customer will then not just be a name on a piece of paper he/she will really be an important part of the project. However, be part of the development group is not enough, the customer must feel secure enough to express what they want and need. Working closely together with the customer will probably contribute to the customer feeling of sercurity, and encourage the customer to participate more actively in the project process. The need to respond to the change that might come with the feedback or just as the project process continues, is something all three companies see as essential when working with Agile development methods. Responding to change is as shown in the models and guidelines a great benefit for the project as the will be able to adapt to a changing market and make sure that the projects end product is up to standards. The ability to respond quickly to the change is one of the main reasons for all three companies to work with Agile development methods. Nevertheless, Company A and Company C also commented that not all change is for the better. The need to control the evolution of the project and make sure that there is not just a change for the sake of change making sure that there is a real need to incorporate the change. Company A had to make sure that some things that always needed to be done where done and not just put aside because of 56

the change. Company C wanted to control the change so the customer did not come up with changes just because they could, but because the change was needed, otherwise the cost of the project could become too high. Moreover, the best way to discuss changes and how to react to them is done face-to-face. All three companies informants agrees that face-to-face communication is the best way to communicate, however in some cases it was not possible to physically communicate, but with help from modern communication techniques the companies could maintain high-quality communication, both internally and externally. These efforts were necessary to avoid misunderstanding and to make sure that everything was clear to both parties in the conversation. This is linked to all parts of the Agile development method in the models and guidelines, without an interaction and face-to-face communication the change, documentation or customer feedback might get misinterpreted. When discussing change, showing models and architecture to the customer or are receiving feedback from that customer it is important that the communication is as face-to-face as possible to make sure that there are no misinterpretation. 5.2 Principles Table 5.2 shows the ought s from the research model, and shows the are s from the empirical data taken from chapter 4 and a column to remind how the findings looked. Every statement will be discussed after the table. Table 5.2: Research model of principles with empirical findings Ought s, from principles Are s Comments 1. The highest priority ought to be satisfying the customer through early and continuous delivery of valuable software. 2. Changing requirements ought to be welcomed, even late in development the change ought is to be harnessed for the customer competitive advantage. 3. Working software ought to be delivered frequently with a preference to the short time scale. Satisfying the customer through early and continuous delivery of software is important. Changing requirement, even late in the project, is welcome to the project, but it must be controlled. Delivering working software as often as possible is important in Agile development projects. All three companies agree that this is important to strive for when working with Agile methods. All three companies agree with the statement and always welcome change, but the need to control the change so it does not spiral away in cost is needed. All three companies agree with the statement, but the interpretation of short time scale changes from company to company. 57

4. Business people and developers ought to work together daily throughout the project. 5. Projects ought to be built around motivated individuals, give them the environment and support they need, and trust them to get the job done. 6. Face-to-face conversation ought to be the preferred way of communicating. 7. Working software ought to be the primary measure of progress. 8. Technical excellence and good design to enhance agility ought to be continuous attended. 9. Simplicity ought to be favoured, the art of maximizing the amount of work not done, is essential 10. At regular intervals, the team is ought to reflects on how to become more effective, what was good and bad and respond to this. Having business people and developers working together when it is needed is important in Agile development projects. Building projects around people and trusting them to do their job is important in Agile development projects. Face-to-face conversation is the best way to communicate in an Agile development project. Working software is the primary measure of progress. Working to continuously evolve and customize the Agile development process is important for an Agile development project. Finding the easiest way to develop a product is important for an Agile development project. Reflecting over what is good, bad, how to respond to this and how to become more efficient is important for an Agile development project. None of the companies agreed with this statement, although they saw the need to involve the business people into the project when it was needed. Only one Company, Company A, mentioned the fact of having motivated people, but all companies trust in the people in the project to do their job. All three companies agree with this statement, all have physical meetings every day and make sure that all the people in the project can communicate face-toface. All three companies agree with this statement as they all focus on developing software, so how much of the software is done is the way to estimate the progress. None of the companies agrees with this statement, but all three companies try to evolve their version of Agile as often as possible. None of the companies agrees this statement, but they all see the need to find the easiest way to develop the product. All three companies agree with this statement and they end every iteration or sprints with a retrospective to evaluate them. 58

The table of the principles identified from the Agile Development Manifesto are also largely supported by the companies. All three companies considered it important to satisfying the customer while continuously and frequently delivering. However, what time intervals that were interpreted as frequent varied depending on the company, Company A and Company C had longer sprints or iteration lasting for 1-2 months while Company B could have iterations that lasted for a day. The interpretation of time can be linked to the size of the projects as Company B generally had smaller end products resulting in short iterations or sprints while Company A and Company C had one large end product leading to more releases for a single product and more to do for every release which resulted in longer iterations. Nevertheless, the time used to develop a product was still shorter then more traditional methods. As the models and guidelines show it is important for an Agile development project to not only have communication with the customer but have working software that the customer can evaluate and give feedback on. By doing this the companies can get a more customized product for the customer and make sure there is no need to redo anything as the customer will know what he or she gets. All three companies also agreed that change is important for an Agile development project, but as stated in the previous sub chapter Company A and Company C saw a need to control the change. Why Company B did not mention this might be because the question was misinterpreted. It might also be because Company B handled smaller projects and the smaller project the fewer the changes, and the changes that might appear will not cost as much because the projects are relatively small where a change for Company A or Company C might cost both customer and the companies many resources. The need to manage the change is also something the models and guidelines recognises, not in the way of controlling it but to make sure that the change that is done is done because it is needed and heightens the products value to the customer. The need to have business people working alongside developers on a daily basis was not identified by any of the companies. All companies saw a need to involve business people to make sure that their competence was used in the project, but none of the companies worked with business people on a daily basis. The need for these two types of project members to interact was motivated by the fact that this would let the members learn from each other and understand why they work as they work. This may sound good in models and guidelines, but in practice there might not be time nor interest for all members to be up to date and understand what other members of the project is doing, as long as they are doing their job everyone is happy. It might also be because of the fact that both Company A and Company C have a more traditional project methodology in the companies as a whole, where the interaction between the business people and developers is not a part of the business plan. The models and guidelines shows that having motivated people in the project are a good thing, the workforce will feel stimulated in their work and be more productive and happy. The need for motivated people within the project might be something that all three companies see as a must, something that of course is needed and does not mention it as it might be something basic and incorporated without mentioning. 59

This trail of thoughts might be supported by the fact that all three companies agree that face-toface conversation is preferred. The companies want the people in their project to work together alongside each other, they care about the fact that their group members talk and interact with each other maybe they also care about how motivated there people are. All three companies also want their project members to learn from each other; at the end of every iteration or sprint they plan for a retrospective where the members look at their work, what was good and bad, what they could learn and improve and how to be more efficient in their work. This way of working should lead to a more motivated staff since the get constructive feedback both from the customer and the company. Alongside this, all three companies also agree that the best way of seeing progress within the project is to look at the amount of finished software. By finished the companies mean software that has either been completed (according to Company A and C) or has been released (according to Company B). Moreover, for every piece of finished software there should have been a retrospective and demo meeting to evaluate the software and the projects work with the software. The models and guidelines shows that by having a learning environment the group will grow to work more efficient and be able to look back on old mistakes and not do them again. When looking at the table 5.2 and what the companies have said about the process and the way of simplicity we can see that not one of the companies agree with this statement, They see the need to plan to make the development of a product as easy as possible. The statement might have been formulated in unfortunate way. Stating that you strive to make as little as possible might sound bad, and no customer would respond positively to this statement. When analysing the values and principles it is important to not forget what was left behind, three statement where abandoned because they lacked support from enough authors, four or more. However, we feel that these at least should be discussed in order to see if an abandon statement has support in practice. Moreover, this is not a good enough motivation to miss possible important knowledge. The needed effort to maintain the solution ought to be balanced with its value is one of the three statements that were left behind because it lacked support from the authors, as some authors saw the need when managing a product that the cost of managing should not exceed the value that the solution brings to the company. In this case, the statement is still unsupported, one might make a connection to the need to control change, but as this statement only involves maintaining the product we believe that it is not supported by our companies. Statement two of the three, selforganizing teams ought to give the best architectures, requirements and designs, is also unsupported as no companies identified the need to have a self-organized team to achieve there architecture. This was done by the architect of the project along with the project and even thought it was a collaborative effort there still was a need for an architect. The third and last statement, the sponsors, developers, and users ought to be able to maintain a constant working pace indefinitely, is also unsupported by the companies. Even though all companies talk about iterative 60

planning and frequent delivery they also confirm that there are people in the project and they can no work indefinitely but need to be treated as people that have their ups and down. 5.3 Scrum process In this chapter, we are going to analyse and discuss each phase separately; before Scrum, pregame, game and postgame separately. 5.3.1 Before Scrum As seen in the three different models for how our informants worked with Scrum, in their projects, they all began the process different. Company A and B started off by analysing the need/problem they got from the customer, in order to see if Scrum was the right method to use. We cannot say whether Company C also did this in their project, if they had a period when decided if Scrum was the right methodology to use before they started, since our informants did not mentioned or talked about it at all. Informant C1 and C2 did not talk about what happens before the Scrum process begins with its pregame phase. In Abrahamsson et al. (2002) there is no phase, before starting with the pregame phase, when analysing if Scrum is the right methodology since it is not a part of the Scrum methodology. According to Abrahamsson et al. (2002) all analysing is done in the Pregame phase, but informant A2 believes that all analysing should be done even before Scrum starts since it is hard to otherwise know if Scrum fits the specific project. We agree with this, since Scrum is a model that might not fit all projects or companies. We believe that everybody, especially the customer, needs to be aware of how demanding this method really is, as informant C2 also said. This methodology needs a customer that wants to be a part and have time to get involved in the work, otherwise the methodology is not Scrum and the usefulness that comes with Scrum might not come. So having a part before beginning to use Scrum of analysing might be a good idea. This might not be a part of the Scrum process model, since it is not a part of the Scrum process but it needs to be done. Nevertheless, we believe there is a fine line between the phases before Scrum and pregame. Some companies might not even know what strategy or project process they are going to use so they do their planning before Scrum, and when they are done with their planning the go directly into the game phase, so their planning phase before Scrum indirect becomes the planning part in the pregame phase within Scrum. 61

5.3.2 Pregame Figure 5.1 shows how the pregame phase looks in the research model, and in the empirical findings. Abrahamsson et al. (2002) Company A Company B Company C Figure 5.1: Pregame phase All companies including Abrahamsson et al. (2002) includes some form of planning within this phase. Company A have their planning before Scrum and also a sprint planning in the Game phase, before each sprint but they have a list of demands that is broken down into activities. Company A does not specify these activities as planning, since that said they did all planning before Scrum, but this is planning. Planning how and which activities are going to be in the product backlog and set time on them. It makes sense to have planning in this phase, because it is the pregame phase, the phase where you prepare for the game and planning is a part of preparing. Both Company B and C include planning in this phase, but they do not make the planning in the same way. Company B has their prep. period to do planning of what needs to be done, they also have a planning meeting, and it is the information from the planning meeting that follows into the game phase. Company C has first planning for the whole project and then a planning for each iteration. None of the companies mentioned anything about making the architecture in this phase, this is something that separate models and guidelines with practice. It might be so that the informants referred to both designing the architecture and planning the project process when they talked about planning. Because, in our eyes, designing the project are also some sort of planning, planning how the process will look. All the companies have their own ways in this phase but none of them differ much from Abrahamsson et al. (2002) s model. It is only planning made within this phase, and with planning we now mean both planning and designing architecture. 62

Company C makes their DoD in this phase, Company A made their before Scrum, and Company B does not seems to have a DoD. DoD is not included in the model made by Abrahamsson et al. (2002) either, but it is a part of the Scrum models and guidelines according to Björkholm and Brattberg (2010). According to informant A2 DoD very is important. Without it how do you know when you are done? We agree with informant A2, DoD is very important, and because of that is should be a part of the Scrum process, it should be visible in the model. If there is no DoD it will be difficult to know when a task is considered done, and at the end of a project process the developing team will probably have a lot of unfinished tasks left to do. The unfinished tasks then need to be remade or parts needs to be added, because of that we believe that there is a high risk of having to do the task repeatedly because there is no DoD. It will be much more time consuming to not have a DoD according to us. Since Company B made their DoD in the planning phase and Company A also did their DoD in their planning phase, before Scrum, we believe DoD should be a part of the pregame phase when all planning is made. Both A and C have a list of demands, what needs to be done, and Company B has a list of features of what needs to be done. We can assume that these, list of demands and the features, are similar to each other since they include what needs to be done. How they go on with these demands/features are not similar between the other companies. The demands becomes activities in Company A, the activities are put in a product backlog that is continuously updated, we believe that this makes Company A very flexible since they have the chance to change without any struggle, changing is a big part of working with Scrum. The activities in product backlog are later on divided into a sprint backlog. Company B are also very flexible in the sense that they update their portfolio with features continuously. From the features in the portfolio Company B makes even smaller features and after that puts them into a backlog. Our informant did not mention anything about having two backlogs, one product and one sprint backlog list. Therefore, we assume they only have one for the whole project, a product backlog list then. Company C makes stories of the their demands and the stories are then put into the two different backlog lists, first product backlog second the sprint backlog. They have the most included in their pregame phase. All the companies have some sort of a backlog list, A and C has a product backlog list. Company B have not specified what kind of backlog list they got but we can assume it is similar to a product backlog list since this is the only backlog list they got. Abrahamsson et al. (2002) also got a product backlog list in this phase. These lists are all to-do-lists based on activities, features or stories, but the core is the same. There should be a step in Abrahamsson et al. (2002) s model, after planning, breaking down things-to-do within the project into activities that can be placed in the product backlog list, since this clearly is a step in practice. 63

All companies did their prioritising together with the customer for the product backlog, and according to the models and guidelines the prioritising should be made together with the product owner, which often is the customer. We believe that doing the prioritising together with the customer helps with making a product more customized and it also helps to create a closer customer relationship. Because when the customer is involved and expressed what he/she wants it is easier for the developing tea to create a customized product, a product that the customer really wants. The more often the Scrum team meet their customer the closer the relationship can be it takes time and human contact in order to create a close customer relationship. However, making the prioritising with the customer is not visible in the model made by Abrahamsson et al. (2002). Because the customer is present when doing the prioritising in practice, it should be included in a Scrum process model. 5.3.3 Game Figure 5.2 shows what the game phase looks in the research model, and in the empirical findings. Abrahamsson et al. (2002) Company A Company B Company C Figure 5.2: Game phase Daily Scrum is something that is used much in practice, all of companies used it. Daily Scrum is also included in most models and theories found in literature but not shown in Abrahamsson et al. (2002) s model. It is very obvious that the companies are following Scrum as the models and guidelines prescribes, since they all focus on the three same questions on every daily meeting: 1.What did I do yesterday, 2. What am I going to do next/tomorrow until next daily Scrum? 3. Do I have any problem? We think that it is strange that this is not included in Abrahamsson et al. (2002) s model, since it is a big part and very significant for Scrum. Models and guidelines prescribe it and it is used in practice exactly as it is prescribed so why is it not included in the Scrum process model? Daily Scrum very important according to informant A2, C1 and C2 since 64

these meetings gives the team a chance to learn, and to improve the group dynamic. With daily Scrum the team also is more flexible since they can reprioritise and help each other with problems. Not that many other methodologies offer this possibility to learn and help each other in the team. Retrospective is also good on this points, learning and being flexible for the same reasons. All three companies also had a retrospective meeting after every ended sprint, and it is prescribed to be used according to the models and guidelines found on the subject, but this is not included in Abrahamsson et al. (2002) s model. In Abrahamsson et al. (2002) s model they have called it analysis instead, where you analyse the work that has been done and design where you change the design as the work progress. It is similar but is should be named the same thing, otherwise it might be confusing to have different names on the same activity. Moreover, all three companies included Abrahamsson et al. (2002) makes demo versions at the end of each sprint. However what differs among the companies is first of all that Company B has no sprint backlog, as far as we know. There is a chance that the informant B1 forgot to mention this, and since we did not interview another person on this company we cannot be certain about this. We do know that they use a backlog in the pregame phase. Secondly, only Company A makes updates of their sprint backlog, testing, documentation and checking their DoD at the end of each sprint. However, we do believe that the other companies also updated their backlogs, since they said that they were flexible with changes within in project. With updates you are more flexible since this backlog is constantly updated. The two other companies did not say when their testing or documentation was made, but we think it is a good way to have testing and making documentation at the end of each sprint. In this way it is easier to not forgetting anything them doing documentation or having problem with testing something very big and therefor minimizing the risk of having any big errors. Abrahamsson et al. (2002) also have testing as a part in the end of each sprint however they do not have and documentation here. All the documentation is made in the last phase closure. When doing all documentation in the end it is probably much documentation that needs to be made at one occasion, but when doing it at the end of each sprint it is less documentation on a few occasions. We believe that this way is easier and since one of the companies use it, it is probably useable. Company B has an iteration planning meeting in the beginning of each sprint, and Company A has sprint planning in the beginning of each sprint also. We can assume that these planning meetings are similar to each other because every sprint is an iteration. There is not any planning at all made in this phase according to Abrahamsson et al. (2002) s model, but the models and guidelines prescribe a planning meeting in the beginning of every sprint. The sprint planning is also something that seems to be very important, because according to informant A1 the sprint planning is critical in the sense that if the planning is bad no one knows what to do and there might be problem later on it the project. It might be good to begin each sprint with some sort of planning, as the models and guidelines prescribe and as two out of three companies does. This should also then be a part of the Scrum process model. 65

All of the companies included the Scrum process model made by Abrahamsson et al. (2002) works within sprints, short iterations with a number of activities, tasks or features. When working in short iterations the teams become more flexible since every sprint is flexible with what needs to be done, who is doing what and so on. If something needs to be reprioritised or a new task needs to be done it is easy to plan it and get it done in the next iteration. Since all iterations are short, it does not take long time before the task is done. None of the companies game phase differ much from Abrahamsson et al. (2002) s model, this indicates that the Scrum process in practice is quite similar to the on in models and guidelines about Scrum. 5.3.4 Postgame Figure 5.3 shows how the postgame phase looks in the research model, and in the empirical findings. Abrahamsson et al. (2002) Company A Company B Company C Figure 5.3: Postgame phase There is not much to say about this phase, our informants postgame phases looked very similar. They ended the process with a release, or in Company B s case the product was delivered. However, Company B had four releases in a year, so after a release the start over in the game phase again and continues into the postgame phase again. These two phases are in Company B s case also iterative. For Company C their product went into the maintenance phase after the release. We believe that this last phase will look very different depending on what kind of project it is about, so it will be very hard to make a general model for how it looks after a release. However in Abrahamsson et al. (2002) s model they have system testing, integration and documentation in this phase. As said before we believe all documentation should be done after each sprint instead, but to integrate all parts and also test the entire product as a whole seems to 66

be very reasonable. This might be a part that our informant forgot to tell us, what happens before the release, when the product is declared finished. 5.4 Usefulness Table 5.3 shows all the different usefulness found in models and guidelines, in column one. The second column shows how many companies agree with the different statements. The third column shows how many authors, found in models and guidelines about Agile and Scrum, agree with the statements. For a statement to be supported it requires more than half of the companies/authors agreeing with the statement. Table 5.3: Research model compared to empirical findings of usefulness Usefulness with Agile and Scrum Number of companies agreeing with the statement 2 Number of authors agreeing with the statement 3 Comments More flexibility 3 of 3 companies 8 of 10 authors Supported by both practice and models & guidelines Closer customer relationship 2 of 3 companies 6 of 10 authors Supported by both practice and models & guidelines More customized 2 of 3 companies 3 of 10 authors Cheaper 0 of 3 companies 3 of 10 authors Supported by practice but unsupported by models & guidelines Unsupported by both practice and models & guidelines Learning environment 3 of 3 companies 1 of 10 authors Supported by practice but unsupported by models & guidelines More creativity 1 of 3 companies 2 of 10 authors More productivity 3 of 3 companies 1 of 10 authors Unsupported by both practice and models & guidelines Supported by practice but unsupported by models & guidelines 2 See table 4.5, Shows which companies agree on the different usefulness statements 3 See table 2.7, Summary of usefulness, which authors found in literature agree on the different statement 67

The most interesting usefulness here is more customized, learning environment and more productivity because there is difference between how it is seen in practice comparing to how supported the usefulness is in models and guidelines. But let us go through them one by one from the top. More flexibility is something that both practice and models & guidelines support very highly, so this indicate that this usefulness actually is an existing when applying Scrum in practice and it has been noticed in models and guidelines as well. The same goes for a closer customer relationship that is supported by both practice and models & guidelines. However, it is not as highly supported as flexibility, but it is supported and therefore seen as usefulness in both practice and models & guidelines. More customized is supported in practice but not supported in models and guidelines, the reason for Company A not seeing this as a special usefulness is because they always are trying to customize the solution as much as possible so this is not something new for them. The two other companies all agreed with this usefulness, and maybe this comes out of the fact that they both also have had a close relationship with their customer. In our opinion a close customer relationships and more customization are related to each other since they are connected. When having a customer being present it surely is much easier to understand what they want and when something is good or bad, so it will be much easier to customize a product then. We also think that high flexibility has something to do with developing more customized products, as the customers requirements changes the product will change with it. With flexibility and close customer relationship the usefulness more customized products almost comes as given in practice however still a bit unknown in models and guidelines. This might be why it these three are quite highly supported in practice. None of the informants could actually say anything about whether using Scrum is cheaper in compared to other traditional models. It is unsupported in models and guidelines as well, three out of ten authors claim this, but how many studies do actually support this? Since none of our informants had any information to prove or disprove that Scrum is a cheaper model to use they could not support it. We believe that Scrum might be a cheaper model to use because it gives a customized product, all small changes will be done during the project and since the customer is present at all during the whole process the delivered product will fulfil what the customer requires. The risk of having to do the whole project all over again because of some misunderstanding in the requirement specification will be minimized, if there are any misunderstandings they will hopefully be noticed during and not after the project. However as we understand it this methodology can be expensive as well, for example because there are many meeting when the group are not producing anything, and time is money. It is strange that not more authors than three out of ten write anything about learning environment, as usefulness, since it clearly is useful with Scrum in practice. We also believe Scrum has a learning environment, since the teams are able to learn anything new every day from their other team members. On the daily Scrum the are the three questions to be asked and answered, when listening and trying to solve the different problems the members has stumbled 68

over all members try to solve them. Hopefully many in the group will learn something new, but even if there is only one person in the group learning something new each day we think it is a learning environment. On the retrospective, when the team is looking back on the whole sprint they also learn something. They might learn something about how to solve specific problem, what to or what not to do I specific situations. More creativity is unsupported by both practice and models & guidelines, maybe this is not usefulness that only comes with Scrum or perhaps Scrum is not supporting more creativity at all? We have no idea about why creativity is so low, because Scrum seems to be the ultimate methodology to use in order to heighten the creativity. The team can plan and prioritise everything themselves, they do not have a requirements specification that say do this, this and this. Therefore it is strange that this usefulness is that low. More productivity is seen as a clear usefulness if only looking at what our informants have said, but it is one of the lowest supported usefulness in models and guidelines. That is very strange that this is not noticed more in models and guidelines. All of our informants said that this methodology is very fast and that they are able to produce more when using it. However one informant warned for producing too fast and too much but with bad quality, since Scrum does not have anything checking or making sure that everything produced has high quality. So maybe it is not good to only produce fast and be more productive if the products produced are not of high quality? Since all our informants agree, with this, it is useful and we believe that it should be noticed. 5.5 Features in the Scrum processes that result in project usefulness By looking at the values and principles of Agile methods we can see that they have a connection to the Scrum process model s different tasks or steps. In these subchapters we will show and discuss how they are connected and why. We will end with a figure showing what features in the Scrum process that ought to result in project usefulness. 5.5.1 Agile values and principles connected to the Scrum process Here are the different values and principles presented in a numerical list. All of these values and principles will be addressed in the figure 5.4 and how they are connected to the different Scrum process steps. The numbers they are given here are the same numbers as shown in the figure. 1. Customer collaboration and feedback is important in an Agile development project. 2. Seeing change and responding to it is important in an Agile development project. 69

3. Communication and interaction between the team and within the team is important in an Agile development project. 4. Satisfying the customer through early and continuous delivery of software is important. 5. Changing requirement, even late in the project, is welcome to the project, but it must be controlled. 6. Delivering working software as often as possible is important in Agile development projects. 7. Face-to-face conversation is the best way to communicate in an Agile development project. 8. Working software is the primary measure of progress 9. Reflecting over what is good, bad, how to respond to this and how to become more efficient is important for an Agile development project. Figure 5.4 illustrates how the different Agile features are connected to Scrum process model. Before Scrum Pregame Game Postgame Figure 5.4: Agile features incorporated to the Scrum process model 70

As Figure 5.4 shows all supported values and principles from the Agile methodology can be incorporated with the Scrum process model. Customer collaboration and feedback is important in an Agile development project is incorporated in the continuous update of the backlog, inviting the customer to the demo and release of the product and always looking for the customer feedback and needs. Seeing change and responding to it is important in an Agile development project is incorporated in the product and sprint backlog, daily Scrum and the sprint as all these steps want to adapt to the changes in the project. Communication and interaction between the team and within the team is important in an Agile development project is part of the product and sprint backlog were communication and interaction between the team members and the customer will lead to a better backlogs. This feature is also part of the steps of daily Scrum and retrospective where communication and interaction to see how things are going, what has been good or bad and what can be learned from experience is valuable for the project. Satisfying the customer through early and continuous delivery of software is important, this is incorporated in the sprint and demo were the sprints allows for early and continuous delivery and during the demo the project can make sure the customer is satisfied. Changing requirement, even late in the project, is welcome to the project, but it must be controlled, this statement takes part in both sprint and product backlogs, the daily Scrum and the retrospective. As all these steps allows the project to change and fit the new requirements and with the help of the backlogs the project controls the change and makes sure it is needed. Delivering working software as often as possible is important in Agile development projects is incorporated in the sprint as this allows the project to deliver working software often. Both the face-to-face conversation is the best way to communicate in an Agile development project and the working software is the primary measure of progress feature is part of the whole Scrum process. As all steps should be done with the amount of working in mind and as much as the communication should be done face-to-face. The last feature is reflecting over what is good, bad, how to respond to this and how to become more efficient is important for an Agile development project. This feature is incorporated in the daily Scrum and the retrospective were the projects strive to learn from experience and respond to the change that might be needed. 71

5.5.2 How the Scrum process is connected to project usefulness Figure 5.5 illustrates how the Scrum process is connected to project usefulness. The different Scrum features are in circles and numbered in order to illustrate which of the project usefulness they are connected to. Before Scrum Pregame Game Postgame Figure 5.5: Scrum features connection to project usefulness According to both models & guidelines and the empirical findings Scrum methodology is very flexible. We have marked, with a circle and the number 1 in figure 5.5, where in the Scrum process flexibility can be seen. When new activities, features or stories are discovered they are added directly into the two backlogs. This means that these backlogs ate updated frequently and therefore very flexible in what needs to be done and how the prioritising is going to be. There is no need for a long and unnecessary process to include new activities, features or stories, because there is a new activity it is added into the proper backlog. There also no need for long waiting periods, in order to implement any new activity, since the sprints are short and iterative. When a new activity is needed or a change in the customer request arise the Scrum team can easily make the changes in the current sprint or move them to the next sprint. There is no long planning that will be ruined, since all sprints are planned severalty that also contributes to the flexibility with this method. The daily Scrum and retrospective also contributes to more flexibility, according to us. We believe that the team are flexible here because they make the teamwork closer together, see and learn from each other and most important help each other. Another good example is on the daily Scrum when the team themselves, decide who is going to do what, according to informant A1. 72

When needs come from a customer it is necessary to analyse them, what must be done and if Scrum is the right methodology to use in this case. This is preferably done together with the customer. The prioritising of all tasks in the product backlog is also made together with the customer, and at the end of every sprint a demo is shown to the customer. We believe that these steps contribute to a close customer relationship and helps with making the end-product more customize to the customer s needs. The more time the customer spends with the team, the easier it will become for the customer to present feedback and hopefully also contribute to a closer relationship between customer and the Scrum team. Because when a customer feels comfortable with expressing what they want and need the product will become more customized to the customers requirements, even if they change during the project process. Closer customer relationship and more customized are circled and marked with the number 2 in the figure 5.5, since they are connected to each other. As mentioned in previous sections daily Scrum and retrospective are very good in order to make the Scrum team learn from each other. For example on a daily Scrum meeting when discussing if there are any problems the one with the problem can get help from someone with knowledge about how to solve the problem. Team members can also learn from the mistakes of others, when discussing problems encountered and how they solved them. When having retrospective the whole Scrum team looks at the process, how it have progressed and if anything needs to be change. This is also a way of learning and taking advantage from own experiences from earlier sprints. The steps contributing to a learning environment are circled and marked with the number 3 in figure 5.5. We also think that having face-to-face conversations, getting quick feedback and updates on project progress will help the team being more productive. The steps contributing to more productivity are circled and marked with the number 4 in figure 5.5.With daily Scrum the teams can easily see how the project is progressing, what have been done and what is left to do. They can also give feedback to each other directly, face-to-face, which will minimise the risk of waiting for feedback via other media. By working in sprint the project proceed faster, since the iterations are short, and it will also lead to more productivity in the sense that there would not be any downtime. 73

6 Summary In this chapter we will give a summary of this thesis and also answer our research questions. This thesis aim is to identify features in the Agile software development process that are important for achieving project usefulness, in order to contribute to a more scientifically accepted basis in the area of Agile software development methods. This study focuses on the Scrum method since it is the most widely adopted Agile method within software development projects. In order to answer our main question, How is project usefulness connected to the Agile software development process?, we needed to first answer our two- sub questions: What does the process, when applying Agile software development process, look like? What are the important features in an Agile project, and what are the project usefulness that can be identified when applying Agile software development process? To answer sub question one we used three parts of our research model; Table of values with ought s statements (table 2.5.) Table of principles with ought s statements (table 2.6) And the models showing the Scrum process (figure 2.4) The tables and figures were then used to create our questions for the interview guide and with the help of the empirical data extracted from the interview we created table 5.1 and table 5.2 showing not only the ought s but also the are s for the Agile software development process. These are statements together with a model from Abrahamsson et al. (2002), figure 2.4, and was updated according to our empirical findings to answer the question of what does the process, when applying Agile software development process, look like. What the process look like is shown in figure 6.1. 74

Figure 6.1 shows what does the process, when applying Agile software development process, look like. Before Scrum Pregame Game Postgame Figure 6.1: Summary of Scrum processes To answer sub question two we used four parts of our research model Table of values with ought s statements (table 2.5.) Table of principles with ought s statements (table 2.6) And the models showing the Scrum process (figure 2.4) Project usefulness found in models and guidelines about Agile and Scrum, shown in table 2.7. With the help of the table and models we created our questions for the interviews, that gave us the empirical data needed to find which features and usefulness, identified in the models and guidelines, that wear supported. A summary of these features and usefulness is shown here. Figure 6.2 shows which Values from the Agile development manifesto that are supported by the models and guidelines and which are actually used in practice by the companies from this study. Of the five starting value-statement only three are supported by both the models and guidelines and empirical findings. 75

Figure 6.2: Summary of values Figure 6.3 shows which Principles from the Agile development manifesto that is supported by the models and guidelines and which are actually used in practice by the companies from this study. Of the thirteen starting principle-statement only six are supported by both the models and guidelines and empirical findings. 76

Figure 6.3: Summary of principles 77

Figure 6.4 shows which usefulness that is supported by the models and guidelines and which are actually used in practice by the companies from this study. Out of the seven starting usefulness two are supported by models & guidelines and five are supported by the empirical finding. Figure 6.4: Summary of usefulness These results gave us a mean to answer what features that are the main features in Agile software development process. Furthermore, the result gave us the mean to find which usefulness Agile software development process can result in. To be able to see the connection between the process and the project usefulness we had to first connect the main feature to the process model (Figure 5.4) to see what project usefulness the different processes can lead to. A summary of the connection between Agile feature and the Scrum process is shown in table 6.1 78

Table 6.1 illustrates all the different features found in the Agile software development process and in the Scrum process and how they are connected to each other. This summary is based on figure 5.2. Table 6.1: Summary of Agile features connected to the Scrum process features Agile features Connected to Scrum process Customer collaboration and feedback is important in an Agile development project. Seeing change and responding to it is important in an Agile development project. Communication and interaction between the team and within the team is important in an Agile development project. Satisfying the customer through early and continuous delivery of software is important. Need from customer. Prioritise with customer Demo Release Product backlog Sprint backlog Daily Scrum Sprint Product backlog Sprint backlog Daily Scrum Retrospective Sprint Demo Changing requirement, even late in the project, is welcome to the project, but it must be controlled. Delivering working software as often as possible is important in Agile development projects. Face-to-face conversation is the best way to communicate in an Agile development project. Working software is the primary measure of progress. Reflecting over what is good, bad, how to respond to this and how to become more efficient is important for an Agile development project. Product backlog Sprint backlog Daily Scrum Retrospective Sprint The whole Scrum process The whole Scrum process Daily Scrum Retrospective The main question that our sub questions aim to answer is How is project usefulness connected to the Agile software development process?. By looking at what usefulness the different Agile features can result in discussed in chapter 5 and by then connecting the different features to the Scrum process model we have been able to identify which steps the Agile software development process that should lead to project usefulness. This is shown in figure 7.1. 79

7 Conclusion In this final chapter we will present the conclusions we could draw based on the empirical findings. Figure 7.1 illustrates how the different Scrum processes are connected to project usefulness. The different Scrum processes are in circled and numbered in order to illustrate which of the project usefulness they are connected to. Before Scrum Pregame Game Postgame Figure 7.1: Scrum features connection to project usefulness From Figure 7.1 we can see which steps in the Scrum process that should result in different project usefulness. As we can see from figure 7.1 there is a lot to gain for a software development company to use the Agile software development process. By using the different steps in the Scrum process a project can have a lot of usefulness gain that should give them a better end product, a happier customer and a better reputation on the market. Although the project needs a customer that is recipient to working in with the Agile software development process, to gain the full benefits of theses project usefulness. 80

With this study we have identified how the Scrum process is applied in practice, and which usefulness ought to emerge when applying this specific model. Unfortunately, we cannot make any generalisations with this model since only three companies were analysed. However, with this study we have tested our research model and seen that it is possible to find out how the Scrum process is used in practice and which usefulness that ought to emerge. Therefor we believe that our research model is a good start in the search for how to develop software with the use of Scrum processes and which usefulness this usage should give. 81

Appendix Interview guide in Swedish Frågor för intevjuguide Inledande text till intervjun, denna text kommer inte att finnas med på inspelningen: Vi är två studenter som kommer ifrån ekonomihögskolan och läser vår sista termin på magisterprogrammet, informatik. Vi har valt att skriva vår uppsats om agil projektmetodik med inriktning på Scrum. Vi är nu intresserade utav dina kunskaper utifrån ETT projekt som har bedrivits med denna metodik, Scrum. Går det bra att vi spelar in denna intervju? Intervjun kommer att gå till enligt följande: Vi har fyra olika olika teman som vi kommer att utgå ifrån. I varje tema finns x antal bestämda frågor som vi kommer att ställa. Då intervjun kommer att vara semistrukturerad kommer även följdfrågor att uppstå som inte finns med i intervjuguiden. Intervjun kommer att vara konfidentiell, varken ert eller ert företags namn kommer att finnas med i uppsatsen. Vi kommer även att censurera om ni skulle säga något som går att spåra till vilket företag ni arbetar på eller vem ni är. Ni kommer även att få möjligheten till att läsa igenom transkriberingen av intervjun innan den används i uppsatsen. Inledning (Dessa frågor ska endast ha korta svar och inte vara alltför detaljerade, bara för att komma igång och öppna upp.) Vad jobbar du med? (För att säkerställa vilken position informanten har i de projekt vi frågar om.) Hur länge har du arbetat på tidigare nämnd position? (Få en uppfattning av hur länge informanten jobbat med de han/hon talar om.) Var är det för typ av projekt som du kommer att prata utifrån, gällande Scrum/Agile? (För att säkerställa att det är mjukvaru utvecklings projekt informanten talar om.) Agile Vad är Agila utvecklingsprocesser för er, ge gärna exempel? (Denna fråga ställs för att få informantes syn på agila utvecklingsprocesser, vi kommer att utgå från Martin (2003), Highsmith & Fowler (2001), Ambler (2006) och Alleman s (2002) tolkningar av de Agila Manifestot värden och principer.) Hur länge har ni använt er av agila utvecklingsprocesser? Både på detta företag och företag som ni evetuellt arbetat på tidigare. (Denna frågan ställs för att få reda på hur lång erfarenhet företaget och informanten har av agila utvecklingsprocesser.) o Vilka agila metodiker har ni använt i utvecklingsprocessen? (Denna frågan ställs för att identifiera vilka agila metoder som använts utöver Scrum.) Om de använt mer än en typ, varför bytte de? (För att kunna se vad som kan ha varit bristfälligt i tidigare metodiker.) Scrum Hur länge har ni arbetat med Scrum? (Denna frågan ställs för att skapa en uppfattning av vilken erfarenhet informanten och företaget har av att arbeta med Scrum.) Varför valde ni att använda Scrum? (Dessa frågor ställs för att få veta om informanterna ser/såg några fördelar med att arbeta i Scrum för detta specifika projektet. Varför man valde att arbeta i Scrum kan också förklara om/varför Scrum passar i speciella projekt.) 82

o Fanns det några specifika förväntad fördelar? Fördelar (Dessa gäller mestadels för agilt, men vi anser att de är överförbara på Scrum.) Flexibilitet (Macheridis, 2009) Kundrelation (Martin, 2003; Schwaber, 1995) Skräddarsydd (Martin, 2003) Billigare (Anderson, 2004; Neill, 2003) Hur ser processen i projektet ut, i arbetet med Scrum? (Gärna rita en bild/modell) (För att kunna jämföra Abrahamsson et al., (2002)s modell så måste vi veta hur våra informanter arbetar i Scrum, hur processen och alla faser ser ut.) o I Pregame fasen o I Game fasen o I Postgame fasen (Dessa faser kommer ifrån (Abrahamsson, Ronkainen, Salo & Warsta, 2002; Schwaber, 1995) Vilka delmoment ser ni som mest kritisk för att ett utvecklings projekt skall lyckas? (Denna frågan ställs för att kunna precisera vilka delmoment i utvecklingsprocessen som är viktigast.) o Varför? (Motivering till åsikt.) Finns det delmoment som kan anses vara överflödiga i utvecklingsprocessen? (Denna frågan ställs för att identidera potentiella delmoment i utvecklingsprocessen som kan onödiga.) o Varför? (Motivering till åsikt.) Vilken är er erfarenhet av att arbeta med Scrum s utvecklings processer, finns det någon eller några aspekter du hade velat ändra på? (Denna frågan ställs för att få informanten att försöka utvärdera sitt eget arbete med Scrum s utvecklings processer.) o Positivt? o Negativt? Avslutning Finns det någonting ytterligare att berätta? (Denna frågan ställer vi för att försäkra oss om att vi inte har glömt något, även att vi verkligen får med allt som informanten anser är viktigt och/eller intressant.) o Något som vi har glömt att fråga om o Något som du känner är viktigt att lägga till 83

Interview guide in English Questions for the interview guide 4 An introductory text of the interview, this text will not appear on the recording: We are two students who comes from the School of Economics and are on our last semester at the Master's program, Informatics. We have chosen to write this thesis about Agile project methodology, focusing on a Scrum. We are now interested in your knowledge from a specific project that used this methodology, Scrum. Is it OK if we record this interview? We have four different themes that we will act upon. We have divided the interview into four different thee with a number of questions that we are going to talk about. The interview will be semi-structured, so there might be some follow-up questions that, which are not included in the interview guide. The interview will be confidential, neither you nor your company name will be included in the thesis. We will also censor if you would say something that can be traced to which company you work at or who you are. You will also have the opportunity to read the transcription of the interview before it is used in the thesis. Introduction What did/do you work with within this specific project? How long have you been working within this role? What type of project are you going to talk about, referring Agile/Scrum? Agile What is Agile development processes to you, what does it mean? Please give example How long have you been using Agile management methods? (Answer for both your and the company's experience.) o Which other methods have you, both the company and you as a person, used? (Both Agile and traditional) Why did you choose to switch from the methods you used before to Scrum? Scrum How long have you been working with Scrum? (Answer for both your and the company's experience.) Why did you/your company decide to choose Scrum? Were there any expected advantages? o Flexibility o Customer relationship o Customized o Cheaper What does the work within the project process, with Scrum, look like? ( In all phases) o Pregame o Game o Postgame 4 Why the questions are asked and how they are connected will not be presented in the English version of the Interview guide since it is told in the Method chapter, tables 3.1, 3.2, 3.3 and 3.4. 84

Which parts of the Scrum management process is the most critical? (Phases or parts that you cannot manage Scrum without.) o Why? Motivate Are there any part within Scrum that might feel unnecessary? (Phases or parts that you can manage Scrum without.) o Why? Motivate From your experience of working with Scrum, is there anything you want to change with the method? o Positive o Negative Closure Is there anything else you want to add to this interview? Anything we might have forgotten to ask you or just something you want to add. 85

Transcription 7.1.1 Interview A1 Rad nr 1. Q: Vad jobbar du som? Fråga/Svar 2. A1 - A: Just nu så jobbar jag som produkt ansvarig i ett team som håller på med kundorder system. 3. Q: Och i de Scrum projekt som du kommer tala utifrån, vilken roll hade du i det? 4. A1 - A: Då jobbade jag som leaddeveloper.. 5. Q: Hur länge har du arbetat i denna position? 6. A1 - A: I de projektet så arbetade jag 2 år, 7. Q: Har du någon tidigare erfarenhet av Scrum utöver detta projekt? 8. A1 - A: Nej, jag har varit utvecklare tidigare och blev sen leaddeveloper. 9. Q: Vad är det för typ av projekt som ni kommer tala utifrån? 10. A1 - A: Det är ett projekt med handlar om release hantering, vi hade fyra releaser årligen. (??) 11. Q: När vi säger Agila utvecklings processer, vad betyder de för dig och för projektet? 11. A1 - A: Kan du specificera lite? 12. Q: Vad var det som skilde detta arbetet med att jobba Agilt till skillnad från ert normala arbetsätt? 13. A1 - A: Det vi gjorde var att korta ner iterationerna, vi hade fyra veckors iterationer. Vi hade dagliga möten och planeringsmöten i början av varje sprint, demo i slutet på den. Vi delade upp alla ändringar i mindre tasks och varje medlem hade mindre tasks de kunde ta. Vi införde en tavla, Scrum board, där vi hade lappar som berättade vad alla gjorde. Vi testade, istället för vatten falls processen så testade vi hela tiden och kunde inkorporera changerequests, varje sprint avslutades med retrospecvive. Sen hade vi då fyra stycken release per år där så många som möjligt av de inblandade var närvarande. 12. Q: Just i detta projekt, vem agerade beställare? 13. A1 - A: Ja där var det inte helt klockrent eftersom vi hade svårt att träffa dem som verkligen beställde systemet.tilllägg: I detta fall fick vi en produkt ansvarig som fick agera beställare då beställaren fysiskt satt nere i ett annat land. Vår befintliga produkt ansvarige fick ta på sig rollen som productowner. Han diskuterade sen vilka ändringar vår beställarer verkligen ville göra och hade en product backlog, en lista med alla ändringar (CR; PR, ER) i prio ordning. Koppling till teoretiska ramverket Av&p, Sdp Av&p, U 86

14. Q: Så mellan kunden och er fanns det inte något kontakt eller hur såg detta ut? 15. A1 - A: Ja..Tilllägg: Vår kontakt med kunden/beställaren var via produkt ansvarige. Dessutom diskuterade vår Business Analyst och Solution Architect krav mm i resp CR/PR/ER direkt med beställaren. Test Manager diskuterade testfrågor och under BAT (Business Acceptance Test) testade beställaren av releasen. Jag som Scrum Master hade bara lite kontakt med beställaren. 16. Q: Vi testningen till exempel hur gjorde ni då? 87 Av&p, U 17. A1 - A: Vi hade återkommande kontakt vid de olika releaserna. Sdp, U 18. Q: Var beställaren med under de dagliga Scrum möten? 19. A1 - A: Nej, i och med att kunden, de som verkligen beställde inte med. De var inte alls inblandade skulle jag vilja säg. 20. Q: Fanns det någon anledning till det? 21. A1 - A: Anledningen är att de satt så fysiskt långt borta och att de inte skulle haft tid helt enkelt. 22. Q: Kände ni att ni hade behov att en kundkontakt? Av&p, Sdp, U Av&p, U 23. A1 - A: Absolut, det hade underlättat mycket. Av&p, U 24. Q: Vad berodde det på att beställaren inte var närvarande? 25. A1 - A: Ja de är många saker faktiskt, kunskap kanske om hur Scrum fungerade och varför de fanns ett behov av att ha med dem och så som de såg ut då så hade det bara blivit en belastning i deras arbete. 26. Q: Så de var inte med trots eget intresse? 27: A1 - A: Jag tror faktiskt att vi ställde frågan till dem, men de var vår slutsats att de inte vilje eller kunna vara med. 28. Q: Så hur länge har ni använt er av Agila utvecklings processer? 29. A1 - A: Vi började 2007. 30. Q: Började ni arbeta med Scrum direkt eller använde ni några andra metodiker? 31. A1 - A: Nej vi körde Scrum direkt, vi hade en coach som vi hade diskussioner med innan vi började införa detta sätt att arbeta på. Dock så blev de att mergade mellan tidigare metodiker och Scrum för att hitta nåt som funkade och vissa projekt kunde man inte använda 100%Scrum i. (Anledningen till att vi inte kunde köra 100% Scrum var dels att vi var tvungna att anpassa oss efter resten av företaget, t ex vad gäller testmiljöer som vi inte hade tillgång till hela tiden mm, dels för att vi valde att göra vissa anpassningar som vi tyckte passade oss. Vi ville inte vara bundna till en metod, utan kunna välja att göra som vi tyckte var bäst för oss just då.) 32. Q: Vad finns det för exempel på projekt där ni inte kunnat använda Scrum? 33. A1 - A: Ja när vi tillexempel inte haft kunden nära nog för att kunna ha en kontakt med den, vi kanske vill göra tester i varje sprint men ibland kan man bara göra de i slutet av projektet. 34. Q: Vad använde ni för metodiker innan ni började använda Agila metodiker? 35. A1 - A: Då använde vi vattenfall. 36. Q: Fanns det någon generell anledning till bytet? 37. A1 - A: Nej de var inget generellt byta på företaget utan de var vi själva som valde att jobba med Scrum. Vi kom fram till att det här (Vattenfalls metodik) går inte så bra Av&p, Sdp, U Av&p

38. Q: Vad var det som inte fungerade? 39. A1 - A: Det kändes som att utvecklaren fick sitta helt själv utan någon som frågade hur de går eller om han behövde hjälp. Men Scrum kan man mer hjälpas åt och se vad alla just nu jobbar med. 40. Q: Varför valde ni att använda just Scrum? 41. A1 - A: De var helt enkelt så att vi hade varit och lyssnat på föreläsningar om det och blev inspirerade. 42. Q: Vad för typ av inspiration? Såg du fördelar? 43. A1 - A: Nej man såg alla de visade fördelarna, bättre koll, man jobbar tillsammans, korta iterationer och kunde leverera mer. 44. Q: Upplever ni att ni blir flexiblare i ert arbete? 45. A1 - A: Ja absolut, innan hade vi ju några veckor för att planera och bestämma innan vi började utveckla och då blev de svårare att anpassa sig till ändringar. Nu kör vi fortfarande planering innan, men är det någonting så är det mycket lättare att ändra planerna. 46. Q: Upplevde ni att ni förbättrade er kundrelation med Agila metodiker? 47. A1 - A: Nej faktiskt inte, men vi utnyttjade inte det tillräckligt mycket heller på grund av beställaren fysisk position. 48. Q: Känner ni att ni har blivit bättre på att skräddarsy lösningar åt beställaren? 88 Av&p, U Av&p, U Av&p, U Av&p, U 49. A1 - A: Nej, inte generellt. Av&p, U 50. Q: Upplever ni att utvecklingen blir billigare med Agila metodiker? 51. A1 - A: Ja de tror jag, då vi levererar mer men det är mer en känsla. Av&p,U 52. Q: Hur ser ert arbete med Agila projekt ut? 53. A1 - A: Vi börjar med en sprint planering innan första sprinten, denna tar kanske en halv dag där vi också kan ha en arkitekt som berättar vad de är vi skall göra och sen hjälps teamet åt att bryta ner det i aktiviteter och sätta timmar på varje aktivitet. Detta görs då dag ett, sen har vi dailyscrum varje dag på en kvart ungefär där alla står upp kring tavlan. Sen har vi demon nästa sista dan på sprinten då alla som är intresserade att närvara kan vara det och sen har vi retro sista dagen med teamet, där vi går igenom vad som varit bra och dåligt och vilka förbättringar vi vill göra till nästa sprint. Och så rullar de på med fyra sprintrar per release. 54. Q: Av dessa moment och faser, vilka ser du som mest kritiska för att projektet skall lyckas? 55. A1 - A: Sprint planeringen är avgörande, är den inte bra då vet inte utvecklarna vad och hur de skall göra. 56. Q: Kan du ge exempel på misslyckad sprint planering? 57. A1 - A: För kort genomgång om vad specifikationerna faktiskt handlar om och vad som behövs och de resulterar i att allting tar mycket längre tid om utvecklare och testare skall behöva sitta och jobba med detta istället för att prata med arkitekten som har en helhetsbild. 58. Q: Finns de något moment som känns överflödigt? 59. A1 - A: Nej, vi har ju gjort förändringar hela tiden, börjat med något och testa för att finslipa hur vi arbetar efter hand som vi arbetar. 60. Q: Vad var de mer konkret som ni ändrade? 61. A1 - A: Små grejer, som att stå upp under dailyscrum och att möten skulle Sdp Av&p, Sdp Av&p, Sdp Av&p, Sdp

hålla sig till de tre frågorna. (Vad gjorde jag igår, vad gör jag idag, har jag några problem?) 62. Q: Utifrån din erfarenhet av Scrum finns det något du hade velat lägga till eller ta bort i er Agila process? 63. A1 - A: Nej, egentligen inte jag tycker att det funkar bra. Ända skulle väl vara att ha bättre beställare kontakt än vad vi hade. 64. Q: Finns de något övrigt du skulle vilja lägga till? 65. A1 - A: Nej. 66. Sekreteraren ställer följdfråga1 - A: 67. Q: Backlogg, hur har ni prioriterat i den? 68. A1 - A: Vi tog in det som vi vet, vad beställaren vill ha. En del fick de vara med och prioritera men de var ändå vi i slutändan som tillsammans med produktansvarige som skötte prioriteringen. Sen hade vi ju en sprint backlogg också, för att prioritera för varje sprint. Men vi kände att ha dubbla backloggar var ett bra verktyg för att sedan kunna följa upp arbetet och ha kontroll över det. Tavlan var ju främst för utvecklarna som arbetade dagligen med det och Scrum mastern och andra kunde titta på backloggarna för att följa arbetet. Av&p, Sdp, U 69. Q: Vem bestämde vem som skulle göra de olika uppgifterna? Av&p, Sdp 70. A1 - A: De skulle man göra själv, men man var tvungen att kontrollera så de hade avslutat en uppgift innan de gick på nästa. Och kontrollera att de dokumenterade. Ibland blev de så att utvecklarna bara tog de som de tyckte var roligt, vilket kunde leda till att uppgifter som hade hög prioritet ändå inte blev tidigt gjorda. 71. Q: Hur ser arbetet ut mer dokumentationen? 72. A1 - A: Vi gjorde bara den nödvändiga dokumentationen, arkitekten kontrollerar detta. Vi gjorde samma dokumentation när vi arbetade med vattenfall som med Scrum. Att vi gick över till scrum påverkade inte mängden dokument. Sdp Av&p, Sdp 7.1.2 Interview A2 Rad # Question/Answer 1 Q: Kan du beskriva vad du jobbade med inom X projektet? 2 A2 - A: Jag var i huvudsak Business Analyst, som ska ta reda på vad som ska utvecklas. Vad det är som ska utvecklas och inte hur det ska utvecklas. Exempelvis förklara för utvecklarna vad det är som ska utvecklas, och även se till att de som testar har rätt saker. 3 Q: Hur länge har du arbetat med den uppgiften? 4 A2 - A: Drygt tre år, och innan dess satt jag på förvaltningen. 5 Q: Under detta X projektet har ni använt några andra metodiker? Koppling till teoretiska ramverket 89

6 A2 - A: Vi använde Scrum under sista året innan dess var det halvorganiserad RUP [Rational Unified Process (RUP) är en systemutvecklingsprocess för design och implementering av IT-system.] 7 Q: Hur ser du på den agila processmetoden? Förklara den gärna med egna ord. 8 A2 - A: Idealet är att man har små eller kortare projekt med ganska tydliga ramar, för annars blir det väldigt krångligt. Exempelvis, om man har väldigt många involverade och inte så tydliga ramar bli det väldigt krångligt. Men vi hade en väldigt inarbetad grupp som i huvudsak arbetade med förvaltningen i projekt som mötte just den förvaltningen, vilket innebar att vi hade dels förbättringar som kom löpande och dels saker som var projektstyrda. Det fungerade väldigt bra att man hade båda två delarna i Scrum under fyra veckor, att man lägger in sakerna i prioritetsordning från båda i sprinten, två projekt och två förvaltning som båda löpte parallellt. Jag tyckte att detta fungerade väldigt bra, framförallt vad det väldigt roligt att arbeta med Scrum. Man kommer väldigt nära varandra i gruppen och får ett bättre samarbete i gruppen. 9 Q: Hur länge använde ni denna agila metod [Scrum]? 10 A2 - A: Jag var med i ungefär ett år, sen lämnade jag den gruppen, men de fortsatte att arbeta med den metoden. I ungefär sex månader till [efter att hon lämnat just den gruppen] så var jag aktivitetsledare för ett projekt 11 Q: Innan dess, har du haft någon erfarenhet av de agila metoderna? 12 A2 - A: Nej, det kan jag inte påstå. Det har mer varit vattenfall och ad hoc. 13 Q: Vad innebär aktivitetsledare, vad är det man gör som en aktivitetsledare? 14 A2 - A: En aktivitetsledare skulle man kunna säga är en mini projektledare. Du har samma uppgifter som en projektledare, men hela projektets budget styrs från den "riktiga" projektledaren. Man skulle även kunna jämföra med en delprojektledare. Huvudprojektet låg för ALLA applikationer på hela företaget, ett delprojekt låg på supplying, aktiviteter mot och applikationerna däri. Det var den här biten som jag var ansvarig för. 15 Q: Vet du varför man bytte från de här tidigare metodikerna och valde Scrum? Var det något som inte fungerade tidigare med de traditionella metoderna? 16 A2 - A: Man ville korta ner ledtiderna, exempel korta tid från change request till change. Och försöka få det på ett smidigt sätt, men ändå inte bryta mot företagets regelverk. 17 Q: Och som du sa, du har själv arbetat agilt i ungefär ett till ett och ett halvt år? 18 A2 - A: Ja, precis, jag själv har gjort det. 19 Q: Kände ledningen att Scrum gav dem de fördelarna, som du berättade om kortare ledtider? Och vad var det mer som gjorde att man valde att arbeta med Scrum? 20 A2 - A: När vi började med det så var det en stor kampanj, och man tyckte att det här var en bra metod. Vi hade också ganska mycket utbildning och även process coacher som kom och berättade för oss hur det gick till och gjorde reklam för detta sätt. Men var det var som gjorde att vi i gruppen fortsatte med denna metod var ju framförallt för att samarbetet och arbetsmiljön blev så mycket bättre i gruppen och man hade roligare. Man får bättre kontroll på vad som hinns med i hela gruppen... 21 Q: Kan du ge exempel på vad detta kan vara, i förhållande till hur det var tidigare? Av&p, Sdp, U Av&p, Sdp Av&p, Sdp, U Av&p, U 90

22 A2 - A: Tidigare så kunde man ge en uppgift till en av utvecklarna, och så har han kvar den uppgiften i tre månader. Under den tiden så vet man inte alls var han är på väg eller hur långt han har kommit med uppgiften. Och samtidigt så hade du arkitekten som satt och försökte få till olika arkitekturer/arkitektoniska modeller och pratade om planeringar som låg ett år framåt i tiden. Det kom inte heller tillbaka till gruppen. Och så satt jag som business analyst med mina grejer och förvaltningen med sina grejer och produktansvarig bestämde att det här ska göras inom tre månader. Man delade alltså ut uppgifterna och så satt var och en och jobbade med sitt. Men med Scrum så träffades man på möte varje dag och berättade: "Jag håller på med det här", "Jag är färdig med det här" osv. Det betydde att man kom fram till att nu har vi gjort de här sakerna, och nu ska vi göra de här sakerna. Det blev alltså betydligt bättre sammanhållning och det blev roligare att arbeta helt enkelt. 23 Q: Denna uppsats syftar dels till att titta på de fördelar som man får genom att arbeta med Scrum och dels de nackdelar man får samt processer, hur man arbetar med Scrum. Känner du att ni när ni arbetade blev mer flexibla, fick mer flexibilitet med denna metodik? 24 A2 - A: Mer kontrollerad flexibla, skulle jag vilja säga. Detta företaget är en väldigt stor organisation, och det kommer alltid in saker ifrån sidan som bara måste göras. Istället för att antingen säga att " Vi göra detta om tre veckor" eller behöva släppa allt och egentligen inte ens ha riktigt koll på hur det ska se ut kan vi nu helt enkelt bara säga att vi påbörjar denna uppgiften i nästa sprint, och då blir det klart i slutet på den sprinten. 25 Q: Och förändringarna inom projektet, känner ni att ni har kunnat hantera dem på ett bättre sätt? 26 A2 - A: Det kommer väldigt mycket utifrån och var tvungna att helt enkelt få någon struktur på det hela. Vi fick inte mer flexibilitet, utan med kontrollerad flexibilitet som jag sa. Vi kunde helt enkelt tid boxa det som kom ifrån sidan, och vänta lite med de sakerna. 27 Q: Du pratade lite om att ni fick bättre relationer till varandra inom gruppen, kände du att ni fick en bättre relation till kunden eller beställaren i detta fallet? 28 A2 - A: Vi hade ganska bra kontakt med våra användare ändå, och product ownern i vår Scrum-grupp var snarare product ansvarig på IT-avdelningen, så det var inte någon från användarsidan. Men detta beror på hur våran koncern är uppbyggd, och att våra användare sitter i ett annat land, vilket är lite snörpet. Så att IT-ansvarige [personen som fick bli product owner] åkte till detta land för att prata med användarna [de riktiga produkt ägarna] och gick igenom prioritetslistan. 29 Q: Kände ni att ni fick en mer skräddarsydd lösning till beställaren med denna metod [Scrum]? 30 A2 - A: Njaaa, det har vi alltid varit väldigt noga med redan innan. Jag kan inte säga att det var någon större skillnad på den fronten. Av&p, Sdp, U Av&p, Sdp, U Av&p, Sdp, U U 31 Q: Rent kostnadsmässigt, är det en billigare metodik att använda? 32 A2 - A: Det har jag ingen koll på. Av&p, Sdp, U 33 Q: Ingen generell känsla? 34 A2 - A: Man känner ju att det blir effektivare. Genom att man på kortare tid får koncentrera sig på bara en sak, istället för att släppa och plocka upp något nytt, sen släppa och plocka upp något nytt. Och på det sättet så känns det ju faktiskt effektivare. Av&p, Sdp, U 91

35 Q: När ni arbetar med specifikt Scrum, hur ser arbetet ut? Exempelvis olika delmoment ni har, planering osv Rita upp en bild a hur det ser ut hos er. 36 A2 - A: Om vi säger så här, så börjar det med att användarna uttrycker ett behov, antingen att det är ett problem de har eller en förändring som de vill ska göras. Innan man överhuvudtaget startar sin Scrum så finns det en del grejer som man måste veta. Man måste veta ungefär hur stort projektet, eller ändringen, kommer att vara, och man måste veta om det finns några beroenden utanför, och man måste veta grund iden. Det här blir till två olika listor, en lista med krav/beställningar som är grund analyserat och en lista som består av krav/beställningar som är färdig analyserat. Så få man göra prioriteringslistan med användarna. 37 Q: Det här listorna, är det backlogs? 38 A2 - A: Det som kommer ut efter att man har varit på det här mötet med användarna Efter att man har grund analyserat och då gått vidare och gjort djupare analys, tillsammans med användarna, och sen får man backlogen som är grunden för sprinten. Vi gjorde som så att vi hade ett möte där scrum mastern berättade vad som skulle göras för utvecklarna, och detta möte leddes utav scrum mastern. Utifrån detta möte fördelade man alla uppgifter till mindre tasks, detta för att klara av dem. Exempelvis för att utföra denna uppgift så måste vi dela upp den i detta och detta och detta momentet [dessa som moment blev alltså de som kallas för mindre tasks]. Vi hade dessutom en ganska grov bild av vad "done" skulle vara. Definition av "done" är något som är väldigt viktigt. Exempelvis hur specifikt och hur mycket som skulle dokumenteras... För att göra det tydligare, först har man "önskelistan" dvs Change request och projektuppgifter som skall göras ofta har de "önskat färdigt datum" så man vet vad som är bråttom. Sen görs en grundanalys där man bl.a. värderar hur stor vare grej är. Den "Analyserade grejer" listan tar man med till möte med användare och går igenom gemensamt för att prioritera, sen har man sin "Scrum" backlog. 39 Q: Hur mycket var det som dokumenterades, och hur specifikt var det? 40 A2 - A: Det skulle åtminstone finnas en beskrivning på lösningen och innehåll av tools 41 Q: Hur såg era möten ut? Hade ni dagliga möten? 42 A: Det här var en liten form av Scrum planing, och då kollar man upp så att man får fram alla tasks. Så sätter man upp dessa tasks i en ordning på tavlan [en fysisk tavla]. Varje dag så hade man de här fem minuters Scrum mötena, detta var möten på fem minuter ståendes vid tavlan där vi skulle svara på de tre frågorna. Vi fick ett antal gånger säga till varandra att nu går vi tillbaka till de tre frågorna som vi skulle svara på, då att det tenderade till att dessa mötena blev lite längre än vad de borde vara. Vi fick vara väldigt noga med att vi svarade på de tre frågorna och allt annat fick tas efteråt. 43 Q: Vilka är de tre frågorna? 44 A: De tre frågorna är: Vad gjorde du igår? Vad ska du göra idag? Och har du några problem? 45 Q: Och höll detta på under hela processen? 46 A2 - A: Ja, varje dag under hela processen. 47 Q: Hur gjorde ni med testningen? Av&p, Sdp Av&p, Sdp Av&p Av&p, Sdp 92

48 A2 - A: Vi körde normalt sett testningen parallellt, men ibland gjorde vi så att om vi hade större grejer vi hade gjort så hade vi även hela sprintar som vi bara testade i. Men annars är det här något som bestäms av definition done, hur det ska se ut med testningen. 49 Q: Och testningen, när är den "done"? Var det färdigt att visas för kunden då, eller har kunden redan fått se, känna, och ge sin åsikt om det? 50 A2 - A: Normalt sett så har vi inte det så. Säg att vi körde tre till fyra sprintar sen test. Vi visade inte någon demo för kunden under tiden, och de berodde på att kunden inte var nära oss [sitter i ett annat land], och då får man anpassa sig till det. Sdp Sdp 51 Q: Du sa att ni körde tre till fyra sprintar sen körde test och sedan fick ut en demo, hur lång tid och hur många sprintar fanns det med över överhuvudtaget? 52 A2 - A: Jag kan inte riktigt komma ihåg men, vi hade väl tre till fyra stora releaser per år och det var tre stycken 4 veckors sprintar per release ungefär. Sdp 53 Q: Under de här delmomenten som du har beskrivit, vilken del tycker du är mest kritisk för att det ska fungera? 54 A2 - A: Jaaa, det här va ju en. Det är ju klart att jag tycker att det jag gör är absolut viktigast, att man vet vad som ska göras, och att utvecklarna frågar om det är något de inte förstår. Och möjligheten till att fråga har man hela tiden. Jag som business analyst var mer som support till gruppen snarare än som medlem i den. Detta innebar att jag kodade inte själv och testade inte själv heller utan jag fanns där för att dels förbereda och dels för att svara på de frågor som fanns... 55 Q: Fanns det något specifikt i Scrum som du känner var extra viktigt, det här måste man ha med för att Scrum-metoden ska bli bra? Exempelvis de dagliga mötena, eller att man hade en fysisk tavla där alla uppgifter fanns. 56 A2 - A: Definition av vad done är, man måste veta vad man anser är klart. Det ska även finnas check listor som beskriver vad som är klart. Exempelvis, för att den här grejen ska anses vad klar krävs det här, det här och det här Sdp Sdp 57 Q: Fanns det något i Scrum-processen som kan anses vara överflödig? 58 A: Nej, jag tycker faktiskt inte det. Jag tycker faktiskt att det mesta i själva metodiken är väldigt vettig. Jag hade dock önskat att vi hade haft fler användare på plats, men det hade vi tyvärr ingen möjlighet till. Exempelvis så hade vi velat kunna visa upp varje sprint för sig, en demo till varje sprint, förklara hur hårdvaran fungerar och vara lite mer flexibilitet när det gäller detta osv. 59 Q: Men har flexibiliteten mer att göra med hur själv företaget är utbyggt eller? 60 A2 - A: Ja, precis. Det har att göra mer med hur själva företaget är uppbyggt med sina regelverk osv än med själva Scrum-metodiken. Av&p, Sdp, U Av&p, Sdp, U 61 Q: Det här projektet som vi pratar om, är det ett projekt som företaget tittar tillbaka på och är nöjda med? 62 A2 - A: Ja. Detta projektet har dels varit löpande i och med förvaltningen men dels har det varit levererat till delar av diverse större projekt. Och vad jag vet så har denna gruppen i detta projektet aldrig ansetts vara någon flaskhals. 63 Q: Om vi tittar på Scrum i stort, och inte bara på Scrum i detta projektet. Om vi ser till din erfarenhet av denna metodik, finns det någonting du hade velat ändra på, både positivt och negativt? Finns det någonting du hade velat lägga till, eller ta bort? 93

64 A2 - A: I Scrum-metodiken så ingår ju inte det här dels hur du ska sköta analys innan, i Scrum ska du ju göra analysen som en del av planeringen. Och för det mesta i större projekt är detta inte möjligt, utan det måste ske i förväg. Iden med Agile är ju gör så lite som möjligt, men du måste ändå göra någon slags exempel dokumentation, man måste ha mer dokumentation... och detta måste då finnas med i definition av done, hur mycket dokumentation som ska göras, hur mycket som egentligen behövs. 65 Q: Gör dom dokumentationen, eller det är något som ni måste ligga på utvecklarna på? 66 A2 - A: Ne, jag tycker att det fungerar hyffsat bra. Men det är alltid något som man behöver hålla lite koll på. 67 Q: När bestäms vad definitionen av done ska vara? 68 A: Den bestäms ju innan man ens har börjat arbeta med Scrum. Under samma möte som man bestämmer sig för att arbeta med Scrum så får man också bestämma vad är det för krav vill vi ha för att något ska anses vara klart. Och sen får man fortsätta med detta under varje utvärdering, att man hela tiden förbättrar vad done är, har det här fungerat eller är det något annat mer eller mindre vi behöver ha med i definitionen av done? Lägga till eller ta bort från check-listan. 69 Q: Men är det här något generellt sett som inte finns med i Scrum? 70 A: Nej det här är en del av det agila arbetssättet, men måste veta när man är klar. 71 Q: Vi frågade dig innan om det var något du ville ändra eller ta bort Finns det någon del som känns överflödig? Av&p, Sdp Av&p, Sdp 72 A: Nä, jag tycker inte det. Även om det då och då kan kännas som det blir lite väl många möten och att det ibland inte kändes nödvändigt att berätta var man låg. Men det var ändå viktigt att träffas för gemenskapen och se hur det fick för hela gruppen, se hur hela gruppen låg till, så att vi själva visste vad alla hade gjort. Och uppföljningen vad bra för att man faktiskt har en chans att säga sitt, exempelvis nu blev det så här och så här, vi behöver bättre analys innan... 73 Q: Finns det ytterligare något som du skulle vilja lägga till, eller ta upp innan vi avslutar? 74 A: Något som man måste hålla väldigt väldigt hårt i är sprintplaneringarna, för att de kan bli hysteriskt långa om inte någon säger till. 75 Q: Har du något exempel på både bra och dålig sprintplanering? 76 A: Vi hade en gång ett sprintplanerings möte som varade i åtta timmar. Och det beror väl dels på att man inte har definitionen av done med i listan och då måste man hitta på den under tiden. Om man har en checklista på vad som ska anses vad done är så säger man att för att den här grejen ska vara done ska det här och det här vara uppfyllt. Och behöver jag alla dessa tasken för den här uppgiften, eller är det någon som vi kan hoppa över... 77 Q: Men tillhör inte det sprint backlogen, att man planerar vad som ska göras för varje sprint? 78 A: I sprint backlogen så har du ju olika features eller olika CR, change requests Vad innebär det här för sprint planeringen, vilka uppgifter innehåller den här featuren? För att få hela featuren klart vilket x timmar finns att göra?. Det är väldigt svårt att anpassa en sån här väldigt stor organisation... 79 Q: Men om man tittar på outsourcing, hur löser ni det här med att jobba med Scrum i Av&p, Sdp Sdp 94

outsourcing-projekt? 80 A: Jag försvann i gruppen precis i samband med det här, att man började med outsourcing. Jag vet inte. Men det är ju väldigt svårt att ha sina dagliga Scrum möten 81 Q: En sista fråga, hur gör man prioriteringen för vad som ska prioriteras högst i backlogarna? När gör man den prioriteringen? 82 A: Det gör man definitivt tillsammans med användarna 83 Q: Och hur löste ni det, i och med att era användare inte kunde närvara och sitter i ett annat land? 84 A: Vår produktansvarig fick antingen åka ner till dem ungefär en gång i månaden, men oftast tror jag att de hade möte via netmeetings. 85 Q: Ja, då är vi klara med våra frågor. Tack så mycket för att ni ville vara med. 86 A: Tack själv. 7.1.3 Interview B1 Row # Question/Answer 1 Q: Skulle du vilja börja med att berätta vilken roll du hade i detta projektet som vi kommer att prata om? Vilka var dina arbetsuppgifter? Koppling till teoretiska ramverket 2 B1 - A: I det här projektet så arbetade jag med ett företag som är ett web Community. [informanten berättar mer om vilket företag det är, dock är detta censurerat då denna förklaring kan avslöja vilket företag informanten arbetade åt.] Jag har jobbat med detta företag ganska mycket i flera olika sammanhang, och för några år sedan så gick vi in för att hjälpa dem lite allmänt med deras utvecklingsmetodik. Sen var det så att deras projektledare inte hade så mycket erfarenhet och då fick jag ta den rollen. Och om man ska definiera den kontexten så handlade det om att titta på deras projektportföljer, lite mer programorienterat. De hade en massa olika små projekt som kom in, alltså väldigt små projekt. Något som är väldigt utmärkande för denna branschen, media och web, är att det är väldigt snabbfotat och väldigt korta cykler. Det var en massa små projekt som deras försäljningsgrupp i Stockholm sålde in. Innan vi kom på plats så hade de sålt till X, vilket betyder att detta företaget ägdes utav X som även ägde ett annat företagsmärke. Så att företag X försökte få så att de här två varumärkena gynnade varandra på bästa sätt. Min roll här var alltså att titta på deras metodik för att få dem så att de kunde leverera på alla dessa små projekten... Så jag var väldigt mycket spindeln i nätet, jobbade mot säljarna och få dem att försöka förstå processen, och dels jobba mot de olika projektledarna som höll i de olika små projekten. Detta företaget fanns ju i Danmark Norge och i Sverige och så hade de lokal närvaro i Stockholm, och det var ju olika projektledare som drev olika projekt. Typisk projektledning handlade om att man jobbade mot ett annat stort märke som ville ha någon slags marknadsföring och då gjorde man någon speciell funktionalitet för detta på Community. Det var mycket kampanjer, men även ny funktionalitet. 3 Q: Om du skulle sammanfatta din roll med ett ord eller en mening, vad skulle du kalla den då? 95 Av&p, Sdp, U

4 B1 - A: Inte Scrum-master och knappt projektledare egentligen Möjligen produktionsledare kanske 5 Q: När du jobbade med det här projektet, hur lång tid drog det ut på tiden? 6 B1 - A: Vi började på hösten, september/oktober år 2007 och jobbade nästan fram till sommaren, maj/juni. 7 Q: Har du haft denna positionen tidigare, eller det är en ny erfarenhet för dig? 8 B1 - A: Ja, jag har haft den här rollen tidigare i ett annat företag. Om jag ska vara helt ärlig så är det lite mer linje orienterat 9 Q: men just i detta projektet så använde ni er utav Scrum? 10 B1 - A: Ja, absolut 11 Q: När vi säger agil utvecklingsmetodik, agil utvecklingsprocesser, vad är det för dig? 12 B1 - A: Det är ju rätt mycket men att jobba i ett projekt där man har ett bra förtroende till kunden, som man ska leverera till då, för att titta på vad som ger mest värde för kunden, kunna omvärdera planen. Alltså kontinuerligt omvärdera planen, och se till att man hela tiden kopplar tillbaka/itererar till planen och inte lämnar den. 13 Q: Har ni använt någon annan typ av agil utvecklingsmetod, förutom Scrum? B1 - A: Av min erfarenhet från 90-talet och framåt har det varit mycket RUP [Rational Unified Process (RUP) är en systemutvecklingsprocess för design och implementering av IT-system.] Jag har även kommit lite i kontakt med PROPS [] och även några andra mindre., RUP och PROPS är ju ganska stora. 14 Q: Är det som företaget generellt har bytt sätt, eller det har fallit sig naturligt att använda sig av en viss typ? 16 B1 - A: Nu har jag inte jobbat så länge på detta företaget men det jag vet är att det inte finns någon metod som ersätter den andra, utan man använder båda två. Exempelvis så har vi kört en del agilt under hösten men har nu fått en kund där det inte fungerar. Det är en kund som har haft mycket problem med vad de behöver, och de behöver mycket stöd i förankringsarbetet. Vi är inte där i utvecklingen att vi kan köra Scrum och då väljer man RUP. Så att så är det som det ser ut, det beror mycket på vilka förutsättningar man har. 17 Q: Vad var det som gjorde att man valde att gå över till det agila sättet, fanns det något bristfälligt med den traditionella sättet? 18 B1 - A: Om jag tittar på det här projektet som vi pratar utifrån då skulle de skala upp sin utveckling och då hade de drivit det här ett tag och de var inte så många, ett par tre utvecklare bara. Men så skulle de skala upp och anställa nya och de behövde alltså ett sätt att kunna hantera den volymen. Då gick man ifrån ett inte så strukturerat arbetssätt och då skulle man börja jobba på ett mer strukturerat sätt. Det fanns helt enkelt alla förutsättningar. Så det var ett väldigt enkelt val i det fallet. Av&p, U 96

19 Q: Men då kanske man kan säga att det inte fanns någon historia av misslyckande, utan att man mer såg fördelarna med detta arbetssätt. Och vad var det då för fördelar som man såg? 20 B1 - A: De hade alltså en massa små projekt och ville ha en gemensam plattform. Och i och med att jag har arbetat med dem tidigare så vet jag att man tenderar att sitta och designa för länge, och man kommer inte loss från det. Och det är precis det agil säljer på. [att man inte kan sitta ner och designa för länge, utan att man måste gå vidare i processen hela tiden.] Vi hade kört RUP på projekt innan, och man trodde på den tiden att det säkert var jag som gjorde fel, att man inte kunde denna modellen. Men någonstans efter det så känner man att nu har vi kört den här modellen, och vi borde kunna den, men det fungerar inte. 21 Q: Känner du att man får mer flexibilitet inom projektet med Scrum? Av&p, U 22 B1 - A: njaa Ibland kan det vara lite svårt med agil metodik. Och då skulle jag vilja gå tillbaka till den där frågan om vad agilt är för mig. Agil metodik är ju en stor verktygslåda, och i den här verktygslådan finns det en del som inte härar till kärnan, en del som man kan köra utan. Det är något som är väldigt svårt att bedöma innan man har kört det länge. När man har kört en metodik länge så märker man att den här grejen kan vi köra utan och det är ju en jättefördel. Vad agilt gör är att den trycker ner iterations längden, man får en möjlighet i och med att man arbetar på ett annat sätt, att korta ner cykel tiderna. Man tar bort en massa overhead, om man känner att det här klarar vi oss utan och så tar man bort det... Det gör att man hela tiden står klar med hur det är som produkten ser ut just nu. Det gör ju att man aldrig fastnar i: "Kommer det här funka?" "Hur ser det ut"?. I agilt är de också väldigt tydligt med hur, inte bara med att man ska ha ett dokument, utan även hur det ska se ut. Eller vi ska ha ett möte och det strukturerar vi upp på det här viset, inte bara att vi ska ha ett möte. Ett exempel på detta är retroperspektivt [går tillbaka och kollar hur det har gått], detta är ett sätt att försöka hålla lågan vid liv och hålla uppe produktiviteten även i tider då man stöter på motgångar. Man kan gå in på ett retroperspektivt möte med en massa tankar om att det här inte gick bra och sen kommer man ut från retroperspektivt och tänker: "wow, nu kör vi". och det är något som jag inte har lyckats komma i närheten av att åstadkomma i något annat projekt. Så där har ni några exempel... 23 Q: Kundrelationer, är det något som du känner att ni genom att använda Scrum har fått bättre kundrelationer? 24 B1 - A: Absolut, det är ju så att genom kortare cykeltider får tätare avstämningar med kund. Och ja, det är ju en jättestor skillnad. Det gör också att man utvecklar relationen snabbare, du blir tvungen att jobba med kunden. I traditionell metodik kan det också vara så att det är en lite trevande relation, men i agil metodik så tvingar man sig lite in i en situation och säger nu kör vi. Och det behöver man ofta 25 Q: Den här relationen som då skapas, gör den att ni kan göra en mer skräddarsydd lösning? Av&p, Sdp, U Av&p, U 97

26 B1 - A: Ja, absolut. Dels är det så att kunden inte blir lika rädd. När man använder sig av agilmetodik så är det change for free. I äldre modeller så planerar du och sen ser du att det finns en kostnad med förväntningar. Agilt har det här "Alltid redo" perspektivet. Man lägger inte ner mycket tid på att titta i framtiden utan fokuserar mer på att alltid vara redo, vilket gör att man gemensamt tar beslutet om förändring. [beslut om förändring tas då alltså av både kund och leverantör tillsammans]. Vilket gör att man inte har att för varje change request så kommer detta att kosta. Vilket var exakt så jag jobbade när vi använde RUP tidigare, vad kommer det här att kosta för att det är förändringar. Det spelade ingen roll om det var förändringar, för att alla förändringar kommer att kosta. Bara att genomföra förändringarna kostade, det här kommer att kosta att strukturera och planera om... men det fungerar inte så i agilt. Utan här bygger man förtroende och man bygger relationerna gemensamt kan vi säga. Vilket gör att kunden får ett förtroende för oss om att det är okey att komma med förändringar. I det andra, gamla sättet, så förstod man att så fort kunden ville ha något annat så var vi i förhandlingssituation. Med den agila sättet så försöker vi etablera förtroende i relationerna, vilket gör att man inte får den här känslan av att "Nu är vi tillbaka vid förhandlingsbordet igen"... För så var det ofta tidigare, att man hamnade i den situation, sälj och förhandlingssituationen, som projektledare hände det jätteofta. Varje gång man tittade på CR [change request] så hamnade man vid förhandlingsbordet igen. 27 Q: Skulle man inte då kunna säga att det blev mer flexibelt på så sätt? Av&p, Sdp, U 28 B1 - A: Ja, absolut. 29 Q: Ger Scrum en billigare utveckling? Blir det billigare för kunden, leverantören eller bli hela utvecklingsprocessen billigare helt enkelt? 30 B1 - A: Det där är klurigt egentligen så klart att jag skulle vilja säga att: "Ja klart det blir de " och det tror jag att det blir, men jag tror inte att man sänker sina utvecklingskostnader. Men jag tror att nå fram till samma resultat med en annan metodik skulle kosta betydligt mer. Har du förutsättningar för att använda agilt metodik, vilket du inte alltid har, men har du det så kommer du komma fram till ett resultat som hade kostat mer med en annan metodik. Det är jag helt övertygad om. Jag tror att får snabbare avkastning och det finns en massa andra ekonomiska fördelar men jag tror inte att man ska se den här metodiken som en billig metodik, för det är den inte. Det är en snabb metodik, en ruskigt snabb metodik och du får bra kvalité men den har en del krav på att utvecklingen inte kommer att vara billig direkt. Ett exempel är att i en traditionell modell så trevar du dig fram, dels hur du börjar med projektet hur du börjar att undersöka och planera vad behöver vi i scoopet och så tar man i hand på de och sen så sitter dels projektledaren och någon BA [business analyst] och kikar lite och analyserar lite och så småningom så skalar man upp projektet.. medans man i agilt är lite mer pang på. Det är lite mer "Okey, nu ska vi köra och då behöver vi dom här utvecklarna och skalar upp det lite. Det är inte så att du kör alla på samma gång, men du skalar betydligt snabbare. Om man ser på cash flow, så kommer du behöva mer pengar tidigare. Pengautflödet ser annorlunda ut helt enkelt och det ställer andra krav på finansieringen helt enkelt. 31 Q: Om vi tittar lite mer på hur själva processen ser ut, skulle du vilja berätta hur projektets process såg ut från att ni började till ett eventuellt avslut? Vilka processer och faser ni hade/gick igenom. Om du vill får du gärna rita. Av&p, Sdp, U 98

Agile project management The software development processes 32 B1 - A: [respondenten börjar rita på en white board samt förklarar vad det är som ritas från 20:20,0 --> ca 30.] Tänk att vi har 15 till 20 olika utvecklare. Många av mina projektledarkollegor tittar mycket på pengar för att avgöra hur stort ett projekt är, jag tittar istället på hur stor pipen är och hur många utvecklare som finns och sen vet jag att till detta kommer det komma tester osv. Det finns så klart även fler saker man tittar på men i alla fall.. Vi använde oss av feature, och det här handlar om kunskapsspridning. Om man har 15-20 utvecklare, vissa av projekten kanske kan färdigställas av tre och man behöver inte alltid alla. Men i ett agilt perspektiv så kan alla gå in och jobba med allting, vilket gör att du inte får några flaskhalsar, det är en massa fördelar. Likförbaskat kan inte alla kolla på samma sak, men vad vi gjorde var att vi delade upp det och de här började arbeta i det här projektet och med den här projektledaren eller den här säljaren. Man hade alltså någon slags prep-period här, och under denna period hade man utvecklare som hade olika möten med kund och sälj då. [dv + pl + sälj i bilden]. Någonting i den stilen, men ibland var det bara utvecklare och kund eller kanske även någon extern, eventuellt en samarbetspartner. 33 Q: Såg dessa människor till vad som skulle göras? 99 Av&p, Sdp

34 B1 - A: Ja, precis. Då började dem att känna vad är detta, vad handlar detta om? Någonstans här får man en känsla för vad det är för features, och den här perioden är mycket för att definiera features så att man får en initial känsla för storleken. Precis som i alla andra projekt så måste man kolla på storleken och leveransdatum, vi tittade på förhållandevis få parametrar här. Sedan hade vi ett planeringsmöte, som jag inte kommer ihåg vad vi kallade det men i denna modell kallar vi det "Styrgruppsmöte" men det är ett dåligt ordval för att det var ingen styrgrupp egentligen... men på detta möte hade vi de olika projektledarna och vi hade någon som var teknisk arkitekt, som vi kallade team leader. Vd:arna var väl inbjudna, men var aldrig där, och vissa säljansvariga var också där, och så var där väl någon kontorschef också... [på detta "Styrgruppsmöte"] Här tittade vi på portföljen, vilka projekt hade vi på ingående, en massa olika kampanjer och projekt, och projekt i detta sammanhang kunde vara projekt som tog 2-3 veckor till 3månader. Det var ändå rätt korta projekt, för att detta är en väldigt snabbfotad bransch. Vi pratar ju inte om tillverkningsindustrin och projekt som varar i flera år. Så projekt in här då, och så bestämde man "Vad släpper vi in här?", "Vilket av det här ska gå in i backlogen?". Det här var ju det första då, och det kunde ju vara veckan efter då så hade vi ett iterationsplaneringsmöte, där vi tog vi då de olika projekten och utvecklarna satte sig ner och finplanerade featuresen som någon tidigare i teamet hittade. När man finplanerade så tittade man på: "Hur gör vi detta?" och "Vad är det för uppgifter som behövs göras?", och detta blev då tasksen eller uppgifterna. Sen så åkte detta ut och deployades, här hade man våldsamt kort cykel så de kunde deploya flera gånger om dagen. Förmodligen gjorde man det någon gång varje dag/varannan dag, men man kunde göra det flera gånger om dagen. Leveransdelen här var inte så formaliserad sen, det kom ut och kommunicerades till rätt ansvarig som sedan tog kontakt med kund. Ungefär så här var det väl grundläggande, men så har vi också en iterationsdemo som visade ungefär var har vi varit/var står vi i de olika projekten. 35 Q: Ungefär hur lång tid var det här? 36 B1 - A: Vi körde ju två veckors iterationer. Men säg att vi hade ett pågående projekt, en kampanj som planeras och så kommer de lite mer här och demo sen retrospektiv här, och det kommer alltid dagen efter. Och att ha retrospektiv dagen efter tror jag generellt är väldigt bra. Många sätter samman det här [demo och retrospektiv] och ska ha det på en och samma dag, men jag tycker inte att det fungerar. Demon var generellt sett torsdag eftermiddag och sen kunde folk ringa in från andra städer och vara med och sen samlades alla på kontoret som var där just då. Det varierade vem som körde demon, men var det riktigt bra så var det projektledaren som körde, men det hände väldigt sällan. Det är ju egentligen best practice, att han som är kundrepresentant... men i många fall var det någon av utvecklarna. 37 Q: När du pratar om projektledare, pratar du om Scrum-mastern eller en projektledare i traditionell bemärkelse? Av&p, Sdp, U Sdp 38 A: En projektledare. Vi hade en motsvarande Scrum-master här och 2 Scrummasters här och de kallade vi team coacher, och sen hade vi team leader också. Team coacherna hade mer ansvar för den dagliga processen. Han hade inte så mycket erfarenhet [pekar på team leadern], så en utav de här killarna [pekar på team coacherna] fick coacha honom. 39 Q: Hur såg det ut på en daglig basis? Sdp 100

40 A: Stand upen hade vi runt klockan 9 varje dag. Vi hade en stor fysisk tavla med alla uppgifterna och en sekreterare som synkade alla uppgifter med ett ärendehanteringssystem, och sekreteraren hjälpte även min med lite annat administrativt. 41 Q: Hur såg hela mötet ut, vilka var närvarande? 42 A: Hela teamet var närvarande, alla som ville fick komma dit och kolla. Det var en väldigt stor tavla, 3-4 tavlor bredvid varandra och så stod alla i en halvmåne kring dessa tavlorna. Sen gick man runt och alla fick berätta saker och ting. Grundstommen är ju den att man ska svara på de tre frågorna: "Vad gjorde jag igår, vad ska jag göra idag och har jag några problem?" Men allteftersom så justerade man det lite, beroende på vad man ville höra, exempelvis "Fokusera på att förändra" eller så. Det är mycket av sånt som bestäms i retrospektiv. Det var lite olika "hunch" på de mötena. 43 Q: Ungefär hur lång tid tog de här mötena? 44 B1 - A: Ja, de va väl ungefär 15-20minuter. Det kunde väl dra ut lite på tiden, men oftast var det ganska snabbt. De flesta hade kört de här grundläggande i 2-3 år, så de var väldigt förtrogna med detta sättet att arbeta. Så när nya utvecklare anställdes så gick det ganska snabbt för dem att komma in i det, i och med att det var en så pass stark kultur hur man jobbade. Det är viktigt att själva teamet själv är bärande av traditionerna. 45 Q: När man ska bestämma uppgifterna till backlogen, hur görs prioriteringarna här? Vem är det som bestämmer vad som ska prioriteras högst? Sdp Sdp Sdp 46 B1 - A: Det är rätt klurigt i det här läget. Man tittar på det på två nivåer kan man säga. På första nivån tittar man på portföljen, vad som ingår. Mötet i sig som man har är mer en bekräftelse på en diskussion som man redan har haft. Och det här var min roll, detta gjorde jag mycket av. Mycket av min tid gick åt att ringa och maila de här olika projektledarna och se vad är det som känns viktigt här och så. Se till att alla helt enkelt är synkade. Så där var det vilka projekt måste vi prioritera. Man har ju en begränsad pipe och det handlar mycket om att väga, exempelvis vilka kampanjer måste vi genomföra nu, för att få in pengar och finns det någon kampanj som vi kan skjuta på eller blir kunde jättesur för det. Allt det här kontra att vidareutveckla produkten, så att vi klarar av att sälja helt enkelt. Samtidigt som det här så hade man också tittat på de features som kunden tillsammans med projektledaren och eventuellt säljaren hade kommit fram till... Förutom de olika kampanjerna så var det många vidareutveckling av olika delar mot andra länder. Då var det mycket med att trimma ner features och prat om vad är det vi måste ha, men det är ju också en dialog man hade innan. Sen den andra delen utav backlogen var det mer diskussion mellan teamet och team leadern. Det var då två faser, först vilka projekt och då hade man redan haft diskussionen vilka de var och sen den andra fasen handlade om hur stora de var och så, sen kunde det då läggas på ytterligare... 47 Q: Finns det något med agilt som är lite mindre bra? Sdp 101

48 B1 - A: Det finns jättemånga, det beror på situationen sätter du in agilt i ett ställe där det inte fungerar, alltså inte finns förutsättningar så blir det ju inte bra. Tänk att du jobbar mot en organisation där du inte har så bra kontrakt, och därigenom svårt att skapa delaktighet från kund, då får du det svårt. Sen finns det ju många grejer som inte agilt hjälper till med, det finns ingenting i agilt som hjälper dig att kommunicera i projektet. Om man tittar på projektverktygslådan så är den ju så att den omfattar väldigt mycket. Om man tittar på PMI så är där ju jättemycket grejer som agilt överhuvudtaget inte fokuserar på alls. Intressent hantering och kommunikation, kontinuerligt se till att man är förankrad och har det stödet man behöver hos kunden angrips ju inte alls av agilt. Det kan nog vara lite svårt att få det att fungera, detta är något som jag upplever nu. Men det finns väl ingen konkret nackdel kanske... 49 Q: Om vi tittat på de processer och delmoment som finns inom Scrum, vilken är den mest kritiska delen? Vad behövs för ett lyckat projekt? Sdp 50 B1 - A: Det är ju så olika Tittar man på det här caset här [det som informanten ritat upp] så ser man ju svagheterna här. Det som var mest problematiskt här var ju styrningen, men den lyckades vi få bukt på. Alltså agilt hjälper inte en där, utan du får något väldigt snabbt men hur du styr kan ju vara rätt ner i diket... Men jag tror att agilt hjälper till i och med att man får fokus på det, och de är ju rätt så snabbt. 51 Q: Mer konkret här med styrningen, vad är det för del som du skulle vilja lägga till? Sdp 52 B1 - A: Rent konkret i det här fallet så försökte vi åskådliggöra vilka projekt vi har, vad kan de ge oss för benefits, och hur långt tid kommer detta att ta. Och där finns ju lite olika modeller som man kan använda för att titta lite djupare på det. Det kanske inte är något som har med agil metodik att göra, utan det är väldigt viktigt i alla såna här sammanhang. 53 Q: Var någonstans skulle du vilja att man tittar ytterligare på styrning? Sdp 54 B1 - A: Det är ju de arbetet som går in i pipen. Viktigt att man ser till att ta rätt steg som slut för den produkten. 55 Q: Är det utifrån vad som är kundens eller leverantörens bästa? 56 B1 - A: Från kundens perspektiv, det är det det handlar om. 57 Q: Finns det något moment i Scrum som kanske känns lite överflödigt? Får du någonsin en känsla av "Varför har vi detta mötet?" eller kanske tycker att det är onödigt att släppa en demo varje vecka? 58 B1 - A: Det är så väldigt slimmat redan, det är nog ingenting man känner är onödigt 59 Q: Finns det någonting utöver styrning som du skulle vilja lägga till? Utifrån dina erfarenheter så kanske du känner att det är något speciellt som man skulle vilja lägga till, just för att det är så slimmat som du säger. 102

60 B1 - A: Ja, det är ju jättemycket! Återigen agilt är en väldigt nischad grej, det är ju en annan typ av skruvmejsel men det finns ingen hammare eller linjal. Det är ju jättemycket man måste komplettera med 61 Q: Till exempel?... 62 B1 - A: det som vi pratade om precis, portföljstyrning Jag tror att det är en av de grundläggande grejerna i det agila, alla säger att den här processen är inte omfattande, den omfattar inte allt du behöver utan den ger dig ett par bra verktyg som fungerar i vissa situationer. 63 Q: Nu har vi pratat om väldigt korta och grundläggande projekt, men används det agila sättet, framförallt Scrum, även i större och mer omfattande projekt, utifrån din erfarenhet? 64 B1 - A: Om man tittar på att vi hade 15-20 utvecklare så är det inte många som är så mycket kodbas. Vad man gör på större företag så delar man upp i mindre grupper och delar även upp ansvaret. Du har alltså något stort som du ska leverera och så delar du upp de i små delprojekt. Det är lite samma här, om du tittar på produkten så var den ju jättestor. Det mesta annat jag har jobbat med har nog varit mindre. Men vi jobbar med ett team på ett annat företag och hanterar deras säljstöd som är väldigt stort, men det här projektet som jag pratar utifrån nu var större på alla parametrar förutom att man hade färre utvecklare. Men om man tittar på projekt där jag har använt traditionella metodiker så har jag bara kört mindre projekt/saker. 65 Q: Finns det något ytterligare som du skulle vilja lägga till? Någonting som du känner att vi har glömt att fråga dig? 66 B1 - A: Det kanske jag redan har sagt, men det är ju inte det här tänket med en verktygslåda tänket. När man har jobbar ett tag så ser man vad man behöver olika, det är nog en väldigt central grej. Varje projekt man är på så lär man sig någonting om vilka faktorer det är som påverkar, och hur situationen var och så för man över det till nästa. Det är svårt att hitta den perfekta passformen. Sdp Sdp Sdp 67 Q: Då har vi fått svar på allt, tack så mycket 7.1.4 Interview C1 Rad nr Fråga/Svar 1. Q: Vilken roll hade du inom det projektet som vi kommer tala utifrån? 2. C1 - A: Inom projektet så har jag ingen som helst roll utan jag är chef för utvecklings organisationen. Där tillkommer personalansvar för det teamet som arbetar med Scrum gentemot våra kunder. 3. Q: Har du arbetat länge på den här positionen? 4. C1 - A: Ett och ett halvt år. (1,5 år) 5. Q: Har du haft en liknande position tidigare på något annat företag? 6. C1 - A: Ja. 7. Q: Och hur lång erfarenhet har du där? 8. C1 - A: tre och ett halvt år sammanlagt kanske. (3,5 år) 9. Q: Vad är det för projekt som du kommer tala utifrån? 103 Koppling till teoretiska ramverket Av&p

10. C1 - A: Kommer prata om ett utvecklings projekt av ett prisutvecklingsverktyg. 11. Q: När du tänker på Agila utvecklingsprocesser vad tänker du på då? Vad betyder Agilt för dig? 12. C1 - A: Agilt betyder snabb, rörlig, korta iterationer, produkt resultatet är inte bestämt till en början, kunden har större påverkan och att teamet tar ett eget ansvar för sitt arbete. 13. Q: Hur länge har ni använt er av Agila utvecklingsprocesser? 14. C1 - A: I fyra år ungefär. 15. Q: Vilka processer använde ni innan ni började använda Agila utvecklings processer? 16. C1 - A: Generell utgångspunkt är Vattenfalls modell och Svarta lådan som vi brukar kalla metoden, stoppa in en kravspec vänta sex månader och se vad som kommer ut. 17. Q: Varför valde ni att byta från Vattenfall och Svarta lådan till Agilt? 18. C1 - A: Svarta lådan fungerade inte, finns ingen förbättrings hantering inom Svarta lådan och Vattenfalls modellen fungerade inte för de lösningar vi utvecklade, vi utvecklar lösningar som är så pass specifika att de inte går att köpa, och så pass specifika lösningar är väldigt anpassade de som äger lösningen och därför måste de vara med. 19. Q: Fanns det något positivt med Vattenfalls modellen och Svara lådan som Agila processer inte fångar? 20. C1 - A: Vattenfalls är mer förutsägbart, men inom utveckling så finns det inte jätte mycket som var positivt med dessa arbetssätt. Skället till att ändå använda Vattenfalls modellen kan kopplas till outsourcing, det är väldigt svårt att jobba Agilt med ett företag som geografiskt inte befinner sig på samma position som du själv. Även om det finns teknik för att komma runt de så är de problematiskt. 21. Q: Hur har ni löst att arbeta med partners som inte kan vara närvarande? 22. C1 - A: Så länge man kan närvara på standups och så vidare, finns olika video och chatt system som gör det möjligt, man får helt enkelt skapa ett virtuellt team. 23. Q: Hur länge har ni använt just Scrum? 24. C1 - A: 4 år, ish. Vi använder Scrumish det är Scrum fast anpassat till våra premisser. De handlar inte om att förändra den utan anpassa den, att finkalibrerar den för våra ändamål. 25. Q: Har ni använt fler Agila metoder? 26. C1 - A: Vi har använt Scrum i utvecklingsprojekt men sen använder vi KANBAN i tekniska projekt. 27. Q: Och varför är Scrum så bra för er i utvecklingsprojekt? 28. C1 - A: Scrum är bra för att man kan arbeta mer dynamiskt, tillsammans med kunden, se till att man faktiskt levererar rätt sak, det är kunden som prioriterar med det är teamet som tillsammans skapar produkten. Så de finns ett ansvar både hos dem som är beställare men också hos teamet själva som leder till ett bra samspel. Scrum är tidseffektivt, enklare att optimera resurser eftersom man jobbar i korta iterationer istället för ett sex månaders projekt. Scrum är visuellt, framsteg i ett Vattenfalls projekt är svårt att avgöra. Tex. hur många sidor av kravspecifikationen har vi malt igenom och vad betyder de egentligen? Med Scrum så finns det ett system som berättar hur komplexa saker är att göra, när de skall göras och hur många som göras av vilka teams. Att kunna visualisera detta som Scrum gör är Av&p, U Av&p, U Av&p, U Av&p, Sdp, U Sdp Av&p, Sdp, U 104

viktigt för dem som inte jobbar med utveckling. 29. Q: Vi har hittat visa fördelar i teorin, så nu vill vi se om dessa finns i praktiken. Flexibilitet, blir du flexiblare tack vare Scrum? 30. C1 - A: Absolut. U 31. Q: På vilket sätt? 32. C1 - A: Flexibiliteten att tillexempel från ett Backlogg möte till ett annat helt omprioritera vad som är viktigt, lägga till eller ta bort funktionalitet. 33. Q: Kan man inte göra detta i tex. Vattenfalls modellen? 34. C1 - A: Man kan men då handlar de om changemanagment vilket är en ganska administrativ process. I Scrum är det en del av modellen, de är självklart vi skall förändras men i vattenfalls modellen så vill vi inte förändra oss men vi kan om vi trycker på. 35. Q: Har kundrelationen förbättrats? 36. C1 - A: De kunder som är mottagliga för att jobba enligt Scrum tycker det här är fantastiskt bra, de blir mer involverade och bestämmer mycket mer hur deras produkt skall se ut. Kunder som inte har tid däremot, för Scrum processen kräver tid av kunden, är de ingen hit and run som det var tidigare med vattenfalls modellen och som de är vana vid. Du skrev en spec, slängde iväg den också kunde du gå och jobba igen. Dessa kunderna har svårare att vänja sig vid Scrum processen. 37. Q: Blir Scrum en belastning på kunden? 38. C1 - A: De får ju vad de vill ha, de positiva med Scrum är ju det att de kräver tid av dem, men de kan också kännas obekvämt. 39. Q: Blir lösningarna mer skräddarsydda till kunden? 40. C1 - A: Absolut, de ser ju produkten i alla sina utvecklingssteg och kan då påverka vilket nästa steg blir. I vattenfalls modellen så ser du en prototyp, en beta version och en alfa version. Du ser 3 versioner på en livscykel, i det här fallet ett år istället för vart 3e som med Scrum. Detta ger ju mer och bättre feedback. 41. Q: Skulle du säga att det är en billigare metod? 42. C1 - A: De beror nog på om de är billigare eller inte, jag tror ju att den är billigare eftersom att vi skapar en produkt som kunden vill ha, och på så sätt blir den billigare, för en produkt som kunden inte vill ha kommer behöva rätt mycket efterarbete vilket är kostsamt. Men sen finns det också en risk att de blir dyrare, för många bäckar små, de kostar inte så mycket att lägga till en story på åtta poäng, de känns inte. Men att under ett helt projekt lägga till en story på åtta poäng i veckan blir ganska mycket pengar, och då är frågan om det är en must eller är det en bells and whistle att kunden tänker: vi kan ju få det så varför inte? 43. Q: När ni sätter poäng, gör ni de själva eller tillsammans med kunden? 44. C1 - A: Tillsammans med kunden och sedan prioriteras storys tillsammans med kunden, men sen finns det ju vissa tekniska krav, vissa kan du inte prioritera över något annat och vi (teamet) måste vara med och se till att flödet fungerar och är rätt prioriterat. 45. Q: Hur ser processen ut när ni arbetar med Scrum, från början till slut? 46. C1 - A: Eftersom projekt modellen för detta företag fortfarande har vattenfalls modellen som huvudprincip så kommer Scrum in i slutet på planeringsfasen där man tar en affärsspecifikation och bryter ner den i userstories. Den skrivs om utan att något nytt läggs till och arbetas igenom med kunden, estimerar stories, planerar 105 Av&p, Sdp, U Av&p, Sdp, U Av&p, Sdp, U Sdp, U Av&p, Sdp, U Av&p, Sdp, U Av&p, Sdp Av&p, Sdp

iterationer och planerar projektet och längden på denna planering är helt beroende av storleken på projektet, kan vara en dag eller flera veckor. 47. Q: Vad händer sen när själva arbetet sätter igång? 48. C1 - A: Kontinuerlig iterationsplanering vart tredje vecka, under iterationen så ser teamet till att lösa de uppgifter som är uppsatta för given iteration. Sen är det demo av produkten och retrospektive för att identifiera vad som gick bra och inte bra. Och på daglig basis har vi dayliestandups, impediments och allt som ingår i den här processen. Och vart tredje vecka så är kunden tillbaka igen, han får se produkten och prioritera nästa iteration. 49. Q: Vilka är med på de dagliga mötena? 50. C1 - A: Utvecklingsteamet, projektledaren och kunden om det är i slutfasen. Och då använder vi standardfrågorna, vad gjorde jag igår, vad gör jag idag och har jag några problem? 51. Q: Hur länge varar de dagliga mötena? 52. C1 - A: 15 min, de är inte time boxade. Du skall gå igenom alla resurser och se till att alla problem är lösta innan du går där ifrån. 53. Q: Hur ser mötet ut rent fysiskt? 54. C1 - A: Vi har tidigare jobbat med Scrum boards, men story lappar. Nu har vi gått över till att använda TFS tillsammans med ett grafiskt program som visar upp en digitaliserad Scrum board. Sen har vi en digital backlogg. 55. Q: Hur har ni själv anpassat Scrum till ert företag? 56. C1 - A: De är nog sättet vi använder Scrum då vi förhåller den till en vattenfalls modell. IT projekt är oftast en vattenfalls process som har en ide fas och förstudie fas och sen kommer Scrum in när utvecklingen kommer igång. Men anpassningen görs för att de skall fungera vid rapporteringen då de alltid är en styrgrupp som sitter någonstans och tycker och tänker. 57. Q: Vem är de som är ledare för just detta specifika projekt? 58. C1 - A: De finns projektledare som ibland agerar Scrum master, men oftast så får teamet agera Scrum master, de finns ingen utpeka person som fyller den rollen men sen får projektledaren ta visa ansvar som en Scrum master har, tex. om det är problem som inte kan relateras till utvecklings teamet. Projektledaren leder tillexempel dagliga mötet och retrospektiv och demon där kunden också är med. 59. Q: Hur stora brukar teamet vara? 60. C1 - A: 2-7 beroende på storleken på projektet. 61. Q: Kan storleken på projektet hindra er från att använda Scrum? 62. C1 - A: Nej man kan ha olika Scrum teams, men en Scrum master som knyter ihop och koordinerar teamen, då de finna ganska mycket beroende. De gäller att ha en balans mellan en projektplan och friheten inom ett Scrum team, då teamen skall lösa sina uppgifter helt själva och utan att deras kreativa frihet kränks. 63. Q: Hur dokumenterar ni er utveckling? 64. C1 - A: Dokumentation skall läsas, de är bara den enklaste dokumentationen som läses, kod dokumentera sig själv om man talar om för den att göra det. Vi dokumentera snarare vilka design paradigm vi använder än hur de funkar, de förväntar vi oss att läsaren kan. Allt skall skrivas, inte med glädje men vi skriver de. 65. Q: Vad är de som bestämmer när en uppgift är klar. 66. C1 - A: De beror på hur teamet har definierat defintion of done, och detta beror Sdp 106 Av&p, Sdp Sdp Sdp Sdp Sdp Sdp Sdp Av&p

från projekt till projekt så där finns inget generellt svar. Men i en definition of done finns oftast den gått igenom ett automatiserat test. 67. Q: När bestäms defintion of done? 68. C1 - A: I början av projektet, men de kan vara olika för olika iterationer. Sdp 69. Q: Finns de någon överflödig process i Scrum processen? 70. C1 - A: Nej, ibland kan retrospektiv kännas lite överkurs men det är viktigt att de följs upp. 71. Q: Finns de några kritiska processer i Scrum processen? 72. C1 - A: För är de just anpassningen till vattenfalls modellen. Vi måste se Scrum som en del i en större metod men en annan typ av rapportering än vad Scrum ger. 73. Q: Finns de något generellt positivt med Scrum? 74. C1 - A: Den tar tillvara delar av andra modeller, den pratar om saker man redan gör men på ett sätt som är mer tilltalande för utvecklare. Att prata med bonden på bondens språk, Scrum presenteras enkelt och man förstår vad som skall göras och förstår nyttan med det som görs. 75. Q: Finns det någonting i processen som du hade velat lägga till? 76. C1 - A: Jag är inte intresserad av en Scrum bords, jag vill ha Scrum för att knyta ihop projektet med företaget. För de är något som saknas så är de att göra Scrum lika kraftfullt för en hel organisation och inte bara ett projekt med givna ramar. En Scrum process på en IT organisation som bedriver 200 Scrum processer samtidigt, där skulle jag vilja se Scrumoch ett bra användande av det. 77. Q: Blir Scrum för flexibelt? 78. C1 - A: De blir inte för flexibelt för oss (utvecklingen) utan de blir för flexibelt för dem som kanske gör uppföljning inom vissa ramar. Ett företag sätt att mäta hinner inte med Scrums sätt att arbeta. 79. Q: Är det något mer du skulle vilja få fram med Scrum processen? 80. C1 - A: De tror jag inte. Sdp Sdp Sdp Av&p, Sdp, U 7.1.5 Interview C2 Row # Question/Answer 1 Q: Skulle du vilja berätta lite om vad du jobbade med/vilken roll du hade i det här projektet som vi skulle prata om? 2 C2 - A: Projektet i sig gällde ju prissättning enligt vissa förutbestämda kriterier, och det var att implementera en applikation för att stödja det. I projektet så fungerade jag mer som teknisk specialist och rådgivare. Jag var med en begränsad tid under projektet, men har bra insyn i hur de arbetade och vilka problem som uppstod. 3 Q: Var du med och gjorde någon utveckling själv? 4 C2 - A: Ja, litegrann på vissa områden där man behövde hjälp. 5 Q: Hur länge har du arbetat på den här positionen som du berättade om? Koppling till teoretiska ramverket Av&p, Sdp, U 107

6 C2 - A: I själva projektet så var det ju under projektets tid annars har jag haft den rollen och liknande roller, systemutvecklare, arkitekt eller rådgivare till andra projekt, sedan år 2006 ungefär. 7 Q: Under hur lång tid hade ni det här projektet? 8 C2 - A: Det löpte under 3½månad, tror jag. 9 Q: Då skulle vi vilja veta vad agila utvecklingsprocesser är för dig? Vad är det som är specifikt för det agila sättet? 10 C2 - A: Agila utvecklingsprocesser utgår ju ifrån kundens behov och sätter kunden i centrum när det gäller förhandla i kontrakt, göra noggrann dokumentation och en fungerande mjukvara. Det är ju egentligen så att man levererar det som kund och användare vill ha. Begreppen kund känner jag betyder är alla de som har nytta av vad som kommer ut projektet... 11 Q: intresenter då?... 12 C2 - A:...precis Själva det agila arbetssättet an ju ge fördelar med att det kan anpassar sig snabbare om man jämför med traditionell utveckling typ vattenfall Av&p, Sdp, U 13 Q: Hur länge har ni använt er av agila utvecklingsprocesser? C2 - A: I ungefär 4 år. 14 Q: Och hur lång tid har du använt dig av agilt, om du ser till hela din arbetslivserfarenhet? 16 C2 - A: Det är väl i 4 år... 17 Q: Vad använde ni er utan innan vi använde agila utvecklingsprocesser? 18 C2 - A: Innan vi började läsa in oss på agilt så använde vi oss utan någon form av egen utveckling där man tog in delar ifrån RUP men utan att veta om det så arbetade vi väldigt agilt för att vi använde oss utan product backlog, som vi inte visste hette så då. Att istället för att bara trycka ut uppgifter på utvecklare att de tog det de ville arbeta mer. 19 Q: Finns det någon speciell anledning till att ni gick över på agilt? 20 C2 - A: Det var ju både det att vi sökte någon form av strukturerad utvecklingsmetod. Det fanns ingen fast utvecklingsmetod som vi kunde luta oss mot, inget ramverk heller. Och så kändes det som att Scrum var det som låg närmst till hands. Det var väl de som också löste många av de problem som fanns hos oss, att ha snabb feedback fram och tillbaka från kunden. Eller problemet med att ha specar som visade sig inte vara det som kunden ville ha, och så ville vi att företaget snabbt kunna förändra och reagera då också. 21 Q: Då går vi över på lite med frågor om Scrum. Hur långe har ni använt er utan Scrum? 22 C2 - A: Ja, det är ju då ungefär samma tid. Det var det första ramverket som vi tittade på. 23 Q: Har vi använt någon annan metod inom de agila metoderna? Av&p, Sdp Av&p, Sdp, U 108

24 C2 - A: Ja, vi har ju asså anpassat beroende på projekt, och då har vi ju inte kört Scrum. Vi har utgått ifrån de förutsättningar som fanns med projekten. Har det varit två personer i projektet eller om man har arbetat väldigt tätt tillsammans så har vi inte kört daily standups, om det inte har känts behövligt, och därmed har vi ju inte gjort Scrum. Vi har inte heller kört renodlade Scrum när många olika kompetenscenter har varit inblandade, där inte alla kompetenscenter har velat eller möjlighet att arbeta under metoden Scrum. Inte heller när kunden inte velat köra Scrum... 25 Q: Men är det bara en variant av Scrum som ni har använt eller kanske någon av de andra agila metodikerna så som XP, Kanban eller Lean? Av&p, Sdp 26 C2 - A: ja, egentligen är det ju inter Scrum om man tar bort någon av nyckeldelarna, eller vad man definierar som Scrum. 27 Q: Vi har ju hittat en del fördelar med Scrum i teorin, men vad ser du finns för fördelar med Scrum? 28 C2 - A: Fördelen med Scrum är ju att det är ett enkelt ramverk, man har ju två form av listor i form av backlogs, man har tre roller och fyra möten. Så det är en väldigt enkel att förklara för folk, så den enkelheten är ju en fördel. Fördelen är också att man har något att strukturera och arbeta efter men som ändå går att anpassa, då den är så pass löst styrd att du egentligen bara har et ramverk att lägga in en process i. Fördelarna ligger också i de agila fördelarna att man har tät kontakt med kund, eller product owner som representerar kund och att man därigenom kan få feedback snabbt. och att man har dagliga möten vilket gör att man snabbt kan få reda på problem som uppstår och feedback på dem, och kan ta tag i dem när de dyker upp efter hand. Samma sak att man har sin sprint backlog och sin Scrum board att man får en visualisering av hela flödet, och att man inte lider av symtomen från traditionell projekt utveckling där man är 90% färdig 90% av tiden som man brukar säga, för här får man en ganska tydlig bild av när man är färdig. och även att man tydligt ser när saker och ting växer, via burn outs. 29 Q: Nu tänkte jag berätta om lite olika fördelar som vi funnit i teorin och så får du berätta lite om hur du ser på dem. Flexibilitet? 30 C2 - A: Ja, i och med att Scrum är ett ramverk så är det väldigt flexibelt i och med att man kan lägga på sina egna practises och sina egna delar till projektstyrningen. Man kan ju kombinera med andra projektstyrnings modeller. Och även i sig att man är flexibel om man nu väljer att arbeta med stories som inte inkluderas i Scrum men som är väldigt vanligt, så gör man färdigt en story i taget men därmed är flexibel att kunna byta och ändra sig och kunna prioritera om. Kunden kan själv säga nu har det förändrat sig och därför vill ja prioritera det här istället. Annars i det traditionella så är det vanligt att man har gjort sin spec. och ska man sen avvika från sen så måste man göra en change request och sen ska det göras en process kring det hela. 31 Q: Kundrelationer är också något som teorin föreskriver som en av fördelarna med Scrum, hur ser du på det? Av&p, Sdp, U Av&p, Sdp, U 109

32 A: Ja, det är ju huvuddelen bakom hela det agila tänkandet, att ha en nära relation till kunden, och få en direkt återkoppling till kunden. Så de är ju klart att det är en fördel, men sen kan det även vara svårt att få in alla kunder i det agila tänket, och många tänker att de inte har tid med det här, och att det tar för mycket tid för dig med denna typ av process metodik. Det kan vara en utmaning och är svårt att få dem att ändra sitt tänkande för att dom är upptagna med sia saker, och sälja sina produkter till sina kunder. Där får man väl helt enkelt visa att man får mycket mer och effektivare och mer rättvisande projekt där man levererar rätt saker. 33 Q: Kan det vara problematiskt att arbeta med en kund som inte är van vid att arbeta i Scrum? 34 C2 - A: Ja, det kan de. Jag har väl sett exempel på både och, i något projekt så var det en kund som helt euforisk och tyckte att så här borde vi arbeta i alla projekt. Det var väl chefen på avdelningen som egentligen inte var inblandad i projektet men som ändå var med på eget initiativ. Han tyckte att det var så bra att han kunde lägga in egna önskemål, något som han inte kunde göra tidigare och att det blev prioriterat. 35 Q: De gånger man har arbetat med ett företag som inte är vana vid det, hur har ni fått dem att förstå att detta är ett bra sätt att jobba på? 36 C2 - A: Inom det här företaget så är de ju problematiskt och det har fortfarande inte gått fram på många ställen för att man har en övergripande utvecklingsmodell som inte är agil över huvud taget, och som gäller över hela företaget och inte bara på IT-projekt. och den är ju väldigt mycket vattenfallsstyrd. Så att det vi har fått göra är på de bitarna där vi själva har fått möjlighet att styra är att helt enkelt göra agilt inom gruppen och sedan avgränsa oss ut. En del kunder har ju tyckt att det har varit jättebra att kunna få den detaljstyrningsnivår, att själva kunna följa upp om budgeten och så medans andra har tyckt att de vill ha ett fastpris inom företaget och sen tyckt att det är ni som står för riskerna. De inser väl inte alls att med fastpris så blir det ofta en tids och budgetpress så måste man ta genvägar för att nå målet och då blir kvalitén sämre och man får inte det man har efterfrågat. 37 Q: Förklarar ni det för kunden, eller de får förstå det själva? 38 C2 - A: Ja, vi försöker göra det i alla fall. Men sen så oftast så ligger de flera skikt mellan oss och beställaren, så det är ju inte dem vi kommer i kontakt med som är slutkunden helt enkelt. För slutkunden kanske hellre hade kört agilt, men sen finns det vana och tradition att man ska använda fastpris. Och sen är det även flera kompetenscenter som organisationen är indelad i med olika sätt att arbeta på olika produkter. Vårt kompetenscenter har väldigt mycket med ren systemutveckling medan andra har standardsystem och där är det svårare att köra agilt då man arbetar mycket med specifikations arbete och måste specificera mycket i förväg, så det bli ju svårare att köra korta iterationer. Det är ju också svårt om man inte är van vid det. 39 Q: Blir det billigare att använda sin utav Scrum än traditionell projektmetodik, är det en billig projektmetodik? Av&p, Sdp Av&p, U Av&p Av&p, U 110

40 C2 - A: Jämfört med traditionella så blir det billigare i längden, framförallt för att man får möjligheten att anpassa sig efter de förutsättningar som kommer fram och de förutsättningar som finns under projektets gång och som kräver att man får feedback direkt och då genererar rätt saker. Och att man kan hålla en jämn och hög kvalité. Men det är ju inte Scrum i sig som ger de fördelarna, utan att man tillför eget. Det finns ju inga practices inbyggt i Scrum så det är ju mycket upp till hur man implementerar det. Så om man har en dålig implementation av Scrum så är ju risken istället att man producerar fortare men att det är mycket och dåligt istället. Man kommer ju fortare framåt men kvalitén tillhör inte Scrum. 41 Q: Blir det mer skräddarsytt om man använder sig utav Scrum? 42 C2 - A: Det är en svår fråga Ja i det avseendet att man inte specificerar allting i början så är det ju klart att det bli bättre anpassat till behoven. Av&p, U U 43 Q: Hur såg processen ut, i det här projektet som vi pratar om, när ni använder er utav Scrum? Från början till slut, när ni lämnade över produkten. 44 C2 - A: Man arbetade med produkt ägare, det var två personer som skötte själva produktägarrollen, och som skapade huvuddelen av produkt backlogen och sen prioriterade. Sen körde vi sprintar, iterationer, som var två veckor långa och avstämning då varannan vecka som kallades demomöten. och retrospective... Man följde alltså Scrum helt som i teorin. 45 Q: Hade ni några dagliga möten? 46 C2 - A: Ja det var dagliga möten, där produkt ägarna var med också Sdp 47 Q: Var produkt ägarna med på alla möten? 48 C2 - A: Det var dem, jag kan inte svära på att de var men på precis alla, men alla demomöten och även sprintplaneringar. De dagliga mötena tror jag att de var med på majoriteten. 49 Q: Hur såg dessa möten ut? 50 C2 - A: Det följde Scrum agendan för daily Scrum. Svara på frågorna "Vad har du gjort sedan förra gången? Vad ska du göra framöver? Har du några problem?". Sdp Sdp Sdp 51 Q: Hur såg det ut rent visuellt? Hade ni någon tavla eller hade ni något datorprogram? 52 C2 - A: Ja, det fanns en Scrum board som man samlades runt där man hade de olika storisen och tasksen. Sdp 53 Q: Hur långt var mötet ungefär? 54 C2 - A: En kvart. Sdp 55 Q: Vi har ju hittat lite namn på de olika faserna som du har gått igenom. Pregame, Game och Postgame. Har du hört dessa namnen tidigare? 56 C2 - A: Inte just de namnen har jag inte hört. Om man ska se till pregame så hade man en uppstart innan där man gick igenom att denna metodologin kommer vi använda och stämmer av med de som var potentiella produkt äger då. Produkt ägarna tyckte att det lät som en god idé, en av dem hade varit med sen tidigare och hade kört Scrum och fått goda erfarenheter från de. Den andra var ny för agila metoder helt enkelt. Sen s följde ju implementationen Scrum. Och om vi ska se på postgame från produktsättandet och framåt så har produkten blivit produktsatt och övergått till till någon form av maintenance fas helt enkelt. Sdp 111

57 Q: Finns det något moment som är kritisk för att man ska lyckas med denna projekt metodiken? 58 C2 - A: Man måste komplettera med någon form av tekniska practises, för att upprätthålla kvalitén vid leveransen så att säga. Som jag sa tidigare, att man inte bara levererar dåliga saker fortare, för det är lätt. Sen är det viktigt att man kör retrospective så att man kontinuerligt kontrollerar processen så att man inte bara kör vidare. Sen att man både under de dagliga mötena och under retrospective fokuserar på vad man kan förbättra. Ofta under dagliga möten så har ingen några problem, vilket inte kan vara sant för att det finns alltid någonting som kunde gjorts bättre åtmindsånde. Man fastnar på något problem och så till slut så löser man ju det, men varför fastnar man kan man fundera på. 59 Q: Fanns det någonting som kanske kunde ses som överflödigt, någonting som inte hade behövts finnas med? 60 C2 - A: I själva Scrum skulle jag inte säga att det fanns något som var överflödigt, i och med att den är så liten. Sdp Sdp 61 Q: Utifrån dina erfarenheter av att arbeta med Scrum som utvecklingsprocess, finns det någonting som du skulle vilja ändra på, lägga till eller ta bort? 62 C2 - A: Inte i Scrum som sådant. Det kan ju ses som en fördel men också som ett hinder för många som ska införa det som nytt, att det är så pass enkelt synbart men inte är så enkelt att praktisera. Sen finns de ju så många olika tekniska practises som finns att komplettera, men de kanske inte passar alla. Så därför tror jag inte att man ska införa mer saker i Scrum. Man kanske kan skriva så här har vi gjort, och det har fungerat för oss, men för er så kanske det är någonting annat som fungerar... 63 Q: Då har vi kommit till avslutningsfasen och här skulle vi vilja att du berättar om det är någonting som vi har glömt att fråga dig eller någonting som du känner att du vill få fram här? 64 C2 - A: ja, om man nu se till just detta specifika projektet så fanns det ju problem i projektet. Ett av dem var att under demomötena för varje sprint så hade kunderna och produkt ägarna möjlighet att komma med feedback, men det gjorde dem inte. De vågade inte lämna feedback av någon anledning, de kände sig väl osäkra på hur de skulle ge den feedbacken osv. Så istället kom det tillbaka till utvecklingsteamet på omvägar, att de var missnöjda med saker som de inte tyckte fungerade bra... Jag vet inte om att de var för att de var vana vid att, här är kraven och de kanske inte är så tydliga och därför är det vårt eget fel... eller om de var för att de inte hade det förtroendet och kände att de kunde leverera den feedbacken... 65 Q: Kan det ha varit för att de var vana vid att om man vill göra ändringar så kostar det mer och därför ber man inte om ändringar? Sdp Av&p, Sdp, U 112

66 C2 - A: Ne, jag vet inte De ville ju göra ändringar för att få det så som de ville ha de Ne, jag vet inte riktigt varför de inte vågade komma med den feedbacken. Det är ju en av de sakerna, det krävs att förtroende etableras, och då är det ju en fördel om man kör under en längre tid. Då märker man ju att man kan lita på andra och att man sitter i samma båt, och måste samarbeta för att ro i land. Jag vet inte om det kan ha spelat in, men ofta är de ju vanan från de som representerar kundsidan att det är IT-sidan som tar hand om alltid när det gäller produkt och projektstyrning. De kanske anser att de levererar en spec., sen får de implementera det och göra estimat och budget osv. Och sen även att det är ITsidan som gör prioriteringarna, i vilken ordning man ska göra saker, för att allting måste ju levereras... Sen är det också svårighet i hur man ska prioritera, för allting är prio ett. Allt måste levereras annars går det inte. Sen finns det svårigheter för nya utvecklare i agila metoder, att se hur man kan bryta upp leveransen, se att man faktiskt kan delleverera saker och se att man faktiskt kan byta ut en enskild prioritet och leverera den utan att leverera helheten. 67 Q: Hur gjorde ni prioriteringarna? 68 C2 - A: Det var produkt ägaren som gjorde prioriteringen, och de lyckades att prioritera stories. Men sen är det ju oftast så att man måste jobba aktivt med produkt backlogen och se hur de hänger samman. Och det fanns väl problem med hur de skulle prioritera, men de prioriterade i slutändan rätt, men sen var det ju just feedbacken som var problemet. 69 Q: Ja, då känner vi att vi har fått svar på alla våra frågor, tack så mycket. Av&p, Sdp, U Sdp 113

References Aaen, I., Börjesson, A. and Mathiassen, L. (2007). SPI Agility: How to navigate improvement projects. Software process improvement and practice, 12, 267-281. Abrahamsson, P., Salo, O, Ronkainen, J. & Warsta, J., (2002) Agile software development methods: Review and analysis. VTT Publications. Espoo 478, Finland. Available at: http://www.vtt.fi/inf/pdf/publications/2002/p478.pdf [accessed 2011-04-24] Alleman, G. B. (2002). Agile project Management Methods for ERP: How to apply agile processes to complex COTS projects and Live to tell about it. In Wells, D., Williams, L., eds (2002): Extreme Programming and Agile methods: XP/Agile Universe 2002, Berlin, Springer Ambler, S. W., (2006) Examining the agile manifesto. Ambysoft. Revised August 19, 2006 Available online at: http://www.ambysoft.com/essays/agilemanifesto.html [accessed 2011-04-24] Anderson, D.J., 2004. Agile Management for Software Engineering. Prentice Hall, Upper Saddle River, New Jersey. Avison, D., & Fitzgerald, G., (2006) Information Systems Development: Methodologies, Techniques and Tools. 4th Ed. London: McGraw-Hill. Beedle, M., Devons, M., Sharon, Y., Schwaber, K. & Sutherland, J., (1999) Scrum: An extension pattern language for hyperproductive software development, in Harrison, N., eds (1999): Pattern Languages of Program Design. Boston, AddisonWesley Beznosov, K. & Kruchten, P., (2004) Towards Agile Security Assurance. Proceedings of the 2004 workshop on new security paradigms, pp.47-54, Nova Scotia, Canada. Björkholm, T., & Brattberg, H., (2010) Prioritera Fokusera Leverera. Din snabbguide till Lean, Agile, Scrum och XP, Stockholm: Vulkan. Blomberg, J. (2003). Projektorganisationen kritiska analyser av projektprat och praktik. Malmö: Liber. Borum, F. (1980). Systems desgin and scientific managment. Technology and Society, 4, 287-296. 114

Bryman, A. (2002). Samhällsvetenskapliga metoder. Malmö: Liber Ekonomi. Chow, T. & Cao, D-B., (2007) A survey study of critical success factors in agile software projects, The Journal of Systems and Software, 81, 961 971 Creswell, J. W. (2007) Qualitative inquiry and research design : choosing among five traditions. 2nd ed., Sage, Thousand Oaks, CA. Denscombe, M. (2009). Forskningshandboken för småskaliga forskningsprojekt inom samhällsvetenskapen. Studentlitteratur: Lund Dybå, T. & Dingsøyr, T., (2008) Empirical studies of agile software development: A systematic review, Information and Software Technology, 50, 833 859 Highsmith, J., (2001). History: The agile manifesto. Agile Alliance. Available at: http://agilemanifesto.org/history.html [accessed 2011-04-24] Highsmith, J. & Fowler, M., (2001) The agile manifesto. Software Development Magazine. August 2001 Available at: http://www.ddj.com/architect/184414755 [accessed 2011-04-24] Hultén, P., Hultman, J. & Eriksson, L. T. (2007). Kritiskt tänkande. Malmö: Liber Hossain, E., Baber, M., A. & Paik, H-Y. (2009) Using Scrum in global development: A systematic literature review, Fourth IEEE International Conference on Global Software Engineering. Jacobsen, D. I. (2002). Vad, hur och varför? Om metodval i företagsekonomi och andra samhällsvetenskapliga ämnen. Lund: Studentlitteratur. Kvale, S. & Brinkmann, S. (2009): Interviews: Learning the Craft of qualitative research interviewing, 2nd ed. Sage, Thousand Oaks, CA Lindvall, M, Basili, V., Boehm, B., Costa, P., Dangle, K., Shull F., Tesoriero, R., Williams, L. & Zelkowitz, M., (2002) Empirical Findings in Agile Methods. Agile Universe, www.cebase.org. Martin, C.R., (2003). Agile Software development Principles, Patterns and Practices. New Jersey: Prentice Hall Morien, R. & Wongthongtham, P., (2008) Supporting Agility in Software Development Projects Defining a Project Ontology, Second IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2008), available online at 115

http://espace.library.curtin.edu.au/view/action/singleviewer.do?dvs=1304590281861~976&local e=sv_se&viewer_url=/view/action/singleviewer.do?&delivery_rule_id=10&search _terms=sys%20=%20000011824&adjacency=n&application=digitool- 3&frameId=1&usePid1=true&usePid2=true Neill, C. J., (2003) The Extreme Programming Bandwagon: Revolution or Just Revolting? IT Professional, 5 (5), 62-64. Seale, C. (1999): The quality of qualitative research. Sage Publications, London Schwaber, K., (1995) Scrum development process. Proceedings of the Conference on Object- Oriented Programing Systems, Languages, and Applications (OOPSLA 95), available online at http://csis.pace.edu/~marchese/cs616/agile/scrum/schwapub.pdf Schwaber, K., (2004) Agile project management with Scrum, Washington: Microsoft Press 116