Agile project management

Transkript

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

2 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

3 Contents 1 Introduction Research focus Purpose Delimitations Models and guidelines Traditional project methodology Agile Project methods Values Principles Scrum Roles Daily Scrum Scrum process Pregame Game Postgame Usefulness with Scrum The difference between traditional project and Agile projects Research model Method Selecting a method Sample Interview guide Interviewing, transcribing and analysing Validity and reliability Ethics Criticism of the sources Findings The companies Company A Company B Company C Summary of company findings Values Summary of Value findings Principles Summary of Principle findings Scrum processes Company A Company B Company C Summary of the company Scrum processes Usefulness ii

4 5 Discussion and Analysis Values Principles Scrum process Before Scrum Pregame Game Postgame Usefulness Features in the Scrum processes that result in project usefulness Agile values and principles connected to the Scrum process How the Scrum process is connected to project usefulness Summary Conclusion...80 Appendix...82 Interview guide in Swedish Interview guide in English Transcription Interview A Interview A Interview B Interview C Interview C References iii

5 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 Table 2.3: The Ought's from Agile principles Table 2.4: Comparison between Waterfall and Agile, (Morien & Wongthongtham, 2008, pp.230) Table 2.5: Values in our research model Table 2.6: Principles in our research model Table 2.7: Usefulness with Agile/Scrum in our research model Table 3.1: Introduction questions Table 3.2: Agile questions Table 3.3: Scrum questions Table 3.4: Closure question Table 4.1: Summary of company findings Table 4.2: Summary of value findings Table 4.3: Summary of principle findings Table 4.4: Summary of the company Scrum processes Table 4.5: Summary of usefulness findings Table 5.1: Research model of values with empirical findings Table 5.2: Research model of principles with empirical findings Table 5.3: Research model compared to empirical findings of usefulness Table 6.1: Summary of Agile features connected to the Scrum process features Figure 2.1: Scrum phases Figure 2.2: Scrum methodology, (Schwaber, 1995, pp.10) Figure 2.3: Scrum process, (Abrahamnsson, et al., 2002, pp. 28) Figure 2.4: Research model for Scrum process, (Abrahamnsson, et al., 2002, pp. 28) Figure 4.1: Scrum process for Company A Figure 4.2: Scrum process for Company B Figure 4.3: Scrum process for Company C Figure 5.1: Pregame phase Figure 5.2: Game phase Figure 5.3: Postgame phase Figure 5.4: Agile features incorporated to the Scrum process model Figure 5.5: Scrum features connection to project usefulness Figure 6.1: Summary of Scrum processes Figure 6.2: Summary of values Figure 6.3: Summary of principles Figure 6.4: Summary of usefulness Figure 7.1: Scrum features connection to project usefulness iv

6 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

7 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

8 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

9 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

10 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

11 & 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

12 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

13 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

14 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

15 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 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

16 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

17 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

18 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

19 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

20 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 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

21 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

22 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) 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

23 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

24 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