The Agile Transition in Software Development

The Agile Transition

1

MIT9.100 Applied Research Project MASTER OF INFORMATION TECHNOLOGY

The Agile Transition in Software Development Companies: The Most Common Barriers and How to Overcome Them

Santiago Obrutsky Student ID: 2016000980 Supervisor: Dr. Emre Erturk

Napier, New Zealand 7 June 2017


2

Contents Abstract ......................................................................................................................................... 6 CHAPTER 1: INTRODUCTION ......................................................................................................... 7 Introduction .................................................................................................................................. 8 Research Question ...................................................................................................................... 10 CHAPTER 2: LITERATURE REVIEW ............................................................................................... 11 Literature review......................................................................................................................... 12 Topic background ................................................................................................................... 12 Agility .................................................................................................................................. 12 Scrum.................................................................................................................................. 15 Kanban................................................................................................................................ 17 Extreme Programming (XP) ................................................................................................ 19 Theoretical perspectives......................................................................................................... 21 A set of theories based on prerequisites and key decisions .............................................. 21 An Agile framework to define the organisation structure ................................................. 24 The Agile Adoption Framework: The 4-Stage Process ....................................................... 25 Obstacles in moving to Agile software development methods ......................................... 26 The Agile transition barriers: How to avoid them? ................................................................ 27 General organisational resistance to change ..................................................................... 27 Lack of business/user/customer availability ...................................................................... 29 Pre-existing rigid/waterfall framework .............................................................................. 31 Not enough personnel with the necessary Agile experience and development team support ............................................................................................................................... 32 Concerns about a loss of management control and management concerns about lack of upfront planning................................................................................................................. 33 Insufficient management support...................................................................................... 34 Concerns about the ability to scale Agile ........................................................................... 35 Perceived time and cost to make the transition ................................................................ 39 Regulatory compliance ....................................................................................................... 39 CHAPTER 3: DATA COLLECTION AND ANALYSIS.......................................................................... 40 The Agile project management survey ....................................................................................... 41 Results section one: IT professional experience .................................................................... 41 Results section two: The Agile transition ............................................................................... 44 Results: The Agile barriers ...................................................................................................... 45 Final comments and feedback ................................................................................................ 47 Discussion.................................................................................................................................... 50 The Agile transition theories .................................................................................................. 50 The Agile project management survey ................................................................................... 52 The biggest Agile barriers and their avoidance ...................................................................... 54


3

General organisational resistance to change ..................................................................... 54 Lack of business/user/customer availability ...................................................................... 55 Pre-existing rigid/waterfall framework .............................................................................. 56 Not enough personnel with the necessary Agile experience and development team support ............................................................................................................................... 56 Concerns about a loss of management control and management concerns about lack of upfront planning................................................................................................................. 57 Insufficient management support...................................................................................... 58 Concerns about the ability to scale Agile ........................................................................... 58 Perceived time and cost to make the transition ................................................................ 59 Regulatory compliance ....................................................................................................... 59 Summary of the approach used to address the research question ....................................... 60 CHAPTER 4: CONCLUSIONS AND RECOMMENDATIONS ............................................................. 61 Conclusion ................................................................................................................................... 62 REFERENCES AND BIBLIOGRAPHY ............................................................................................... 69 References .................................................................................................................................. 70 Bibliography ................................................................................................................................ 75 APPENDICES ................................................................................................................................ 77 Appendix A .................................................................................................................................. 78 The Agile project management survey ................................................................................... 78 Appendix B .................................................................................................................................. 80 REAC application approval...................................................................................................... 80 Appendix C .................................................................................................................................. 81 The proposed Agile project management framework for future research ............................ 81


4

Figures Figure 1. Comparative Chart – Traditional vs. Agile.................................................................... 14 Figure 2. Scrum Framework ........................................................................................................ 16 Figure 3. Basic Kanban Board...................................................................................................... 19 Figure 4. Emergence of pre-start-up assessment theory ........................................................... 22 Figure 5. The addressed question in Agile key decisions ............................................................ 24 Figure 6. The APM framework .................................................................................................... 24 Figure 7. The 4-Stage Process for Agile adoption ....................................................................... 25 Figure 8. Scrum Of Scrums - Guide to Agile Scaling Frameworks ............................................... 36 Figure 9. The Scaled Agile Framework ........................................................................................ 38 Figure 10. Current IT professional positions ............................................................................... 42 Figure 11. Company size ............................................................................................................. 42 Figure 12. Years of work in software development companies ................................................. 43 Figure 13. Years of Agile practice in Software development companies ................................... 43 Figure 14. Agile methods used.................................................................................................... 44 Figure 15. Time required for the Agile transition ....................................................................... 44 Figure 16. Stakeholders time response improvement................................................................ 45 Figure 17. The barriers to Agile, by percentage .......................................................................... 46 Figure 18. The barriers to Agile, by number of respondents ...................................................... 46 Figure 19. Resistance to change in the Agile transition .............................................................. 47 Figure 20. The misunderstanding of the Agile process in the Agile transition ........................... 47 Figure 21. The failure to adopt roles in the Agile transition ....................................................... 47 Figure 22. The Agile barriers’ bubble chart................................................................................. 53


Tables Table 1. The most common Agile barriers and their avoidance. ............................................. 64

5


6

Abstract The purpose of this research is to answer the following research question: “Which are the most common barriers and how to overcome them during the Agile transition?” Firstly, based on a literature review, this study describes the Agile concept including its principles, practices, and three of the most used Agile project management methodologies: Scrum, Kanban and eXtreme Programming (XP). Secondly, the literature review includes current Agile adoption theories which have provided considerable information about Agile barriers. These works will show some prerequisites, key decisions, transitional frameworks, and several recommendations to overcome organisational, cultural, and structural Agile barriers. This study includes an Agile project management survey which has gathered the most important issues that software development companies have to overcome in order to be successful in an Agile transition. A 23 questions survey was compiled from information from Scrum masters, project managers, chief executive officers, and IT professionals who have participated in companies that have migrated from a traditional methodology to an Agile methodology. Several barriers were identified: general organisational resistance to change, lack of business/user/customer availability, preexisting rigid/waterfall framework, not enough personnel with the necessary Agile experience, concerns about a loss of management control, management concerns about lack of upfront planning, insufficient management support, concerns about the ability to scale Agile, development team support, perceived time and cost to make the transition, and regulatory compliance. Recommendations to overcome each of these barriers are provided based on a further literature search and analysis.


CHAPTER 1: INTRODUCTION

7


8

Introduction This work has the purpose and commitment to help software development companies to understand if they are capable of implementing an Agile project management methodology to improve their software development processes. The Agile methodologies have been chosen over the traditional ones during the last years. According to Highsmith and Cockburn (2001), the market demands high-quality software and innovation as soon as possible. The Agile methodology responds to this expectation by reducing the cost of software requirement changes. To make this clear, XP requests software development teams to: Produce a deliverable in weeks in order to get customer feedback quickly; Create a simple solution to minimise the quantity of changes (Awad, 2005); Improve design continuously to reduce the next deliverable cost; Test constantly for an earlier and less expensive defect detection (Highsmith & Cockburn, 2001). Also, the Agile software development was influenced by four factors: object-orientation, evolutionary development, internet technologies, and methodology engineering (Strode, Huff, & Tretiakov, 2009). This topic is motivated by the researcher's experience and his strong project management background. He has more than 10 years as an IT project manager, dealing with large-scale multicountry software implementations in both traditional and Agile methodologies. Additionally, the researcher is a member of the Project Management Institute (PMI), the world’s leading project management organization with over 450,000 global members (Project Management Institute, 2017), and a member of the Scrum Alliance which is the largest, most established and influential professional membership and certification organization in the Agile community with more than 500,000 certified practitioners worldwide (Scrum Alliance, 2017b). Additionally, this research has collected relevant information from both Agile transition literature and the Agile project management survey performed for this study. Firstly, the literature review includes current Agile adoption theories which have provided considerable information about the Agile barriers. These works will show some prerequisites, key decisions, transitional frameworks, and several recommendations to overcome organisational, cultural, and structural Agile barriers. Secondly, the Agile project management survey has contributed to this original research by gathering the data which identifies the most important issues that software development companies have to overcome in order to be successful in an Agile transition. The 23 question quantitative and qualitative online survey has been collected information from Scrum masters, project managers, chief executive officers, and IT professionals who have participated in companies that have migrated from a traditional methodology to an Agile methodology.


9

Furthermore, this study explores the Agile concept including its principles and practices. Agility means the ability or flexibility of a company to adapt and change to a new context. This includes short development iterations ranging from two to six weeks where each team can make decisions and adjustments according to the new information and the effectiveness of people working together with goodwill. Also, three of the most used Agile project management methodologies, Scrum, Kanban and eXtreme Programming (XP), are explained. Finally, the proposed research question will be answered. It includes the most important Agile barriers that software development companies have to overcome in order to successfully adopt an Agile methodology and several recommendations to avoid these barriers. The recommendations to defeat the issues was the result of an original research which includes current literature and an analysis of the Agile project management survey result.


10

Research Question This study proposes to answer the following research question: “Which are the most common barriers and how to overcome them during the Agile transition?” The research question outcomes aim to provide relevant information for software development companies transitioning from a traditional approach, such as the SDLC (e.g., Royce, 1987), to an Agile approach. The outcomes will help organisations to understand in advance the barriers to be dealt with and the demands of transitioning to an Agile methodology implementation.


CHAPTER 2: LITERATURE REVIEW

11


12

Literature review Topic background Agility The concept of Agility can be described as the ability or flexibility of a company to adapt and change to a new context. Agility is defined as “dynamic, context-specific, aggressively change embracing, and growth-oriented. It is not about improving efficiency, cutting costs, or battening down the business hatches to ride out fearsome competitive storms. It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share, and customers in the very centre of the competitive storms many companies now fear” (Nagel, Goldman, & Preiss, 1995). Estler, Nordio, Furia, Meyer, and Schneider (2014) state that several IT experts have independently developed methodologies and practices as a reaction to the changes they have experienced. These new methodologies incorporated iterative enhancement, creating the Agile methodologies. Thus, Agile methods put more emphasis on people, interaction, working software, customer collaboration, and change, rather than on processes, tools, contracts and plans. In addition, there is a necessity to provide an evaluation of the effectiveness by using Agile project management methods by further research works (Estler et al., 2014; Awad, 2005). Basic principles Agile methods put emphasis on the working code and the effectiveness of people working together with goodwill. First, the working code shows the team and stakeholders what product they really have instead of a promise of what product they will have. Second, people working effectively achieves speed and cost savings. Team members can share ideas faster face to face than by writing and reading documents, and designers sitting together produce a better design than each could produce by oneself (Highsmith & Cockburn, 2001; Awad, 2005). Agile practices Highsmith and Cockburn (2001), explain that a team is not Agile if the feedback loop with stakeholders is six months. The Agile approach suggests short iterations in a range between two to six weeks where each team can make decisions and adjustments according to the new information. Feature planning and dynamic prioritisation: These short iterative cycles are combined by the Agile methodologies with feature planning and dynamic prioritisation. The fundamental point is the feature plan, instead of a task plan, by using story cards or a product backlog because a


13

feature is what a stakeholder needs and understands. Also, Agile has dynamic prioritisation which allows the customer to change the feature priorities for the next iterative cycle. The Scrum methodology states that the priority order can be modified at the end of a cycle but not in the course of one. Also, Awad (2005) recommends a planning strategy detailed for the next few weeks, a very elemental for the next few months, and an only outlined beyond that. Feedback and change: Agile methodologies suggest a variety of practices for constant feedback on management constraints, customer requirements, and technical decisions because this approach is most appropriate for chaotic, high-change environments. The change is welcomed rather than discouraged. The team and the customer handle the change of feature priorities and requirements accepting that the changes oppose the broad scope, schedule, and costs defined by the management or sponsors. Agile is, therefore, adaptive and change is expected in all stages of the project (Awad, 2005). Also, Patterson and Erturk (2015) explain that the constant feedback and change is beneficial for User Experience (UX) designers. A deliverable working product at the end of each sprint provides response for further product research and user testing to guide upcoming sprints. Focus on teamwork: The Agile methods have team closeness and extreme interaction as an emblem. XP uses pair programming, and Scrum promotes close collaboration practices. Furthermore, Agile development methods require close customer partnerships. However, if customers do not provide appropriate direction, Agile developers will generate low-quality deliverables. Highsmith and Cockburn (2001) add that “Poor customers result in poor systems” (p. 3 ). Comparisons between traditional and Agile methodologies In the context of software engineering and the selection of a methodology, Brooks (1986) states that “there is no silver bullet” (p. 2). This means that always using the same framework, standard or methodology, may not be the best approach for a project. The project manager is the main person responsible for choosing the best option, and this decision is not an easy one. According to Estler et al. (2014), requirements elicitation, design, implementation, verification, and maintenance are aspects that traditionally have been managed with structured processes such as Waterfall, Rational Unified Process (RUP), or the spiral model. These processes focus on defined practices, extensive documentation, and detailed planning and management. However, due to some of the limitations and unsatisfactory features of structured processes, Agile development processes have risen. Agile processes such as Scrum or eXtreme Programming (XP) accentuate the significance of informal communication among developers, and the importance


14

of use-case scenarios developed through iterative implementations. Also, the applicability of structured vs. Agile processes in software development is well-known. The structured methodologies are used for developing software where requirements are less likely to suffer radical changes. On the other hand, when requirements are subject to the more frequent changes Agile process are better due to customers and the team accepting change. According to Augustine, Payne, Sencindiver, and Woodcock (2005), traditional methodologies have linear, sequential processes and are based on an assumption that requirements are stable, known, and consistent. They also explain that Agile methodologies allow project managers, customers, and teams to adapt to changing circumstances rather than by enforcing strict control. According to Davis and Radford (2014), the waterfall is a model completely different to the Agile iterative development process. Waterfall is a sequential development where the outputs of each phase are the inputs of the following phase. Thus, this model has an emphasis in providing 100% certainty to collect all the requirements first and perform the correct analysis to ensure that a re-planning is not going to be necessary. On the other hand, in the iterative life cycle model, the progress evolves iteration after iteration and the requirements and feedback will be collected progressively (Davis & Radford, 2014). It is not necessary to collect all the requirements at the beginning of the project, and probably it is not possible either. According to Hoda, Noble, and Marshall (2008) from the Victoria University of Wellington in New Zealand, differences between the traditional and the Agile software development can be established. Some of them are shown in Figure 1.

Figure 1. Comparative Chart – Traditional vs. Agile (from Hoda, Noble, & Marshall, 2008, p. 2)


15

To received frequent change requests from the customer is a normal experience. The traditional forms of development unrealistically assume that changes will remain fixed throughout the entire project. On the other hand, the Agile methodology has an iterative style of development that expects change requests, and it is focused on managing the associated risks better (Hoda, Noble, & Marshall, 2008). According to Karlesky and Vander Voord (2008), there are frequent project management problems that Agile Project Management (APM) offers a solution to, such us poor estimation, wrong timelines, and lack of interest by users in an almost-done state. Also, Highsmith (2009) states that a product that meets today’s customer requirements will need easy adaptation to future needs. Otherwise, the product will disappear shortly. Highsmith (2009) adds “The formula for success is simple: deliver today, adapt tomorrow” (p. 71).

Scrum Schwaber (as cited in Kniberg, 2007) says “Scrum is not a methodology, it is a framework” (p. 7). Scrum is not going to tell exactly how to do things but is going to provide processes and procedures. It is more a framework than a methodology because not all tools are mandatory. According to James (2010), Scrum is a framework created for incremental product development adopted by self-organizing cross-functional teams. It provides roles, artefacts, rules, and meetings to create and adapt their software development processes. This methodology uses short iterations called sprints to create and deliver a shippable product focused on customer value. Scrum begins when customers need a product or service. It is created focussing on value and the high visibility of the work which starts with a list of characteristics or ideas that the team will transform to a deliverable (Scrum Alliance, 2014). The combination of roles, artefacts and activities are the Scrum framework (see Figure 2):


16

Figure 2. Scrum Framework (from Deemer, Benefield, Craig, & Vodde, 2012)

According to Scrum Alliance (2014), the Scrum roles are: Product Owner who is responsible for the definition and prioritization of the characteristic of their product, Scrum Master who is the guardian of the process and who helps the team and product owner to not lose direction, and Team which develop the product or service, including analysis, design, coding and testing. The development of a product or service is done in sprints of one to four weeks. In general, teams prefer short sprints. At the end of every sprint, the team will release an operating version of the product with features and quality previously defined and agreed (Scrum Alliance, 2014). According to Scrum Alliance (2014), the Scrum artefacts are: product increment which is a deliverable part of the product or service, product backlog which is a prioritised “wish list” of requirements for the product, and sprint backlog what includes the quantity of work for the next sprint. According to Scrum Alliance (2014), the Scrum activities, or meetings are: 

Product backlog refinement: The team perform the estimation of the items and confirm the order of importance.



Sprint planning: A time-boxed meeting which takes about two hours per week. A good quality of product backlog is key for the success of the sprint planning.



Daily Scrum: 15-minute meeting every day where every team member tells what she/he has done since the last meeting, what she/he is going to do from now to the next meeting and the blockers.

The Agile Transition 

17

Sprint review: At the end of the sprint, there is a demonstration of the product increment. The team and stakeholders review it, and the product owner updates the product backlog.



Sprint retrospective: The team reviews how the process was done, identifying issues and improvements.

Kanban According to Corona and Pani (2013), Kanban is a concept related to just in time (JIT) production and Lean which uses the demand rate to control the production rate. The Kanban system includes the following steps: 1. Identify the flow and find the activities. 2. Explicit requirements based on features. 3. Define limited features for each activity, depending on the team composition. 4. Set-up the Kanban board with activities, issues, high-priority features, and bugs. 5. Assign developers to activities and issues related to flow. 6. Determine the format and duration of the meeting such as daily stand-up, planning, review, and customer and product owner meetings. 7. Define how the releases will be delivered. 8. Define the technical processes such as analysis, design, development, testing. 9. Select tools, statistical methods, and diagrams to manage the process. According to Stellman and Greene (2014), Kanban is not a software development lifecycle methodology. Thus, a process has to be already in place so that Kanban can be applied to modify the current process incrementally. Kanban is a procedure for process improvement used by Agile teams which at the beginning have to understand the procedure, and then make improvements. Teams using Kanban focus on eliminating waste from their process. The focus of Kanban is different from Scrum and XP. Scrum focuses on project management: scope, time, and requirements. XP values and practices have focus on software development. Kanban is meant to help a team to improve the way that they build software. Teams have a clear picture of the actions and interactions with other areas involved to develop the software. Thus, they know how to improve by removing waste caused by ineffectiveness and inefficiency. It is called process improvement created by the application of Agile ideas. Stellman and Greene (2014) enumerate Kanban practices. The practices are separated into two groups: the foundational principles and the core practices.


18

The foundational principles are three: start with what you know now, agree to pursue incremental and evolutionary change, and initially, respect current roles, responsibilities and job titles. Then adopt the core practices: visualise, limit the work in progress (WIP), manage flow, make process policies explicit, implement feedback loops, and improve collaboration, evolve experimentally by using models or scientific methods. The six practices can be partially adopted. Thus, teams can gradually increase Kanban procedures in depth (Stellman & Greene, 2014). Kanban for software development teams Nowadays, Agile teams can leverage the amount of work in progress (WIP) to accommodate the team’s capacity. Thus, teams have more flexibility planning options, faster output, and clearer focus (Radigan, 2017). While Kanban foundational principles are timeless and appropriate to almost any industry, Agile software development teams have found success with their application. Contrary to implementing Kanban in a factory, it would not involve physical processes in software teams. The only physical or virtual features that teams have to use are a board and cards. Kanban boards Kanban boards are a tool used by software development teams to visualise and optimise the flow of work. Physical boards are popular among teams. However, virtual boards can be found more useful because their provide traceability, easier collaboration, and accessibility for remote team members from multiple locations. In addition, a Kanban board is a tool that provides full transparency of work and instantaneous communication. Despite the fact that the board can be physical or virtual, its function is to visualise the team’s work and to ensure that all blockers and dependencies are identified and resolved. Three sections can be found on a basic Kanban board: To Do, In Progress, and Done (see Figure 3). However, depending on the team’s characteristics, the board can contain extra sections such as: In Test, To Delivery, or User Acceptance.


19

Figure 3. Basic Kanban Board ( from Radigan, 2017)

Kanban cards The Kanban cards allow team members to track work progress in a visual way. It provides critical information about a feature to be developed, a description of the job completed so far, who is responsible for the feature, and an estimation of the time and effort needed. Thus, team members can see the state of every item and its details to increase focus, traceability, and fast identification of issues.

Extreme Programming (XP) According to Lindstrom and Jeffries (2004), XP is the most widely used Agile methodology which shares the Agile Manifesto values but also defines a set of practices. XP is a collection of 12 software development practices that together have been successful in small teams and in evolving projects. However, there is more than only practices to make XP a successful software development methodology; there are also the XP values: simplicity, communication, feedback, and courage. Focused on business value, a team produces and delivers to the customer a small software with fully integrated releases. Thus, XP teams share a common and simple picture of the system. Beck (2000) who was one of the original signatories of the Agile Manifesto, explains the four values of XP: communication, simplicity, feedback, and courage. Communication: Miscommunication does not happen by chance. A lot of circumstances can generate a breakdown in communications. XP proposes to keep communication flowing by using practices that cannot be executed without communicating, such as unit testing, pair programming, and task estimation. Simplicity: Simplicity does not mean easy. It is to think ahead and to fear the exponential cost of a change curve. For XP, it is better implementing a simple function today and make the change tomorrow if it is necessary, than find a more complicated solution today which may never be


20

used. Simplicity and communication are mutually connected. The more the team communicates, the clearer the need to avoid unnecessary features. The simpler the system, the less the need to communicate. Feedback: The system’s status feedback is significant. It works on different time scales. Firstly, it can be minutes and days such as immediate estimation of user stories or progress tracking. Secondly, feedback also works on the scale of weeks and months such as customers and tester writing functional tests for all use cases or customers reviewing the schedule every two or three weeks and the team adjusting the plan. Feedback works through communication and simplicity. The more feedback the team and customers have, the easier it is to communicate and the simpler to test the system. Courage: It is courageous to take the right coding decision, even when it will break most of the test cases and it will take a whole day to fix it. Sometimes, this is necessary. If the first three values are not in place, their courage is worthless. However, when courage is combined with communication, simplicity, and concrete feedback, it becomes extremely valuable. In addition, good communication, a simple system, and an all green test feedback encourage the team to perform better. Fundamental principles Rapid feedback: An action taken and its feedback is critical happens. Thus, the principle is to get feedback, to interpret it, and to put into the system so that the new learning happens as soon as possible. The business and the team can learn from feedback in days or weeks instead of months or years. Assume simplicity: The team has to try to solve every problem as simply as possible. Traditionally, developers are taught to plan for the future and to design for reuse. On the contrary, XP promotes the simplest solution for today and to add complexity later if needed. Incremental change: Usually, big changes taken at the same time do not work properly. Problems have to be fixed in small increments to make the difference. Embracing change: XP welcomes the change that solves a problem requiring immediate attention. Quality work: XP does not allow the sacrifice of quality. Among the development variables: scope, cost, time and quality, this last one is not free. To work well and to enjoy the work, quality is required to be excellent. XP practices


21

The Planning Game: Planning determines the scope of the next release quickly. It requires the combination of business priorities and technical estimations. Small releases: The priority is to deliver a productive system. Then, there will be new releases in further short cycles. Metaphor: Metaphors guide developers. It tells how the whole system works in a simple shared story. Simple design: the design should be as simple as possible. If extra complexity is found, it has to be eliminated from the system. Testing: XP uses unit tests that are constantly written by software developers. These have to run perfectly for continuous development. Also, customers may write tests to demonstrate that a feature is ready to release. Refactoring: Developers usually restructure the code without changing its behaviour to simplify, improve communication, add flexibility, or remove duplicated code. Pair programming: Two developers work together on the same machine. Collective ownership: All the team members are responsible for the code which can be modified by anyone and anywhere. Continuous integration: The system is continuously integrated and built as soon as a task is completed. 40 hour week: Team members are not allowed to work more than 40 hours weekly. If it is crucial never to work overtime the second week. On-site customer: A real customer has to be part of the team, with full availability to answer questions. Coding standards: The standards help to maintain the code and improve the communication through the code itself.

Theoretical perspectives The theoretical framework and the theoretical perspectives of this research are based on the following theories.

A set of theories based on prerequisites and key decisions


22

According to Gandomani et al. (2013), there are several critical prerequisites for an Agile transformation. Figure 4 shows the prerequisites are business goals setup, addressing training needs, team set up, pilot project selection, and method selection. Also, each company will experience their own Agile adoption process differently because each software organisation has unique factors, management practices, structure, policies, values, and norms. This adoption can be considered as an iterative process based on interactions between company members trying to agree their implementation (Khalil & Khalil, 2016).

Figure 4. Emergence of pre-start-up assessment theory (from Gandomani et al., 2013, p. 3)

Business goals set up: An organisation should have an authentic reason for an Agile transformation. The focus on setting up the business goals and finding a reason for change are critical. Organisations cannot feel the Agile values and principles without clear business objectives (Gandomani et al., 2013). Also, without the key executive decision of keeping an aggressive release date, the transition may be unsuccessful. The managerial decision reinforces the Agile principles of delivering early and frequently (Fry & Greene, 2007). Addressing training needs: According to Gandomani et al. (2013), training is the most important and critical prerequisite. Also, the training should be complete and cover all different roles. Gandomani et al. (2013) add that the training materials depend on the knowledge and experience of each team. However, Agile values and principles should be contemplated for all involved. Furthermore, inadequate training may cause problems such as unrealistic expectations of Agile, low collaboration, and resistance to change (Fry & Greene, 2007; Gandomani et al., 2013). Team set up: The selection of the most suitable members is extremely important. One part of the assessment is to advise team members to choose the right people for starting the transition. Thus, people with different skills, knowledge, and backgrounds became part of the Agile team,


23

providing accessibility, transparency, and ownership to the transition (Fry & Greene, 2007; Gandomani et al., 2013). Pilot project selection: Gandomani et al. (2013) state the importance of choosing the best pilot project for Agile transformation. Thus, project selection may affect the future of Agile in the organisation. Also, there are some risks that need to be avoided, such as seniors who may be waiting for a pilot project failure, or the product owner does not like to be involved in the development (Gandomani et al., 2013). Method selection: This is to identify the appropriate Agile method or methods which depend on business goals, organisational abilities and constraints. Different Agile methods are suitable for different purposes. Managers should decide which methods or practices are the most suitable. However, an organisation can start with a particular method, and later use another, depending on their needs (Gandomani et al., 2013; Khalil & Khalil, 2016). There are additional prerequisites: Focus on the Agile principles: Principles help employees understand the Agile process. The company should put effort into the Agile principles such as communication, empowered teams, continuous improvement, and delivering customer value early (Fry & Greene, 2007; Khalil & Khalil, 2016). Project team needs: Software project teams have to find an approach to deliver customer value to achieve business needs. They should identify issues in their software development process and address them with a set of best practices (Khalil & Khalil, 2016). Agile infrastructure: This is the foundation for the enterprise’s Agility. The Agile infrastructure has to constitute an alignment between Agile practices and the organisational structure and culture. Thus, project managers assess how the organisational structure can support the Agile practices, and how Agile practices fit into the organisational infrastructure. In addition, collaboration tools and training programs have to be implemented to increase effectiveness in an Agile environment (Khalil & Khalil, 2016). Agile project investment and prioritisation: Companies have to decide the amount of resources and the projects or areas in which to invest. Khalil and Khalil (2016) add that the organisation should select the most strategic projects that are ready for Agility. See Figure 5. Automation and integration: An automation suite exists to support the transition. Fry and Greene (2007) found that the team was allowed to run much more frequent check-ins and tests which may have been critical for short development test cycles.


24

Figure 5. The addressed question in Agile key decisions (from Khalil & Khalil, 2016, p. 5)

An Agile framework to define the organisation structure Iamandi, Popescu, Dragomir, and Morariu (2015) summarises the Agile Project Management Framework (APM) which was developed by Highsmith (2009), who contributed to the production of the Agile manifesto. This model considers the Agile advantages along with the disadvantages detected at the application of Agile principles. The framework includes a life cycle consisting of five stages: envision, speculate, explore, adapt, and close. It is an iterative model which preserves the Agile principles. The APM pursues the life cycle according to Agile principles, which include tools, methods, and best practices from traditional project management. See Figure 6.

Figure 6. The APM framework (from Highsmith, 2010, p. 3)

The APM framework defines the Agile organisation structure explicitly. Thus, the approach satisfies one of the major deficiency of Agile models: the lack of correspondence between organisational practices and structures and organisational governance. Also, the framework introduces a useful layer to manage risks: managing Iteration which increases the visibility and the prevention of risks. Additionally, the timeframe is similar to a Scrum sprint, from one to four weeks, by using the same artefacts. Iamandi, Popescu, Dragomir, and Morariu (2015) conclude that APM provides an improved structure compared to the Scrum methodology.


25

The Agile Adoption Framework: The 4-Stage Process Sidky (2007) proposes a four-stage Agile adoption framework which is a structured and repeatable approach designed to guide and assist Agile adoption efforts.

Figure 7. The 4-Stage Process for Agile adoption (from Sidky, 2007)

The framework consists of four processes to determine if an organisation is capable of moving towards Agility and being able to identify which Agile practices the organisation should adopt (see Figure 7). The four stages are: Stage 1: Discontinuing factors. It is necessary to find out the stoppers which can prevent the Agile adoption from accomplishing. Sidky (2007) suggests three types of discontinuing factors. 1. The inappropriate need of Agility: From business or software development perspective, Agile methodologies do not add any value. 2. The absence of executive support: The executive sponsors must support the change in the organisation. Otherwise, the transformation will be non-viable. 3. Lack of sufficient funds: The feasibility of the Agile adoption process is null if funds are not available. Stage 2: Project level assessment. This stage determines the target level of Agility for a particular project. However, identifying a target level does not necessarily mean that that level is feasible. Stage 3: Organisational readiness assessment. This stage determinates the target Agility level that the organisation can achieve. The activities highlight the areas that need some development to adopt an Agile process. Thus, recommendations have to be written by the examiner. The


26

company characteristics usually assessed are: customers, developers, managers, software tools, organisational culture, project management, software process, and the physical environment. Stage 4: Reconciliation. In this final stage, it is necessary to determine the Agile practices to be adopted by reconciling the Agile level for a project defined in stage 2, and the Agile level of the organisation assessed in stage 3. There are 3 possible scenarios during this stage: 1. Organisation readiness level is higher than the Project Target Level. Thus, no reconciliation is needed because the organisation is ready to use the chosen Agile practice for the project. 2. Organisation readiness level = Project Target Level. No reconciliation is needed as well, and the project is achieving 100% of its Agile potential. 3. Organisation readiness level < Project Target Level. Reconciliation is necessary. There are two options for the reconciliation: 

Option 1: Change within the Organization. It depends on the willingness of the organisation to change.



Option 2: Lower Expectations. If the organisation is unwilling to invest time or money, it can adopt only the Agile practices that are within their current capacity.

Obstacles in moving to Agile software development methods According to Gandomani, Zulzalil, Ghani, Sultan, and Nafchi (2013), there are organisational, cultural, and structural barriers for companies who are willing to adapt their process to the Agile approach. Organisation and management related challenges: Organisational structure is influenced by culture and the changing people’s mindset is not an easy process. The transformation from traditional to Agile is helped when the management style changes from “command and control” to “leadership and collaboration”. Thus, the organisation will have adequate flexibility and responsiveness to provide the advantages of cooperation. Also, the project manager role should be modified from planner and controller to director and coordinator by ensuring that the creative ideas are reflected in the final decisions. Furthermore, the documentation is another challenge. Whereas, traditional methodologies are based on heavyweight documentation, in the Agile approach, the documentation is limited. This challenge should be decreased by selecting a knowledge management strategy according to each different level of the organisation. People related challenges: To have success in Agile methods it is necessary to have communication and collaboration between team members. To celebrate some of the Agile methods such as pair programming in XP, managers should select the suitable staff and provide


27

them with mandatory training. Also, customers are another important challenge. Agile practices need the customer as a part of the development team. Customers have a critical role in the success of Agile approaches, and they have to be knowledgeable, committed, authorised, collaborative and responsive. Process related challenges: The traditional approach has processes based on activities and measurement rather than Agile where activities are based on fast support and high-quality development. Thus, the expectation of traditional developers to finding adequate documentation in Agile methods can be confusing. To change the development model from a traditional life cycle to an Agile which is evolutionary and iterative is a complicated and exhausting task because it has an influence on strategies, tools, people and techniques. Also, to choose suitable Agile method can be an issue due to the selection is affected by differences in project size, implementation, priorities, and code ownership. Hence, organisations have to decide their most appropriate Agile method according to their processes. Technology and tools related challenges: The technological issues for migrating to Agile methodologies are less than the others. Companies should implement tools which can support incremental evolution, continuous integration, and version management among others. Also, multi-site organisations have a big challenge. However, implementing the appropriate tools is the best way to use the Agile approach in distributed development environment.

The Agile transition barriers: How to avoid them? The present chapter has conducted literature review, and makes recommendations to overcome the issues collected during the Agile project management survey performed for this study. The survey which has noted the most important Agile transition barriers will be summarised and analysed in Chapter 4.

General organisational resistance to change According to Sahota (2012), it is crucial to understand the organisational culture before initiating the Agile transition. There are two different kinds of cultures to deal with, a mismatched culture or a supportive culture. Adoption of Agile practices in mismatched culture: Sahota (2012) recommends to identify practices that support the dominant culture and to avoid changing them. Agile is viewed as a set of practices rather than a value system. For example, the selection of time box development provides more structure and control to the project. For most Agile experts, this idea of reducing Agile to a set of tools or practices is wrong. Also, Agile is about broking the culture control, not supporting it.


28

Furthermore, it is important to avoid anything that suggests a mindset or culture change such as the Agile Manifesto and Scrum. The discussion of a mindset shift may be confusing and disorienting when the organisation is adopting new practices. The recommendation is to talk about culture together with Agile values and principles. Also, Scrum is a very strong and effective transformative technology. However, it is designed to disrupt existing power and control structures with the creation of new roles such as product owner, Scrum master and the team. Thus, Scrum is not suggested for a mismatched culture but some of its practices can be used in vanilla terms (e.g. Iterations instead of sprints). Finally, Sahota (2012) explains that many companies are not ready for Agile. Hence, supporting an incremental Agile practices adoption would be suitable for a mismatched culture. Adoption and transformation in a supportive culture: It would be naive to think that the cultural alignment of an organisation makes the Agile transformation simple. Generally, there are individuals who do not conform to the overall culture. Agile contributes to making these discrepancies absolutely clear and promoting special behaviours, such as collaboration and visibility. Thus, it is advisable to lead with the Agile manifesto, and Scrum because the culture is already aligned with Agile values. Also, Sahota (2012) recommends the following steps to support an Agile transition: 1. Create a transition team. It will be a Scrum team accountable for the organisational transition to Scrum. 2. An enterprise backlog has to be created for all the transition items. 3. Finally, the team performs Scrum, and it inspects and adapts in every iteration until success. (Schwaber, 2007, as cited in Sahota, 2012) Furthermore, the Awareness, Desire, Ability, Promotion, and Transfer (ADAPT) is suitable for scenarios where the move to an Agile mindset is relatively low. This model has five characteristics: Awareness that the current procedures are not delivering properly; Desire of Scrum adoption; Ability to succeed with Scrum; Promotion of Scrum by sharing lessons learned to show success; Transfer the use of Scrum throughout the organisation (Cohn, 2010, as cited in Sahota, 2012). According to Chan and Thong (2009), a software development methodology (SDM), which can be Agile or traditional, improves the process and product of software development because it promotes the subdivision of the complex process into reasonable and consistent steps. Despite the advantages of using either, Agile or traditional, there is a reluctance to adopt either by the organisation. Chan and Thong (2009) state three possible reasons for the low acceptance:


29

Development team ignore the recently introduced SDM; The new methodology treats the software development process as a methodically arranged procedure when it is not; The methodology is assumed to be universally applicable, but it may be adjusted. Cohn and Ford (2003) state that developers can enjoy producing noncode artefacts due to the cultural attachment which is part of a traditional software development methodology. These team members actively look for opportunities to generate formalised tasks back into the Agile process. Hirsch (2005) shares lessons learned during an Agile transition, and descriptions of typical objections against Agile development from sponsors, business analysts, end users, project managers, and developers. Sponsors may be reticent in buying something that they do not know exactly how much it will cost. Thus, it is necessary to appeal to track record of traditional plandriven projects and explain the similarity with shares investment. Business analysts (BAs) and end users (EUs) have their typical objections as well, such as not enough time, the developers should know this, or they are not taking responsibility for system scope. To mitigate these objections, the recommendation is to verify that BAs and EUs have allocated their needed time, to notify the customers’ role before the beginning of the project, and to assign them the authority to make decisions. Furthermore, project managers (PMs) complain about starting unless they have detailed requirements, and of the difficulty of controlling Agile projects. To beat these objections show PMs their misunderstanding of the Agile process. Lastly, developers have their own objections such as 2-4 weeks is too short time. It will be useful to demonstrate that every team member will permanently work on skills improvement. According to Hirsch (2005), the strongest motivator to perform an Agile transition is the failure in previous software development processes, and the biggest barrier for the Agile transformation is to deal with objections, resistance, and fear of the stakeholders. Also, depending on the organisation size, it will take 1-4 years to achieve a complete company adaptation.

Lack of business/user/customer availability It is not simple to be successful in an Agile transformation when there is no customer involvement. It does not matter if this lack of involvement is generated by the absence of willingness or a reduction in resources such as time or cost. According to Hoda, Noble and Marshal (2011), there is a set of strategies to overcome the lack of customer availability and to proceed with the Agile transformation. Hoda, Noble and Marshal (2011) called the technique: Agile Undercover which has 10 different approaches to defeat this important barrier.


30

Changing customers’ mindsets: It may be challenging to tell customers that there will not be a fixed price as they have come to expect over the past for years or decades. To solve this issue, Agile practitioners discuss the cons of traditional contracts and the pros of Agile development approaches, such as the fast delivery of business value or the prevention of seldom used and expensive functionality due to the prioritisation of features by giving them the control of the product. Providing options: It can be possible to deal with the customers’ expectation of fixed contract by encouraging them to try Agile. It can be doable by offering a certain number of iterations to begin with, as against the opportunity to sign a contract for a large project. After customers have tried a few iterations, they are offered to buy more iterations or required features. Thus, customers are able to see their working software after every sprint, and they have the option of ending the contract. Hence, by providing an option to conclude the contract in the worst case scenario, customer financial risks are covered. Buffering: It is a practical strategy to work with a fix price contract. This technique is based on a rate of development estimation per iteration. By using the team velocity as a guideline, it is possible to estimate how low a set of requirements will take to be developed. Thus, the total of estimated time will be included in a fix price contract. Marshal (2011) adds that Agile is not about asking how much the project will take, but the customer will. Changing priority: The user stories’ priority can be changed in order to maintain the nature of an incremental and iterative Agile project. If these product backlog items are awaiting customer requirements or clarification, the items are held until the team members receive a customer’s response. Thus, Agile teams perform the development of a functionality only if they know exactly what the business wants. Otherwise, they can change the priority of the story in the absence of clear definitions. Risk assessment: It can be used to assess the level of customer involvement in the project. If the indicated level of customer involvement is a potential risk to the Agile project, it is recommended to negotiate that one of the customer team becomes a project team member for the project duration which is the perfect customer collaboration level for Agile projects. Story owners: It is an adaptation of the Scrum’s product owner role. The story owners are responsible for particular stories instead of all the product backlog. Thus, every story or product backlog item has to include an owner to get prioritisation, and the organisation does not have to allocate a single customer for the entire project. The team only needs the story owner for part of an iteration, as against to a product owner for the duration of the project.


31

Customer proxy: This technique uses a team member to collaborate with customers to provide requirements and feedback. Generally, the approach helps when customers are remotely located. Thus, proxies serve the team as a customer by understanding the customer’s point of view and needs and transmitting these to the development team. Just demos: A demonstration is a powerful tool for the Agile team to collect customer feedback. The working software is presented at the end of every iteration and customers are allowed to provide their observations, and the new feedback is incorporated into the next development cycles. In some cases, demonstrations are the only involvement that the Agile team has with the customer who, despite their reservations about the Agile approach, appreciates the working software delivery. Also, demos are useful to get collaboration from sceptical and remote customers. Generally, all customers are interested enough to attend the meeting to see a new version of their product. E-collaboration: Electronic collaboration is a way of communicating with remote customers by using phone, email, chat, or video conferencing. This practice has become more common due to the increasing number of global software projects and remote software development companies. Thus, E-collaboration is important for remote Agile teams because of the following three reasons: regular customer involvement required, difficulty to reach face-to-face collaboration, and e-collaboration is an inexpensive alternative. Extreme Undercover: It is a severe approach with the purpose of avoiding the consequences of a lack of customer/business involvement. The Agile team follows the Agile methodology internally at the team level by keeping the customer unaware. Thus, despite their efforts to convince customers, Agile teams do not discuss the development approach with customers who are opposed to it.

Pre-existing rigid/waterfall framework According to Cohn and Ford (2003), during the transition from a heavyweight process, some developers can be reticent. Thus, it is recommended applying gradualism to make the transition easier. Cohn and Ford (2003) define a set of sprint types to introduce enough formality to help team members see the stage of the current working projects. After the team becomes Agile adept, the sprint types concept can be progressively eliminated. The set of sprint types is: prototyping, requirements capture, analysis and design, implementation, and stabilisation. Dilkert, Paasivaara, and Lassenius (2016) face the significant Agile barrier of a pre-existence of a rigid/waterfall framework by using different procedures.


32

Reverting to the old way of working: According to Dilkert, Paasivaara, and Lassenius (2016), to avoid people working the old way is a major challenge. It can be caused by a schedule pressure of doing the development work and the Agile transformation at the same time. Thus, the large quantity of work can pull team members back to the old way of working. Also, people always look for reasons to revert to familiar behaviour. In some cases, the Agile methodology has been seen as an overhead to abandon it finally. The recommendation to mitigate this Agile barrier is to provide adequate training to development teams to avoid struggling with applying Agile approaches accurately. Using old and new methods side by side: There is an option for organisations which want to proceed gradually with the transformation. It is possible to use the Agile approach in parallel with the traditional approach. This practice can generate some tensions on all levels of the organisation. For example, an ongoing traditional approach project has to be rearranged to fit in the Agile methodology when it is known that in the first instance, the requirements have to be completely detailed, and secondly, the requirements can be defined progressively. Also, there is a gap between long and short term planning: Agile backlogs only provide shortterm visibility, creating a need for long-term visibility. This issue can be attenuated by using the set of sprint types recommended by Cohn and Ford (2003). Management in waterfall mode: After the Agile adoption has been performed, some management continue working according to the old waterfall model. In some cases, management focus on big up-front project plans despite having adopted Agile. To mitigate the issue, the researcher of this research thesis recommends using the buffering approach from Hoda, Noble, and Marshall (2011). In this case, it is necessary to see internal management as an external customer to generate the appropriate report that management need.

Not enough personnel with the necessary Agile experience and development team support According to Dikert, Paasivaraara, and Lassenius (2016), there are three ways to avoid the Agile barriers of not having enough personnel with the necessary Agile experience and the absence of proper development support for the Agile team. Firstly, the option is to provide accurate training to help team members understand the methodology. Secondly, new Agile teams should receive coaching to ensure that the process is followed properly. Lastly, by including staff with Agile experience helps the rest of the team. Provide training on Agile methods: Agile training clearly improves the chances of overcoming a transformation. To achieve an Agile transformation satisfactorily or to fail it can depend on the


33

training received by teams. Also, training improves teams positivism and enthusiasm towards the new Agile approach. Coach teams as they learn by doing: Agile methods do not have an exact manner of working. The coaching of a team, while it is applying the new Agile approach, has been seen as a critical factor for the transition. The main purpose of good coaching is to have the assurance that all process and ceremonies are applied properly and to understand the Agile principles. Furthermore, a coach can be internal or external. Generally, the internal coach will know better the specifics of the organisation and the external coach will have a more objective view of the organisation. According to the Agile survey performed for this research, 40.9 % of those surveyed answered that their companies hired an external consultancy to implement the Agile transformation process. Include persons with previous Agile experience: It is important to start the Agile transformation by including staff with prior experience. These more knowledgeable staff members can help PMO to implement Agile over the entire organisation and provide the rest of the team with a better understanding of the process.

Concerns about a loss of management control and management concerns about lack of upfront planning During an Agile transformation, frequently management have concerns about loss of control and lack of upfront planning. Cohn and Ford (2003) explain these management issues by categorising them into four categories. Firstly, the commitment to the customers and the Agile impact on others groups help to lessen concerns about the loss of organisational control. Secondly, the tracking progress on Agile projects and the definition of the project completion reduce the lack of upfront planning issue. Customer commitments: For some management members, Agile process means that they will not be able to make product commitments, such as delivery date, cost and functionality. However, these members must comprehend that by using a traditional methodology there is no guarantee either. A record of unsuccessful projects would be enough to convince management that the Agile process could provide either a quick completion or fewer use of resources. If there are no project records, a classic explanation of the cost, date and feature triangle can persuade management that the commitments are not realistic. Thus, management will be more interested in the Agile approach. Impact on other groups: Management can be concerned about how the Agile approach can affect other groups. Although management agrees that Agile may benefit the development


34

team, it could affect the work of another group. For example, a software development team is performing an exceptional work by using Agile, but the PMO has finished a detailed requirement specification for a new project and asks the development team how long it will take to develop the entire functionality (Cohn & Ford, 2003). Also, Gregory, Barroca, Sharp, Deshpande, and Taylor (2016) provide the PMO as an example of the Agile adoption impact in the organisation. An inconsistency between the development team and the PMO project report was perceived as a lack of full control by management. Thus, when an Agile process has been introduced into an organisation, management has to understand and agree on the impact on other groups apart of the development team. Tracking progress: It is clear that a traditional project Gantt facilitates management project tracking. However, Agile allows suitable project tracking as well. A project status report has to be included as a task during the Agile iteration. It can include key dates, a burndown chart, some paragraphs with commentary on the project’s state, a list of risks, and key metrics such as defect inflow and percentage of the test passed. Project completion: It is hard to move management from the comfortable position where projects budgets are approved, and projects remain within budget boundaries. On the contrary, Agile project iterations will persist while customers keep identifying more requirements that add value to their product. However, it can be solved by wrapping budgeting and planning activities, such as the previous suggested buffering practice (Hoda, Noble, & Marshal, 2011). The team should estimate the total amount of sprint that the project would take according to the functionality defined.

Insufficient management support According to Dikert, Paasivaara, and Lassenius (2016), several problems can be created by management’s unwillingness to change. It is manifested when the change is emerging from the bottom of the organisation. However, executive support is required to extend the Agile methodology to the entire organisation including the PMO and the quality assurance groups. Thus, if management is not involved in the Agile transformation, the approach cannot be spread throughout the entire company. There are three indispensable instructions to guarantee that management will bring support to the Agile transformation. Firstly, management engagement, support, and visibility are critical for the organisation’s involvement with Agile methodologies. They will have the authority and power to remove any impediments that could block the transformation. Dikert et al. (2016) describe a situation where a number of people argue about the applicability of Agile methods in their organisation, but the


35

objection was overruled by the management because of their commitment to the Agile adoption. Secondly, the visibility of management involvement will motivate and encourage workers to adopt the new methodology. It is recommended that management members organise training sessions personally and visit sprint demos. Thus, if the corporate level supports the Agile methodology, teams will adopt Agile immediately. Finally, educating management is a necessity to gain support for the Agile transformation. Proper education will help management avoid a command and control mode, and it will create strong Agile support. Thus, the training of management will clear misconceptions, and it will help to implement the Agile approach more consistently.

Concerns about the ability to scale Agile The ability to scale Agile is directly related to the organisation’s alignment to the use of Agile methodologies. According to Dikert, Paasivaara, and Lassenius (2016), a key factor to achieve Agile transformation is to create organisational alignment. It is extremely important that the all levels in the company have the willingness to accept the change. Thus, a complete alignment between teams and management is necessary in order to use and scale Agile in a large context. There are Agile methodologies especially created to help companies to achieve the scalability and the correct use of Agile. This means that all levels of the organisation agree and support the Agile transformation, or in other words, that the organisation is completely aligned with the new methodology. The two most popular methodologies to scale Agile are Scrum of Scrums and Scaled Agile Framework (SAFe) (VersionOne, 2016). According to Scrum Alliance (2017a), Scrum of Scrums or meta Scrum is a technique to scale Scrum up to large groups by consisting of dividing the groups into Agile teams between five to ten members. Thus, every Agile team have to select an ambassador who is participating in a daily meeting with the other ambassadors of the organisation. This daily meeting is called Scrum of Scrums. The ambassadors can be technical or management contributors depending on the context. They report completions, next steps, and impediments in a typical daily Scrum meeting. Also, the Scrum of Scrums tracks the items by using its own backlog (see Figure 8).


36

Figure 8. Scrum Of Scrums - Guide to Agile Scaling Frameworks (from Agilest, 2017)

According to Scaled Agile (2017), the Scaled Agile Framework (SAFe) is based on an inflexible number of Lean and Agile principles. These nine principles are fundamental to drive the roles and practices to make SAFe a productive tool (see Figure 9). The nine principles are: 

Take an economic view: It is fundamental to understand the relation among risks, the cost of delay, operational and development costs to support decisions.



Apply systems thinking: Systems thinking needs to be applied to the developed system, the organisation which made the system, and the value stream that produced the system.



Assume variability; preserve options: Multiple requirements and design options can be maintained by Lean developers for a longer period during the development until the uncertainty decreases.



Build incrementally with fast, integrated learning cycles: The development has to be performed by using short iterations which allow the team to collect fast customer feedback and to avoid risks.



Base milestones on an objective evaluation of working systems: In Lean development, an integration point has to provide an opportunity to evaluate the solution.



Visualise and limit WIP, reduce batch sizes, and manage queue lengths: The idea is to achieve a state of continuous flow by controlling the work-in-process, reducing the batch size, and reducing the wait times.



Apply cadence (timing), synchronise with cross-domain planning: This transforms unpredictable events into predictable ones, and provides development rhythm.

The Agile Transition 

37

Unlock the intrinsic motivation of knowledge workers: The provision of autonomy, mission, and purpose, and reducing constraints increases the level of workers’ commitment.



Decentralise decision-making: This reduces delays, improves the flow of developments, and collects faster feedback.


Figure 9. The Scaled Agile Framework (from Scaled Agile, 2017)

38


39

Perceived time and cost to make the transition Management can have a wrong perception of the time and cost of the transformation. It is necessary to show the benefits that Agile methodologies would bring to the organisation and how this approach can reduce costs by avoiding the development of unnecessary functionality. Thus, the Agile transformation can reduce costs rather than increase them. Highsmith and Cockburn (2001) explain that the Agile approach was created as a reaction to the expectation of reducing the cost of software development. Thus, Agile development teams reduced the cost of the software production because of the following reasons: Firstly, teams develop a shippable software version in every iteration in order to get customer feedback promptly; secondly, the changes and their associated costs are minimised by creating simple solutions; thirdly, the cost of the next deliverable version is reduced by continuous design improvement; and finally, the automatised and constant testing allows for defect detection earlier and is less expensive.

Regulatory compliance According to Ambler (2008), all regulations such as the Sarbanes-Oxley Act, Food and Drugs Administration (FDA) statutes, BASEL-II for banking, and aerospace and medical industry standards can increase the documentation and process of software development. Cawley, Wang, and Richardson (2010) add that for the FDA authorisation it is necessary to perform a formal review and approval in all the steps. For example, a company developing a medical device implements a hybrid Traditional-Agile methodology to get the benefits of Agility and to maintain more formality in documentation. In conclusion, a combination of approaches, the Agile and the tradition, can be the solution for Agile adoption in the regulatory environments. The advantages of the Agile software development methodologies can be combined with the formality of the traditional process to support the mandatory standard regulations that companies must follow.


CHAPTER 3: DATA COLLECTION AND ANALYSIS

40


41

The Agile project management survey A 23 question mixed survey was conducted online to collect both quantitative and qualitative data. The aim of the survey is to collect information from Scrum masters, project managers, chief executive officers, and IT professionals who have participated in companies that have migrated from a traditional methodology to an Agile methodology. The significant contribution of this survey is to gather data to help answer the proposed research question: “Which are the most common barriers and how to overcome them during the Agile transition?” The questionnaire includes open-ended questions, rating questions, and multiple-choice questions. The open-ended questions ask the participants to record their ideas in their own words in the space provided. The survey also includes Likert scale questions which ask the participant to rate each factor on a scale. The multiple-choice questions will allow participants to pick a single item among alternatives (Cooper & Schindler, 2014). The individual questions on the survey can be found in Appendix A. The survey has been distributed online through LinkedIn and Google platforms for six weeks and it has collected 107 responses from IT professionals from Argentina, Belgium, Brazil, Chile, China, Colombia, Costa Rica, Dominican Republic, Germany, Guatemala, Honduras, India, Mexico, New Zealand, Nicaragua, Peru, Philippines, Spain, Switzerland, United States, and Uruguay. The findings of the survey are shown below. The survey is divided into two sections. Firstly, it contains questions that are aimed to gather information about the surveyed professionals’ experience and their companies. Secondly, the survey gathers information about the Agile transition and its impact, according to the IT professionals and their experience.

Results section one: IT professional experience The survey presents significant information about Agility. It reveals that 71% of the surveyed are working with an Agile methodology, whereas the other 29% are not. Figure 10 shows that 56.52% of the professionals have a development, technical, or architectural position. The other 12.11% have more responsibility for the customer processes and functional knowledge, for example, as a product owner or business analyst. However, 33.31% are project or program managers, and their understanding are more related.


42

24. 22% Development Leadership

33. 31%

Development Staff Other Product Owner/Business Analyst Project/Program Manager 12. 11%

32. 30% 6. 6%

Figure 10. Current IT professional positions

Figure 11 shows that more than two-thirds of the surveyed professionals work for companies with more than 100 employees. This point needs to be considered in the analysis and conclusions. Because this is an international and heterogeneous sample, it is important to examine results from a company perspective rather than a country perspective. 50 50 45 40 35 30 21

25 20

17

15

9

10

10 5 0 less than 20

from 20 to 49 from 50 to 99

from 100 to 249

more than 250

Figure 11. Company size

The responses summarised in Figure 12 highlight the amount of experience of this group of IT professionals. Most of them (i.e., 68%) have more than 10 years work experience in software development companies. As a result of their strong experience, their responses to the other questions are expected to be very relevant and useful.


43

21%

from 5 to 10 less than 5

11%

more than 10 68%

Figure 12. Years of work in software development companies

Another interesting finding is that more than 52% of the survey respondents indicated that their organisation had practised Agile for a period of less than three years. Therefore, Figure 13 below shows that Agile practices are a relatively new concept for many software development companies.

5%

18% less than 3 years from 3 to 5 52%

from 5 to 10 more than 10

25%

Figure 13. Years of Agile practice in Software development companies

Twenty-nine percent of IT professionals stated they had more than ten years in traditional approaches. Only 4.7% of them have indicated more than ten years with Agile approaches. No Figure is provided in this report for the responses to these questions. However, this finding


44

suggests that IT professionals have had more experience with traditional methodologies during their past career. Figure 14 summarises the responses to the question “Which Agile methodologies have you worked with?” Among IT professionals, the most common Agile methodology is Scrum with more than 81%. The second most commonly used Agile approach is Kanban (39%), and the third one is XP (18%).The respondents were allowed to select more than one methodology for this survey question.

Figure 14. Agile methods used

Results section two: The Agile transition The beginning of this section of the survey, it asked if respondents have ever participated in an Agile transition process. More than 45% answered “yes”. Of this 45 % of participants (i.e., n=49), 35 responded that an Agile transition process took more than six months. On the other hand, 12 answered from one to six months, and only 2 said that the transition took less than a month (see Figure 15).

19

20

16

18 16 12

14 12 10 8 6 4

2

2 0 less than a month from a month to six months

from six months to one year

more than one year

Figure 15. Time required for the Agile transition


45

From those who participated in an Agile transition, 77% agreed that the time response to stakeholders has improved since the Agile approach started. See Figure 16 below.

No 6% Not sure 17%

Yes 77%

Figure 16. Stakeholders time response improvement

Results: The Agile barriers The survey included a multiple choice question with the freedom of choosing more than one option: “Which are the biggest barriers to further Agile adoption?” According to the results, it can be highlighted that most of the survey respondents agreed that the following three items are the most common barriers that companies face during an Agile transformation. See Figure 17 for the percentages. Figure 18 shows the responses to the same question, broken down by the number of respondents, rather than percentages. 

General organisational resistance to change



Lack of business/user/customer availability



Pre-existing rigid/waterfall framework

The next four other important barriers selected by the IT professionals are: 

Not enough personnel with the necessary Agile experience



Concerns about a loss of management control



Management concerns about lack of upfront planning



Insufficient management support


46

# Percentage Barrier 1 65.3% General organizational resistance to change 2 51% Lack of business/user/customer availability 3 51% Pre-existing rigid/waterfall framework 4 40.8% Not enough personnel with the necessary agile experience 5 38.8% Concerns about a loss of management control 6 34.7% Management concerns about lack of upfront planning 7 28.6% Insufficient management support 8 18.4% Concerns about the ability to scale agile 9 18.4% Development team support 10 14.3% Perceived time and cost to make the transition 11 10.2% Regulatory compliance Figure 17. The barriers to Agile, by percentage

Regulatory compliance

5


25

Perceived time and cost to make the transition

7

Other Barriers

7

Not enough personnel with the necessary agile…

20

No Barriers

1

Management concerns about lack of upfront…

17


25


14

General organizational resistance to change

32

Development team support

9

Concerns about the ability to scale agile

9


19 0

5

10

15

20

25

30

35

Figure 18. The barriers to Agile, by number of respondents

The findings for the last three questions of the survey are summarised in Figures 19, 20, and 21 below. They were aimed at determining how some issues may affect the Agile transition process. The three particular issues discussed were: 

The resistance to change



The misunderstanding of the Agile process



The failure to adapt roles

For these three situations, the respondents thought that these issues strongly affect an Agile transition.


47

Figure 19. Resistance to change in the Agile transition

Figure 20. The misunderstanding of the Agile process in the Agile transition

Figure 21. The failure to adopt roles in the Agile transition

Final comments and feedback At the end of the survey, there was an option for participants to write comments. There were 38 left comments after data cleaning was undertaken and 23 comments were removed because they were not relevant or provided no additional information, e.g., comments such as “Nothing”


48

or “No”. Additionally, some comments were in Spanish, but as Spanish is the researcher’s first language, they were translated by the researcher. The themes identified were: 

Agile mindset



Agile methodology



Agile team



Agile project



Training and coaching



Agile literature

The researcher found these comments interesting because the knowledge provided by the surveyed people helped to visualise if this research has been on the right track. The feedback emphasised some of the important issues to overcome the Agile transition such as the importance of both the organisational and customer mindset (e.g., “I think that is not just about changing a methodology, but the mindset. More often than not, teams that try Agile for the first time get it wrong, but that's the whole point of Agile, get better, and try again, is a model for growth and focus.”, “Mindset is key. People should feel that they are working with each other.”, and “Agile is a mindset, not a methodology.”), the understanding of the Agile methodology which has to be provided as well (e.g., “Agile is like any other methodology; you can take practices that add value to your company and discard the ones that are not possible to implement.”, “From my humble point of view, and based on my experience, it is not a good idea to work strictly with a methodology, instead ... we need to use them as a tool and NOT AS A PARADIGM.”, and “To be truly successful requires a full transition.”), the influence of having an Agile and sponsored project pilot in the company (e.g., “The Agile methodology is very practical for the small projects but is very complicated use in big projects.”, and “If your main customer is not Agile minded it is really hard to make an organised and clean transition. We have developed very long projects (+3 years), and we are struggling with our transition for the too long time that Is very easy to lose focus.”), and the relevance of starting the Agile transformation by creating the best Agile team to spread to knowledge into the organisation (e.g., “I think that even when teams adopting Agile may have issues with certain aspects of it, the worst issues come from their misunderstanding what Agile means.”, “It really depends on the software factory and team, but it can be implemented, and it can be a really nice way to make projects work.”, and “My suggesting to the transition is to set up new Agile teams and select people from existing organisation. It is good to filter unqualified people at the initial stage.”). Also, I have been suggested with a high-quality bibliography. This becomes a theme because participants


49

provided bibliographic references, although this is not relevant to answer the research question (e.g., “I think that Agile software development is way better than waterfall methods. I can highly recommend articles of DZone: https://dzone.com/agile-methodology-training-tools-news. Good Books: - Agile Estimation & Planning, Mike Cohn: If you want to read one book on Agile planning, read this one. - Scrum & XP from the trenches, Henrik Kniberg: with practical tips on how to apply Scrum practices in a team. - Scaled Lean & Agile Development, Larman & Vodde: a good book describing Agile concepts.”). According to the comments, the Agile mindset is critical for a successful Agile adoption to understand its importance. If the organisation does not accept that the main point is “to get better and try again”, the transformation can be very difficult. Additionally, some comments emphasise the importance of an Agile beginning on a small project with a transitional team. For some organisation, it can be reasonable for a phased rather than a big bang adoption. However, the characteristics of these two different types of methodology adoption have to be discussed more deeply, and it will require further research. Finally, several comments highlight the weight of providing good training and coaching to the Agile teams (e.g., “Maybe the organisation may consider giving adequate certification for every staff around this Agile methodology as a part of an investment of moving to this new management style.”, “By having insufficient staff for the transition entails the organisation to significant losses.”, and “It is vital to have coaching and the management support to adopt this methodology. I may case, it was useful to have strong customer support due to the good results obtained from a pilot project. Without all these points, it is very hard to perform changes.”). It is clear that it helps organisations to succeed in the Agile transition and it has been included on considerable occasions throughout this study.


50

Discussion To change an organisational working process can be challenging. Software development companies have been trying to improve their performance since the beginning. However, the best approach for this particular business has not yet been discovered. Brooks (1986), the pioneer of software engineering, commented that “there is no silver bullet” (p. 2). However, after years of failures in software development projects by performing traditional methodologies, the Agile methodologies were developed. Agile methodologies have been implemented in software development companies since the Agile Manifesto was written (Beck et al., 2001). It was a response to market demands, such as high-quality software and innovation. Thus, the Agile software development approach has helped software development companies to reduce costs, get customer feedback quickly, create a simple solution, improve designs, and constantly test (Highsmith & Cockburn, 2001). Furthermore, the Agile methodologies present principles that clearly put emphasis on the working code, and team members and customers working together. Also, the Agile practices of feature planning and dynamic prioritisation, feedback and change, and focus on teamwork improves speed and increases cost savings (Highsmith & Cockburn, 2001). Thus, this study addresses the research question: Which are the most common barriers and how to overcome them during the Agile transition? The answer is based on two main components: the Agile project management survey and a literature review. Firstly, the survey has collected the main Agile barriers according to 107 surveyed IT professionals from more than 20 countries. Secondly, the literature review includes six existing Agile transition works and several authors who have investigated and discussed the Agile barriers. Hence, both the conducted survey and the literature review have provided the necessary information to answer the research question. This chapter discusses the literature founded to overcome the issues gathered from the Agile project management survey, and the summary of the most common Agile barriers and their avoidance are shown in Chapter 6 (see Table 1).

The Agile transition theories The following Agile transition theories have provided considerable information to identify some of the Agile barriers. These works show prerequisites, key decisions, transitional frameworks, and several recommendations to overcome organisational, cultural, and structural Agile barriers. Their research was performed in parallel with the release of the Agile project management survey.


51

The pre-start up assessment theory introduces several critical prerequisites for an Agile transition process (ATP). These prerequisites for companies that want to perform an ATP are business goals setup, addressing training needs, the team set up, pilot project selection, and method selection (Gandomani et al., 2013). Also, each company will experience their own Agile adoption process differently because each software organisation has unique factors, management practices, structure, policies, values, and norms. Also, the study explains that there are five key decisions to make for translating their business principles and project needs into Agile principles and practices. These five decisions have to include the domains of Agile principles, Agile architecture, Agile infrastructure, project team needs, and Agile project investment and prioritisation (Khalil & Khalil, 2016). Furthermore, a transitional framework that uses advantages of both the traditional and the Agile methodologies can be used. It includes a five-stage life cycle: envision, speculate, explore, adapt, and close. Iamandi, Popescu, Dragomir, and Morariu (2015) suggest that the approach avoids the lack of consistency between the practices and organisational governance. Additionally, the Agile transformation performed in Salesforce.com can be used to collect several recommendations. The practices to perform are: a definition of a cross-functional rollout team, the implementation of the Agile methods into the entire company all at one time, the hiring of external coaches, the practice of a peer to peer coaching, the creation of successful teams, the creation of a sprint release for the entire organisation, the selection of suitable tools, the emphasis on radical visibility and communication, to be inclusive, and to expect mistakes. All of these practices has helped Salesforce.com to overcome their Agile transition. However, the mentioned practices are not necessarily suitable for all software development companies that want to go through the same adoption process. The clearest example of this is the implementation of the Agile methods into the entire company all at once because it will not always be a viable solution (Fry & Greene, 2007). Moreover, another framework proposes four stages to Agile adoption which determine if an organisation is capable of moving towards Agility and identifying which Agile practices the organisation should adopt. Sidky (2007) states that it is necessary to identify barriers to the Agile adoption. Also, the are classified into three types: The inappropriate need of Agility, the absence of executive support, and the lack of sufficient funds. The current research suggests that there are more Agile barriers that companies have to address before the initiation of the Agile transformation (Sidky, 2007).


52

Finally, there are organisational, cultural, and structural barriers for companies that have the willingness to adapt their process to the Agile approach. The following issues have been identified: Organisation and management, people, process, and technology and tools related challenges (Gandomani et al., 2013). These researchers present high-quality information about the Agile transition. However, none of these provides enough instruction to overcome all Agile barriers that companies have to deal with in order to become an Agile organisation. According to the Agile project management mixed survey performed by this research, there are more challenges to implementing an Agile method than stated in all the previous mentioned studies. The survey has collected more than one hundred responses with relevant information from Scrum masters, project managers, chief executive officers, and IT professionals who have been involved in companies that have migrated from a traditional methodology to an Agile methodology. Thus, these evaluated theories are helpful, but they do not provide enough information. It is this survey that has identified crucial information about the Agile adoption barriers.

The Agile project management survey The Agile project management survey has contributed to this research by collecting the most important issues that software development companies have to overcome in order to be successful in an Agile transition. Figure 22 shows how the 107 IT professionals have answered the question: “Which are the biggest barriers to further Agile adoption?”


Figure 22. The Agile barriers’ bubble chart

53


54

Most of the Agile barriers were not elicited from the Agile transition theories included in the literature review section. It states the important contribution from the Agile project management survey to this research. It is clear that the general organisational resistance to change, the lack of business/user/customer availability, the pre-existing rigid/waterfall framework, and not having enough personnel with the necessary Agile experience, are the most common Agile barriers chosen by those surveyed. However, it will depend on every organisational context which is more relevant. Thus, it is necessary that this present research can address all these issues in order to provide a complete answer to the research question. The following section will discuss all the Agile barriers collected from this Agile project management survey.

The biggest Agile barriers and their avoidance General organisational resistance to change The biggest barrier to the Agile transformation is to deal with stakeholders objections, resistance and fear (Hirsch, 2005). Sahota (2012) states that to avoid organisation resistance to change, it is imperative to understand the organisational culture before the initiation of the Agile transformation. In a mismatched culture, there is a need to identify the practices that support the dominant culture and to avoid changing them. However, Agile is about breaking the culture of control, not supporting it. So, it will be necessary to avoid suggestions of mindset or cultural change and to use some of the Agile practices in vanilla terms, such as iterations instead of sprints. Thus, an incremental Agile practices adoption would be suitable for this kind of culture. On the other hand, in a supportive culture where the organisation is already aligned with Agile values, there is no necessity for incremental adoption. Sahota (2012) recommends the Agile Manifesto and Scrum as a tool to promote special behaviours, such as collaboration and visibility. Chan and Thong (2009) describe that despite the advantages of using a methodology, there is often a low acceptance for the methodology adoption by an organisation. There are three main reasons for this: the development team ignores the new methodology, the wrong idea of the new approach treats the software development process, and a misunderstanding that the methodology cannot be adjusted. In addition, Cohn and Ford (2003) suggest that developers can unnecessarily produce non-code software artefacts because of their cultural attachment with traditional software development methodologies. These mentioned issues have to be overcome by training through an immersion in the new Agile methodology and the use of Agile coaches to avoid losing focus in the process.


55

Another recipe to avoid resistance to change is contributed by Hirsch (2005), who describes the typical objections against Agile development from sponsors, business analysts, end users, project managers, and developers. To avoid the reticence of sponsors, the suggestion is to show the track record of traditional plan-driven projects due to the strongest motivator is the failure in previous software development projects. Also, it is necessary to verify that business analysts and end users allocate the necessary time, to inform the customer's role before the project starts, and most importantly, to assign authority to make decisions. For project managers and developments, it is suggested to train them and to show that team members will permanently work on skills improvement.

Lack of business/user/customer availability The directions given in the literature review seem to be suitable to overcome the lack of business/user/customer availability issue. However, this may not always be so simple. For example, the conducted research by Hoda, Noble and Marshal (2011) describes 10 different approaches to overcome this significant barrier: changing customers’ mindsets, providing options, buffering, changing priority, risk assessment, story owners, customer proxy, just demos, e-collaboration, and extreme undercover. Nevertheless, these approaches do not always agree with the Agile principle of the effectiveness of people working together with goodwill. The different strategies are: Changing customers’ mindsets: Discuss the disadvantages of traditional software development and the advantages of the Agility seems to be appropriate. Providing options: Offer a certain number of iterations to deal with customer expectations of fixed contracts. Buffering: Use the rate of development estimation per iteration to estimate how long a set of requirements will take to be developed and include the total time in the contract. Changing priority: Agile teams initiate the development of a functionality only if they know exactly what the business wants. Thus, the product backlog item waits for customer clarification. Risk assessment: According to the customer involvement potential risk, it is recommended to negotiate that a member of the customer team become a team member. Story owners: Instead of using a product owner, a product backlog can use several story owners who can make it easier to negotiate. Customer proxy: Use a team member to collaborate with customers and provide requirements and feedback.


56

Just demos: Use the demonstrations to get collaboration from sceptical and remote customers. E-collaboration: Electronic collaboration is recommended to get regular and low-cost customer involvement. Extreme Undercover: It is the less recommended alternative because it keeps the customer unconcerned about the use of Agile. These recipes give the impression of being adequate to avoid the lack of business/user/customer availability issue. However, the extreme undercover approach does not seem to be right because Agile practices such as feature planning and dynamic prioritisation, feedback and change, and focus on teamwork, are based on the Agile principle of the effectiveness of team members and customers working together with goodwill (Highsmith & Cockburn, 2001). Also, Agile methods put more emphasis on people, interaction, working software, change, and customer collaboration (Beck et al., 2001; Estler et al., 2014).

Pre-existing rigid/waterfall framework This issue will probably appear in all the Agile transformations. If a company does not have previous Agile or traditional approaches, it means that the organisation does not have a development process at all which is unusual. There are different recommendations to avoid this issue: 

Gradualism: It can be applied to make the transition easier (Cohn & Ford, 2003; Dilkert, Paasivaara, & Lassenius, 2016).



Training: To train development teams to avoid struggling with applying Agile approaches accurately (Dilkert, Paasivaara, & Lassenius, 2016).



Parallelism: The use of sprints which includes the creation or estimation of traditional approach deliverables (Cohn & Ford, 2003; Hoda, Noble, & Marshall, 2011).

The selection of the proper approach among these three options will depend on the organisational management support, resources, and the trust in the Agile methodologies, including their pros and cons.

Not enough personnel with the necessary Agile experience and development team support The examined literature review seems to provide enough information to develop a proper solution for both the lack of enough experienced personnel and the support of the development team. Adequate training definitely improves the chances of successfully overcoming the Agile adoption (Cohn & Ford, metho2003; Dikert, Paasivaraara, & Lassenius, 2016; Gandomani et al.,


57

2013). Team members need to understand the methodology to perform well. Also, it is extremely important to provide coaching because the Agile methods do not always work in the same way. Thus, Agile coaches are necessary to guard the Agile procedures or ceremonies to produce the proper product. However, It is clear that companies have to decide what kind of training and coaching is needed to overcome the Agile adoption. It will depend on variables such as the size of the organisation, or if the entire change is taken at once or by steps. Also, management should agree to the training plan, and provide the proper funding and sponsorship. It means that the solution is also related to another Agile barrier insufficient management support. A proposed solution for this will be presented below. Furthermore, the inclusion of staff members with previous Agile experience can be exceptionally positive. These previously trained people can transfer their Agile knowledge to other team members. Thus, it can solve the training issue by reducing the costs drastically. Nevertheless, it may be difficult to find people with enough Agile experience to teach other team members. Finally, according to the Agile survey performed for this research, 40.9 % of those surveyed answered that their companies hired an external consultancy to implement the Agile transformation process. It is a suitable solution to provide both training and coaching for a reasonable period of time until team members feel confident to perform an outstanding Agile software development process.

Concerns about a loss of management control and management concerns about lack of upfront planning The loss of control and the lack of upfront planning can mean management may be reticent to support the Agile transformation. The literature review has provided some feasible solutions to overcome these barriers. Generally, management places vital importance on the final delivery date, the total cost and the entire scope of a project to be able to sign a contract with a customer. However, it has been explained that, contrary to traditional approaches, the Agile methodologies do not provide a final delivery date and the total cost at the beginning of the project. Also, the management are concerned about how Agile methodologies are able to track the project progress properly. To convince management that the Agile methodologies are an accurate solution, it will be necessary to show them an alternative. Firstly, an analysis of the cost, date and feature triangle and some project records will be enough to demonstrate that a premature estimation of these variables is unrealistic. Secondly, to perform a proper project progress tracking, a project status


58

report has to be developed during the Agile iteration by including milestones, a burndown chart, some paragraph commentary about the project’s status, and risks. Finally, one orthodox solution provided by the literature review, the buffering practice, can be used to wrap budgeting and planning activities, thus, providing the total estimated cost and time. The demonstration of estimation failures in previous traditional projects and the generation of the Agile report are the proper approach to overcome both these Agile barriers. On the other hand, the Agile buffering practice can be considered as unrealistic as the traditional preliminary estimation mentioned above. It is necessary to help management to understand that Agile is not replacing their current process, it is improving it.

Insufficient management support It is extremely hard to perform an Agile transformation if management is unwilling to change. This often occurs when the adoption is emerging from the bottom of the organisation. Executive support is needed to spread the Agile transformation into the entire company. A successful Agile adoption requires a genuine executive support; their engagement and visibility are critical for the organisation involvement with Agile methodologies. Only a management member has the authority and power to remove any impediments that could affect the transformation. The recommendations to avoid these issues are to make management support visible and to educate them on Agile. Firstly, the visibility of management involvement is an important motivation to encourage employees to adopt the Agile methodology. Secondly, management education on the Agile approach will create strong Agile support rather than create a command and control mode. Thus, both an appropriate training for management and the provision of management visibility will help to implement the Agile process. Additionally, the previous guide provided for the Agile barriers of concerns about a loss of management control and management concerns about the lack of upfront planning have to be considered. A precise demonstration of failures in previous traditional projects will be necessary to convince management that the new Agile approach will bring a better software development approach to their organisation.

Concerns about the ability to scale Agile The Agile methodologies have the ability to scale the entire organisation. However, it is impossible to think in the Agile scalability without thinking first about organisation alignment. All levels of the company should have the willingness to accept the change. Furthermore, a complete alignment between teams and management is necessary in order to use Agile in a large context.


59

The literature review shows that there are well-known methodologies to scale Agile in the organisation. Nowadays, the Scrum of Scrums and the Scaled Agile Framework (SAFe) are the most popular to achieve Agile scalability. These two Agile frameworks can be helpful to overcome the inability to scale Agile barrier. However, it is necessary, firstly, to have success in the entire organisation alignment to be sure that the Agile model can be scaled in others groups, once the transition has started, and secondly, the best methodology to scale Agile can be chosen according to company characteristics. Thus, it proves once again that it is extremely difficult to overcome an Agile adoption without the sufficient management support. It may be possible to have a partial Agile transformation if the organisation is suffering a lack of management support, but without the proper management sponsorship, a complete organisation alignment to the Agile methodologies is not possible. Consequently, the Agile scalability can only be achieved by solving the insufficient management support Agile barrier.

Perceived time and cost to make the transition Management may be wrong about the time and cost perception to perform the Agile adoption. To avoid this issue is simple because it is enough to show the benefits that Agile methodologies could bring to the company and the cost reduction by avoiding the development of unnecessary functionality. Thus, it is vital to demonstrate that the Agile transformation reduces costs rather than increases it. Also, to develop a shippable software version in every iteration will collect customer feedback promptly which can reduce the development time drastically.

Regulatory compliance There are regulations that can be an obstruction to achieve the Agile adoption goal such as the Sarbanes-Oxley Act, Food and Drugs Administration (FDA) statutes, BASEL-II for banking, and aerospace and medical industry standards. It can increase the documentation and process on software development. At first, it seems that the solution to overcome this Agile barrier may be to hire staff which can help the team to develop the necessary documentation such as a technical writer. However, it is the traditional methodologies that rely on formal mechanisms to probably address this issue in a better way. Thus, the proposed solution is to use both software methodologies, traditional and Agile. The traditional process provides the formality to support the mandatory standard regulation that companies must follow. On the other hand, the Agile methodologies can provide several advantages such as adaptability, flexibility, quick customer feedback, and reduced cost.


60

Summary of the approach used to address the research question Based on the information collected from the literature review and the Agile project management survey, the research question: “Which are the most common barriers and how to overcome them during the Agile transition?” can now be answered more easily. Firstly, the most common Agile barriers have been obtained from two main sources such as several previous Agile adoption pieces of research and the conducted Agile survey which has been answered by 107 IT professionals. Secondly, the recommendations or formulas to overcome these collected issues have been elicited from an exhaustive search of literature review which includes various databases such as Credo, Google scholar, and ProQuest. Thus, the Agile barriers such as general organizational resistance to change, lack of business/user/customer availability, pre-existing rigid/waterfall framework, not enough personnel with the necessary Agile experience, concerns about a loss of management control, management concerns about lack of upfront planning, insufficient management support, concerns about the ability to scale Agile, development team support, perceived time and cost to make the transition, and regulatory compliance seem to be accurate for performing research. The survey can assure its significance and seriousness due to the following facts. It includes 107 people from Scrum masters, project managers, chief executive officers, and IT professionals answers from more than 20 countries. More than 68% of people surveyed have more than 10 years of professional experience, 71% of them are currently working on Agile methodologies, and most importantly 46% have participated in an Agile transition. By synthesising the information gathered from these sources and methods, the Chapter 4 (conclusions) will also summarise the answer to the research questions and the recommendations for software developers and project managers.


CHAPTER 4: CONCLUSIONS AND RECOMMENDATIONS

61


62

Conclusion Agility has been described as the ability of a company to adapt and change to a new context. As a reaction to the experienced changes, new methodologies incorporated iterative enhancement, creating the Agile methodologies. Thus, Agile methods put more emphasis on people, interaction, working software, customer collaboration, and change, rather than on processes, tools, contracts and plans. The Agile iterative development process is a model completely different to the traditional waterfall methodology. In the iterative life cycle model, the progress evolves iteration after iteration and the requirements and feedback will be collected progressively. On the other hand, Waterfall is a sequential development where the outputs of each phase are the inputs of the following phase. Thus, this model has an emphasis in providing 100% certainty to collect all the requirements first and perform the correct analysis to ensure that a re-planning is not going to be necessary. Despite the clear differences among them, it cannot be stated that one model is better than the other. The proper selection depends on each software development company and their organisational characteristics. The Agile project management survey has shown that the most used Agile methodologies are: Scrum, Kanban, and XP. Scrum is a framework created for incremental product development adopted by self-organizing cross-functional teams. It provides roles, artefacts, rules, and meetings to create and adapt their software development processes. This methodology uses short iterations called sprints to create and deliver a shippable product focused on customer value. Additionally, Kanban is a concept related to just in time (JIT) production and Lean which uses the demand rate to control the production rate. Thus, a process has to be already implemented so that Kanban can be applied to modify the current process incrementally. Lastly, XP is the most widely used Agile methodology which shares the Agile Manifesto values, such as communication, simplicity, feedback, and courage, and also defines a set of practices. XP is a collection of 12 software development practices that together have been successful in initially small teams and changing projects. The literature review includes six significant previous research about the Agile transition. According to Gandomani et al. (2013), there are several critical prerequisites for an Agile transition process (ATP). These prerequisites for companies which want to perform an ATP are business goals setup, addressing training needs, the team set up, pilot project selection, and method selection. Also, Khalil and Khalil (2016) develop a framework which includes five key decisions such as Agile principles, Agile architecture, Agile infrastructure, project team needs, and Agile project investment and prioritisation. Furthermore, Iamandi, Popescu, Dragomir, and


63

Morariu (2015) summarises another Agile Project Management Framework which includes a life cycle consisting of five stages: envision, speculate, explore, adapt, and close. This model balances the Agile advantages with the disadvantages detected at the application of Agile principles. Moreover, Fry and Greene (2007) describe an Agile transformation performed in an American cloud computing company. The key points of the transition were: executive commitment to the change, the creation of a rollout team to promote the change, focus on the Agile principles, automation and integration, transparency provided, and external Agile training and coaching. Additionally, Sidky (2007) proposes a four-stage Agile adoption framework which is a structured and repeatable approach designed to guide and assist Agile adoption efforts. It consists of four processes to determine if an organisation is capable of moving towards Agility and being able to identify which Agile practices the organisation should adopt. The four stages are discontinuing factors, project level assessment, organisational readiness assessment, and, reconciliation. Finally, According to Gandomani, Zulzalil, Ghani, Sultan, and Nafchi (2013), there are organisational, cultural, and structural barriers for companies which have the willingness to adapt their process to the Agile approach. Despite these six theories which provide high-quality information about the Agile transition, there is not enough instruction to overcome all the Agile barriers that companies have to deal with in order to become an Agile organisation. This has been the main motivation for releasing the Agile project management survey performed in this research. The survey has collected more than one hundred responses with general information about Agile methodologies but particularly the Agile barriers. Thus, the survey has brought crucial information about the Agile adoption barriers in order to be able to answer the proposed research question: “Which are the most common barriers and how to overcome them during the Agile transition?”. The answer to this question is elaborated and referenced in the following table:


Table 1. The most common Agile barriers and their avoidance.

# 1

2

Percentage 65.3%

51%

Agile barrier General organisational resistance to change


Recommendation to avoid the Agile barrier

Author

An incremental Agile practices adoption.

(Sahota, 2012)

To use Agile Manifesto and Scrum as a tool to promote special behaviours such as collaboration and visibility.

(Sahota, 2012)

To provide immersion in the new Agile methodology and the use of Agile coaches to avoid losing focus in the process.

(Chan & Thong, 2009; Cohn & Ford, 2003)

To show the track record of traditional plan-driven projects due to the strongest motivator which is the failure in previous software development process.

(Hirsch, 2005)

To verify that business analysts and end users allocate the time needed, to inform the customer of their role from the project start, and most importantly, the assignation of authority to make decisions.

(Hirsch, 2005)

To train project managers and developers and to show that team members will permanently work on skills improvement.

(Hirsch, 2005)

To discuss the disadvantages of traditional software development and the advantages of the Agility.

(Hoda, Noble, & Marshal, 2011)

To offer a certain number of iterations to deal with the customer’s expectation of fixed contracts.


To use the rate of development estimation per iteration to estimate how long a set of requirements will take to be developed and include the total time in the contract.


To initiate the development of a functionally only if they know exactly what the business wants.


To negotiate that a member of the customer team becomes a team member.


To create the story owner role. Instead of using a product owner, a product backlog can use several story owners which can be easier to negotiate.


To use a team member to collaborate with customers and provide requirements and feedback.


64


3

4

5

6

51%

40.8%

38.8%

34.7%




Management concerns about lack of upfront planning

To use the demonstrations to get collaboration from sceptical and remote customers.


To implement e-collaboration to get regular and low-cost customer involvement.


To apply the changes gradually to make the transition easier.

(Cohn & Ford, 2003; Dilkert, Paasivaara, & Lassenius, 2016)

To train development teams to avoid struggling with applying Agile approaches accurately.

(Dilkert, Paasivaara, & Lassenius, 2016)

To parallelise sprints which include the creation or estimation of traditional approach deliverables.

(Cohn & Ford, 2003; Hoda, Noble, & Marshall, 2011)

Providing an accurate training will improve the chances of overcoming the Agile adoption.

(Cohn & Ford, 2003; Dikert, Paasivaraara, & Lassenius, 2016; Gandomani et al., 2013)

To coach Agile teams because the Agile methods do not always work in the same way.

(Cohn & Ford, 2003; Dikert, Paasivaraara, & Lassenius, 2016; Gandomani et al., 2013)

To include persons with previous Agile experience. It is important to start the Agile transformation by including staff with prior experience.

(Dikert, Paasivaraara, & Lassenius, 2016)

To hire an external consultancy to implement the Agile transformation process for providing both training and coaching for a reasonable period of time.

(Fry & Greene, 2007) Agile project management survey

Generating an analysis of the cost, date and feature triangle and some project records will be enough to demonstrate that a traditional premature estimation is unrealistic.

(Cohn & Ford, 2003)

To perform a proper project progress tracking, a project status report has to be developed during the Agile iteration by including milestones, a burndown chart, commentary about project’s state, and risks.

(Cohn & Ford, 2003)

The buffering practice can be used to wrap budgeting and planning activities. Thus, providing the total estimated cost and time.


The same recommendations of concerns about a loss of management control.

65


7

8

28.6%

18.4%


Concerns about the ability to scale Agile

To make management support visible to motivate and encourage workers to adopt the new methodology. The management members should organise training sessions personally and visit sprint demos.

(Dikert, Paasivaraara, & Lassenius, 2016)

To educate management is a necessity to gain support for the Agile transformation. The training on management will clear misconceptions, and it will help to implement the Agile approach more consistently.

(Dikert, Paasivaraara, Lassenius, 2016)

To demonstrate estimation failures in previous traditional projects will be necessary to convince management that the new Agile approach will bring a better software development approach to the organisation.

(Cohn & Ford, 2003)

To create organisational alignment towards the Agile transformation. It is extremely relevant that the totality of levels in the company has the willingness to accept the change. Thus, a complete alignment between teams and management is necessary in order to scale Agile in a large context.

(Dikert, Paasivaraara, Lassenius, 2016)

To implement an Agile methodology especially created to help companies to promote the scalability and the correct use of Agile such as SAFe or Scrum of Scrums.

(VersionOne, 2016; Alliance, 2017a)

9

18.4%

Development team support

The same recommendations for not enough personnel with the necessary Agile experience.

10

14.3%

Perceived time and cost to make the transition

To show the benefits that Agile methodologies could bring to the company and the cost reduction by avoiding the development of unnecessary functionality.

&

&

Scrum

(Highsmith & Cockburn, 2001)

The same recommendations for insufficient management support. 11

10.2%

Regulatory compliance

To combine both the Agile and the traditional approach. The advantages of the Agile software development methodologies can be combined with the formality of the traditional process to support the mandatory standard regulations that companies must follow.

(Ambler, 2008; Cawley, Wang, & Richardson, 2010)

66


67

The conducted survey showed the importance of each of the Agile barriers. Also, the literature review analysis has generated suitable guidance to answer the proposed research question. However, it cannot be asserted that the totality of the Agile barriers can be addressed in this work. It would not be possible due to the scope of this paper. Also, 71 of the respondents are working in large organisations with more than 100 employees. This may affect this conclusion due to the mindset necessary for a large organisation would be different for a small one. Finally, it can be established that the foundation of the present research work is suitable. The appropriate answer to the question: “Which are the most common barriers and how to overcome them during the Agile transition?” has been provided. It is reasonable there is omission of some possible issues that companies can expect to deal with. However, the combination of the survey and the literature review have supplied the most important Agile barriers for software development companies which have the willingness to succeed in an Agile transition. Contribution to the Agile literature This present work titled: “The Agile transition in software development companies: The most common barriers and how to overcome them” has contributed with original information about the Agile IT literature. Firstly, the combination of both the high-quality literature review and the Agile project management survey have brought an interesting conclusion and an accurate answer to the proposed research question: “Which are the most common barriers and how to overcome them during the Agile transition?” Secondly, the current literature about the Agile barriers or issues during an Agile transition or adoption is still insufficient due to the Agile concept, as the study of Agility in organisations is relatively new. Lastly, previous literature is somewhat based on their authors’ own experiences. However, this research has provided different perspectives from a wide range of IT professionals. The collected data was gathered from a large variety of IT positions rather than from only IT managers or Agile evangelists. Recommendations for future research The present research has brought a valuable conclusion. However, it is necessary to go deeper in some aspects. Firstly, the conclusion does not distinguish countries when it can be a relevant characteristic due to the Agile transition may present different barriers in according to a particular culture. Secondly, the organisation size can be another factor that may bring a different conclusion because the size of a company has a direct impact on the organisational culture which most likely affects the barrier’s avoidance. Lastly, a framework which takes into consideration the Agile barriers, the company culture and characteristics such as a phased or a


68

big bang Agile implementation, and the selection of the most suitable Agile project management methodology is proposed (See Appendix C). To develop this requires a doctoral work due to the scope, size, and the necessary commitment to perform a tool with this characteristics. Recommendations for project managers and software developers According to the Agile project management survey, more than 70% of IT professionals are working with an Agile project management method. It is advisable for project managers and software developers to be trained in this methodology due to the future of software development. The Agile approach is still growing, which will bring more opportunities for the IT professionals with the willingness to adopt it. There will be many job opportunities, training and consulting for IT professionals around the world in the near future.


REFERENCES AND BIBLIOGRAPHY

69


70

References Agilest. (2017). Scrum Of Scrums - Guide to Agile Scaling Frameworks. Retrieved from https://www.agilest.org/scaled-agile/scrum-of-scrums/ Ambler, S. W. (2008). Agile software development at scale. Balancing Agility and formalism in software engineering (pp. 1-12). Berlin, Germany: Springer. Retrieved from http://opendl.ifip-tc6.org/db/conf/ifip2/ceeset2007/Ambler07.pdf Augustine, S., Payne, B., Sencindiver, F., & Woodcock, S. (2005). Agile project management: Steering from the edges. Communications of the ACM, 48(12), 85-89. Retrieved from http://www.cs.nott.ac.uk/~pszcah/G52LSS/files/AgileProjectManagement.pdf Awad, M. (2005). A comparison between Agile and traditional software development methodologies. Perth, Australia: The University of Western Australia. Retrieved from http://www.unf.edu/~broggio/cen6940/ComparisonAgileTraditional.pdf Beck, K. (2000). Extreme programming explained: Embrace change. Boston, MA: AddisonWesley. Retrieved from https://pdfs.semanticscholar.org/a8e9/992fbe4b9c90121f8ff2bb22816d37dfebb2.pdf Beck, K., & Beedle, M., & Bennekum, A., & Cockburn, A., & Cunningham, W., & Fowler, M., . . . Thomas, D. (2001). Manifesto for Agile software development. Retrieved from http://www.agilemanifesto.org/ Brooks, F. (1986). No Silver Bullet: Essence and accident in software engineering. Retrieved from http://worrydream.com/refs/Brooks-NoSilverBullet.pdf Cawley, O., Wang, X., & Richardson, I. (2010). Lean/Agile software development methodologies in regulated environments–state of the art. Lean Enterprise Software and Systems (pp. 31-36). Berlin, Germany: Springer. Retrieved from https://pdfs.semanticscholar.org/8df0/e451569760657b08035c5ae613f9ee75a292.pd f Chan, F. K., & Thong, J. Y. (2009). Acceptance of Agile methodologies: A critical review and conceptual framework. Decision support systems, 46(4), 803-814. doi:10.1016/j.dss.2008.11.009 Cohn, M. (2010). Succeeding with Agile: Software development using Scrum. Upper Saddle River, NJ: Pearson.


71

Cohn, M., & Ford, D. (2003). Introducing an Agile process to an organization. Computer, 36(6), 74-78. Retrieved from http://www.torak.com/files/Introducing%20An%20Agile%20Process%20to%20an%20 Organization.pdf Cooper, D., & Schindler, P. (2014). Business research methods. New York, NY: McGraw-Hill. Corona, E., & Pani, F. E. (2013). A review of lean-Kanban approaches in the software development. WSEAS Transactions on Information Science and Applications, 10(1), 113. Retrieved from https://pdfs.semanticscholar.org/0725/482b6ced393863440f7e063c268e3790d18c.pd f Davis, B., & Radford, D.(2014). Going beyond the waterfall. Plantation, FL: J. Ross Publishing. Retrieved from ProQuest database. Deemer, P., & Benefield, G., & Craig, L., & Vodde, B. (2012). The Scrum Primer (2nd ed.). Retrieved from http://www.scrumprimer.org/scrumprimer20.pdf Dilkert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale Agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87-108. doi: 10.1016/j.jss.2016.06.013 Estler, H. C., Nordio, M., Furia, C. A., Meyer, B., & Schneider, J. (2014). Agile vs. structured distributed software development: A case study. Empirical Software Engineering, 19(5), 1197-1224. Retrieved from https://pdfs.semanticscholar.org/bba5/b5bcb35a7d678e2a6ffee8d94d99db7d4474.pd f Fry, C., & Greene, S. (2007). Large scale Agile transformation in an on-demand world. Agile Conference (AGILE), (pp. 136-142). IEEE. Gandomani, T. J., Zulzalil, H., Ghani, A. A. A., Sultan, A. B. M., & Nafchi, M. Z. (2013). Obstacles in moving to Agile software development methods; at a glance. Journal of Computer Science, 9(5), 620. doi:10.3844/jcssp.2013.620.625 Gandomani, T., Zulzalil, H., Javanmardi, A., Ghani, A., Sultan, A., & Nafchi, M. (2013). How prestart up assessment helps software companies in Agile transition. Science International, 25, 1125-1130. Retrieved from Proquest database.


72

Gregory, P., Barroca, L., Sharp, H., Deshpande, A., & Taylor, K. (2016). The challenges that challenge: Engaging with agile practitioners’ concerns. Information and Software Technology, 77, 92-104. Highsmith, J. (2009). Agile project management: Creating innovative products. Upper Saddle River, NJ: Pearson. Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 34(9), 120-127. Retrieved from http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/Agile/IEEEArticle1Fi nal.pdf Hirsch, M. (2005). Moving from a plan driven culture to Agile development. International Conference on Software Engineering, 27 (p. 38). Retrieved from http://icse2011.icseconferences.org/2005/ConferenceProgram/InvitedTalks/Hirsch.pdf Hoda, R., Noble, J., & Marshall, S. (2008). Agile project management. New Zealand Computer Science Research Student Conference, 6, 218-221. Retrieved from https://nzcsrsc08.canterbury.ac.nz/site/proceedings/Individual_Papers/pg218_Agile_P roject_Management.pdf Hoda, R., Noble, J., & Marshall, S. (2011). The impact of inadequate customer collaboration on self-organizing Agile teams. Information and Software Technology, 53(5), 521-534. doi:10.1016/j.infsof.2010.10.009 Iamandi, O., Popescu, S., Dragomir, M., & Morariu, C. (2015). A critical analysis of project management models and its potential risks in software development. Calitatea, 16(149), 55-61. Retrieved from Proquest database. James, M. (2010). Scrum reference card. Retrieved from http://scrumreferencecard.com/ScrumReferenceCard.pdf Karlesky, M., & Vander Voord, M. (2008). Agile project management. Embedded Systems Conference, 247(267). Retrieved from https://www.researchgate.net/profile/Michael_Karlesky/publication/229042037_Agil e_Project_Management/links/5512b1c70cf270fd7e3332b1.pdf Khalil, C., & Khalil, S. (2016). A governance framework for adopting Agile methodologies. International Journal of e-Education, e-Business, e-Management and eLearning, 6(2), 111-119. doi:10.17706/ijeeee.2016.6.2.111-119


73

Kniberg, H. (2007). Scrum and XP from the Trenches. Retrieved from http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf Lindstrom, L., & Jeffries, R. (2004). Extreme programming and Agile software development methodologies. Information systems management, 21(3), 41-52. Retrieved from http://www.nku.edu/~sakaguch/msis655/lindstrom2004.pdf Nagel, R., Goldman, S., & Preiss, K. (1995). Agile competitors and virtual organizations: strategies for enriching the customer. New York, NY: Van Nostrand Reinhold. Patterson, E., & Erturk, E. (2015). An inquiry into Agile and innovative user experience (UX) design. Napier, New Zealand: Eastern Institute of Technology. Retrieved from http://www.citrenz.ac.nz/conferences/2015/pdf/2015CITRENZ_1_Patterson_UXDesig n_v1.pdf Project Management Institute. (2017). Learn About PMI. Retrieved from http://www.pmi.org/about Radigan, D. (2017). Kanban: How the Kanban methodology applies to software development. Retrieved from https://www.atlassian.com/agile/kanban Royce, W. W. (1987). Managing the development of large software systems. Proceedings of the 9th International Conference on Software Engineering (Reprinted from Proceedings, IEEE WESCON, August 1970 p. 1-9. Originally published by TRW) (pp. 328-338). Los Alamitos, CA: IEEE Computer Society Press. Sahota, M. (2012). An Agile adoption and transformation survival guide: Working with organizational culture. Retrieved from http://www.agilesociety.co.kr/news_file/9015_michael%20sahota_tr3.pdf Scaled Agile. (2017). The scaled Agile framework. Retrieved from http://www.scaledagileframework.com/safe-lean-agile-principles/ Schwaber, K. (2007). The enterprise and Scrum. Retrieved from http://fabio.bressler.com.br/archives/public/scrum/The%20Enterprise%20and%20Scr um%20-%20Schwaber%20-%20Microsoft%20(2007).pdf Scrum Alliance. (2014). Core Scrum. Retrieved from http://www2.fiit.stuba.sk/~bielik/courses/tp-slov/scrum/core-scrum.pdf Scrum Alliance. (2017a). Scrum of Scrums. Retrieved from https://www.agilealliance.org/glossary/scrum-of-scrums/


74

Scrum Alliance. (2017b). Who is Scrum Alliance. Retrieved from https://www.scrumalliance.org/about-us Sidky, A. S. (2007). A structured approach to adopting Agile practices: The Agile adoption framework (Doctoral dissertation). Retrieved from http://theses.lib.vt.edu/theses/available/etd-05252007110748/unrestricted/asidky_Dissertation.pdf Stellman, A., & Greene, J. (2014). Learning Agile: Understanding Scrum, XP, Lean, and Kanban. Sebastopol, CA: O'Reilly. Strode, D. E., Huff, S. L., & Tretiakov, A. (2009). The impact of organizational culture on agile method use. System Sciences, (pp. 1-9). IEEE. VersionOne. (2016). 10th annual state of Agile report. Retrieved from http://www.agile247.pl/wp-content/uploads/2016/04/VersionOne-10th-Annual-Stateof-Agile-Report.pdf


75

Bibliography Berry, D. M. (2004). Privacy, ethics and alienation: An open source approach. Internet Research, 14(4), 323-332. Retrieved from ProQuest database. Bulsara, C. (2015). Using a mixed methods approach to enhance and validate your research. Perth, Australia: Brightwater Group Research Centre. Retrieved from http://s3.amazonaws.com/academia.edu.documents/44191076/using_mixed_method s_approach_to_enhance_and_validate_your_research.pdf?AWSAccessKeyId=AKIAIWO WYYGZ2Y53UL3A&Expires=1496362203&Signature=%2B2AhLCF32WXzcJ9Q8f%2Fvmw jtY1Q%3D&response-contentdisposition=inline%3B%20filename%3DUSING_A_MIXED_METHODS_APPROACH_TO_E NHANC.pdf Cohn, M. (2005). Agile estimating and planning. Upper Saddle River, NJ: Pearson Education. Crawley, G., & O'Sullivan, E. (2016). The grant writer's handbook: How to write a research proposal and succeed. London, England: Imperial College Press. Fernandez, D., & Fernandez, J. (2008). Agile project management—agilism versus traditional approaches. Journal of Computer Information Systems, 49(2), 10-17. Retrieved from Proquest database. Gable, G. (1994). Integrating case study and survey research methods: An example in information systems. European Journal of Information Systems, 3(2), 112-126. Retrieved from http://borders.arizona.edu/classes/mis696a/resources/readings/Gable-EJIS-1994IntegratingCaseStudyAndSurveyResearchMethods.pdf Grant, C., & Osanloo, A. (2014). Understanding, selecting, and integrating a theoretical framework in dissertation research: Creating the blueprint for your "house". Administrative Issues Journal: Education, Practice, and Research, 4(2), 12-26. doi:10.5929/2014.4.2.9 Jansen, H. (2010). The logic of qualitative survey research and its position in the field of social research methods. Qualitative Social Research, 11(2). Retrieved from ProQuest database. Larman, C., & Vodde, B. (2010). Practices for scaling lean & Agile development: Large, multisite, and offshore product development with large-scale Scrum. Upper Saddle River, NJ: Pearson Education.


76

Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to Agile methodologies. Communications of the ACM, 48(5), 72-78. Retrieved from http://miklp.free.fr/p72-nerur.pdf Obrutsky, S. (2016a). Agile approach to implementing ECM. Napier, New Zealand: Eastern Institute of Technology. Obrutsky, S. (2016b). Comparison and contrast of project management methodologies PMBOK and Scrum. Napier, New Zealand: Eastern Institute of Technology. Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® Guide). (5th ed.). Newtown, PA: Author. Saunders, M. N., Lewis, P., & Thornhill, A. (2016). Research methods for business students. New York, NY: Prentice Hall. Stacey, R. (2002). Strategic management and organisational dynamics: The challenge of complexity. (3rd ed.). Harlow, England: Prentice Hall. Wyse, S. (2012). Advantages and disadvantages of surveys. Retrieved from http://www.snapsurveys.com/blog/advantages-disadvantages-surveys/


APPENDICES

77


78

Appendix A The Agile project management survey 1. What is your current position? 2. What is your current company size? 3. How many years have you been working in software development companies? 4. How many years have you been in your current position? 5. Can you briefly describe your experience in software development? 6. Does your organisation practice Agile? 7. How long has your current organisation been practised Agile? 8. Can you briefly describe your experience in Agile software development? 9. How many years have you worked with traditional software project management methodologies, frameworks, or approaches? 10. How many years have you personally worked with Agile software project management methodologies, frameworks, or approaches? 11. Which Agile methodologies have you worked with? 12. Have you ever participated in an Agile transition process? Agile transition process: When a company that in the past developed software by using a traditional project management methodology, and now is working with an Agile methodology, such us Scrum, Lean, XP, or any other. If yes continue with 13. If no continue with 20. 13. How much time has the company used for the initial transition process? 14. Please briefly describe what have you accomplished during this transition process? 15. How much total time have you spent on your first Agile project? 16. Would you consider that the time response to stakeholders has improved since the Agile transition process? 17. Which are the biggest barriers to further Agile adoption? You are able to choose more than one option. 18. Please describe another the main transitional issues that you or your company have identified. 19. Have you or your company hired an external consultancy to implement the Agile transition process? 20. In a scale from 1 to 5 with 5 being the strongest. How may the resistance to change affect an Agile transition process? 21. In a scale from 1 to 5 with 5 being the strongest. How may the misunderstanding of the Agile process affect an Agile transition process?

The Agile Transition 22. In a scale from 1 to 5 with 5 being the strongest. How may the failure to adapt roles affect an Agile transition process? 23. Is there anything else you would like to add?

79


Appendix B REAC application approval

80


Appendix C The proposed Agile project management framework for future research

General organisational resistance to change



Issues that software development companies have to deal with if they want to adapt their organisation from the traditional to Agile software development methodologies


Agile Project Management Framework

Transition to Agile Methodologies

Traditional Software Development Company

Initiation to Agile Methodologies

What features need to be included in an Agile project management framework for software development companies to transition to Agile methodologies?

Agile Software Development Company

81

The Agile Transition in Software Development

The Agile Transition in Software Development

Suggest Documents

Agile software development in practise

Agile Software Development in Global Software ...

Agile Software Development in Global Software Engineering

Agile Software Development - SNIP

3 Agile Software Development

Agile Software Development

Agile Software Development - SNIP

Reprioritizing the Requirements in Agile Software Development ...

Agile Capability Development, Assessment and Transition in ...

Agile Software Development Agile UX Work

integrating agile software development with - Agile Alliance

integrating agile software development with - Agile Alliance

Contextualizing Agile Software Development - WordPress.com

Agile Software Development Methodologies

AGILE SOFTWARE DEVELOPMENT ... - Semantic Scholar

Agile Software Development: Novel Approaches For Software ...

Introducing agile software development

agile global software development communication

Lecture 3 – Agile Software Development

Lean/Agile Software Development Methodologies In ... - CiteSeerX

PENETRATION TESTING IN AGILE SOFTWARE DEVELOPMENT ...

Agile Development in Automotive Software ...

Series in Agile Software Development - Google Sites

Series in Agile Software Development - Google Sites