Communication- Encourage communication

Get Complete Project Material File(s) Now! »

Theoretical framework

This chapter aims to synthesize past knowledge on the topic, starting with a history and background of agile methodologies. Later, I perform a critical analysis and a systematic review of the articles and spot the gaps in the literature followed by proposing directions for future research.
My study uses a systematic search approach based on Webster and Watson “Analysing the past to prepare for the future: Writing a literature review “. The authors claim that “A systematic search should ensure that you accumulate relatively complete census of relevant literature.” (Webster & Watson, 2002, p.4; Levy & Ellis, 2006, p.5). The aim is to retrieve the most relevant theory from articles and book chapters. The keyword search has been performed through several databases: Scopus, JU library, ProQuest, IEEE, Research Gate, Elsevier and Google Scholar.

Literature review

The contents of this section focus on the theoretical framework of the thesis. The current overview and situation of the challenges in the agile development transition are studied based on literature review. All aspects of those concepts are researched which helps companies to have in mind the various challenges that can occur in a transition to agile methodologies and practices.
Concerning the quality of all the articles and book chapters in my study, only peer-reviewed papers have been used as Levy and Ellis (2006) suggest. Magazines, newspapers and web-pages have not been used due to lack of theoretical background. All articles are chosen by reading the abstract, introduction and conclusion or by following relevant references in the literature itself. Many articles are chosen exactly because they are referenced in other studies who are important and useful. In total 98 articles are downloaded to create a relevant and qualitative literature review. According to Webster and Watson (2002), a necessary part of a study is the prior review of the literature in the field of study. This gives our work a better understanding of the problem at hand and reveals current and future research directions.
The research in my thesis is performed with the help of various databases and searching with keywords. This research is possible with the help from several databases like JU library, Scopus, ProQuest, Google Scholar and a wide variety of key words such as: transition challenges, agile deployment, barriers in agile development, agile transition challenges. After collecting extensive range of research, the keywords are narrowed down to: Scrum , XP, PM role in agile methodologies, agile development history, deployment of agile methods, agility.

Description, history, predecessors

Agile software development has raised a great deal of discussions within the software development community. Some companies prefer agile methodologies, others fancy traditional approaches and a third category try to mix them. To better understand why and when the right time to transit to agile methodologies in an organization is, the management should be aware of the agile development history and what the methodologies are all about.
A predecessor of agile development is the Iterative Incremental Development (IID) whose history can be traced back to the early seventies. This process is followed by the traditional approach, where each next stage can be executed only if the previous one is completed. Traditional approaches rely on documentation and are characterized as “heavyweight”. When a project is compassed by traditional methodologies, it is necessary to plan and document the whole set of requirements and plan every step of the project. As it turns out in the mid 1990s, managers and developers found this step challenging and unnecessary (Highsmith, 2002). As both sides were delivering projects late and customers were not satisfied, the community developed the agile methodologies in order to embrace change instead of denying it. The official beginning of agile methodologies starts in 2001 on a conference in Utah attended by 17 process experts, where the phrase “agile methodologies” comes from (Larman & Basili, 2003). “Agile with a capital “A” refers to a project management style” (Taylor, 2015). The agile methodologies, also characterized as “lightweight”, consist of short iterative cycles, they rely heavily on customer collaboration and teamwork, there is constant feedback from the client and early product delivery is highly valued (Koskela, 2003). The success of the methodologies is so high, that term “agile” is now a synonym of “flexible manufacturing practices” (Cockburn & Williams, 2003) guaranteeing client satisfaction and quality. The founders wrote the Agile Manifesto (http://agilemanifesto.org/), where the four core values can be found:
• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan.
There are several methodologies that give managers the opportunity to implement agile development in the companies successfully. In the next section, we will explore deeply the most known and used methodology – Scrum, followed by a short description of Extreme Programming (XP), Kanban and Lean.

Agile methodologies

Nowadays, a great deal of organizations state that they have the “agile thinking” or show enthusiasm in transitioning to agile development in their companies. According to a study from Forrester, the IT industry admits that there are numerous benefits of the methodologies and report positive aftermath (Schwaber, 2007). When organisations adopt new agile development practices, managers have to face a large number of challenges when they have to shift from traditional methodologies (Boehm & Turner, 2005). However, it is claimed that it is not uncommon, that some companies are not aware of how broad the transition is and how big changes that must be performed inside the organization. As it turns out, this can be a challenging task (Svensson, 2005). The agile methodologies consist of short iterative cycles whose aim is to prioritize and optimise the actor requirements by counting on the developer team skills and knowledge more, than focusing on documentation. In their core, agile development practices undergo a given number of iterative cycles where the team tests the software several times before delivering a potentially shippable product. The team sets the way of work, the principles and embraces changes instead of performing strict planning. An important part of the project is to grasp the changes by perceiving them as an integral part of the work and how interrelated they are to the constantly changing environment instead of avoiding them and being afraid to accept them. Change in a project should be a motivator to create better software, deliver a stable product and react to fluctuations in the ecosystem for the sake of bringing a greater value to the customer.

Scrum

In Project Management terms, Scrum is identified and differentiated from traditional heavyweight methodologies as “lightweight” and an agile process whose aim is to facilitate software product development in a constantly changing software ecosystem (Cervone, 2011).
A distinguishing part of Scrum is its iterative development whose aim is to control all chaotic aspects that emerge in a team, fix errors, improve communication and coordination. A final goal of Scrum is delivering a stable product faster with improved quality compared to traditional methodologies.
The methodology consists of ceremonies, artefacts and roles (Schwaber, 2004). The roles are the Product owner, Scrum Master and the team itself. The ceremonies include Daily Scrum Meeting, the Daily Scrum of Scrums Meeting, the Sprint Review Meeting and the Sprint Planning Meeting (Cho, 2010). Finally, the artefacts include the Product backlog, Sprint Backlog and Burndown chart. The process starts by reviewing the ROI (Return on investment) and figuring out the milestones of the project, having in mind that changes will come throughout the project. The items with priority are separated as isolated tasks during the Sprint planning meeting which go to the backlog in the end of the meeting. All items in the backlog are done one by one when the sprint starts, and this is repeated through all iterations.
A great advantage for companies when managers use Scrum is its simplicity. They implement necessary factors for success such as communication, iteration, efficiency and great productivity. By decreasing as much as possible the unnecessary bureaucracy and achieving more practicability in terms of management of the project, it is possible for all team members to do a meaningful and productive work (Cervone, 2011).
Even though the methodology is widely used and preferred in the software development community, Scrum has challenges that every manager must be aware of before performing the transition. For all team members, it is better to have a description of what is being done for new-coming developers and share equal knowledge for every member, instead of only one. It is known that the methodology relies on little, and possibly none, documentation. Some developers even consider the code itself as a document, which leads to more comments inside the program used for development (Cho, 2010, pp. 191-192).
Communication is well supported by introducing the Daily Scrum Meetings as it is well known that supporting it is essential for success (Parnas, 2006). Nonetheless, if a company consists of several teams, communication can be a challenging factor for the team and the management. The consequences from lack of communication can be numerous, including duplicated code and unfulfilled requirements, as a result of the lacking feedback from the clients. This also implies that customers should be more involved in the decision-making process from the beginning until the deployment of the product. It is essential that the clients must be aware of what they want and have a vision of the final product so that the developers could work more effectively and efficiently. It is the manager role to involve the clients as much as the team needs to deliver a stable product, otherwise the team loses time because of the lack of communication and information.
Above all, the distinguishing Scrum ceremonies help the team to avoid most of those challenges and be up to date with the development of the product. The daily stand-up meetings might be unnecessary for some developers, a waste of time or too long for others, but it is the manager task to keep the meetings long enough to produce value to the result (Cho, 2010).

 Extreme Programming (XP)

Beck (2000) describes XP as a perfect example of embracing change in an organization while transitioning to agile practices is EXtreme Programming (XP). This methodology is mostly about forgetting old habits which are easily adapted in traditional methodologies. XP is about being able to realize the capabilities that developers have and putting them in use the best way possible. This methodology focuses on excellent understanding and application of programming skills which require perfect communication within the team including constant feedback. This methodology is different than others by its short cycles and continuous feedback, an overall plan which changes during the project, adopting new concepts according to the resulting business needs and constant tests which nurture progress in the development (Beck, 2000).

 Kanban

Kanban is a Japanese approach, which dates to 1950s when it was used in the car industry. In its essence, Kanban is system made for scheduling within the manufacturing (Ahmad, Markkula, & Oivo, 2013). In software development, Kanban was first used in 2004 at Microsoft. The purpose is to give a better visualisation of the workflow and minimize the Work in Progress (WIP) (Kniberg, 2009). This methodology allows customers to review the released software, while the developers focus on the work at hand with the help of “shorter feedback loops”. Kanban has the following principles:
• Visualize the workflow
• Limit Work in Progress
• Make process policies explicit
• Improve collaboratively (using models and the scientific method)
The feedback and results from companies that use Kanban are positive and supportive of the methodology (Ahmad et al., 2013). As a part of the agile development family, this methodology is based on iteration and adapting to changing requirements through its characteristic possibility to visualize all processes and nurturing collaboration and communication (Kniberg, 2009). By limiting Work in Progress, Kanban supports a stable workflow and increases the work performance within the team (Anderson, 2010).

 Transition challenges

In this section I give an overview of the most commonly met transition challenges in the literature that organizations face when they decide to transit to agile methodologies. I will not provide solutions to solve the existing barriers but will highlight them to make companies aware of them in their future agile development transition.

 Communication challenges

This section focuses only on the communication barriers between managers and software development teams, excluding communication between managers and customers or developers and customers.
As we discovered in the previous section, agile methodologies like Scrum and XP are preferred by companies, because they adapt fast to the rapidly changing business environment. Nevertheless, there is little research and a knowledge gap on how they affect communication (Pikkarainen et al., 2008). In most organizations, agile methodologies are preferred because of the fast development of the product and a higher quality when it is been delivered (Holmström et al. 2006). The studied methodologies are also being chosen by managers because they improve collaboration and communication in fast- developing situations where change is critically important for competitive advantage (Anderson, 2003). Malone and Crowston (1994, p. 62) propose a definition of communication which describes the term as “managing relationships between producers and consumers” which in our case is between the management and development team. When we talk about change in development projects, it is essential that we consider communication as a necessary aspect for succeeding (Stelzer and Mellis, 1998).
Although agile methodologies imply that communication is an essential part in the project work, Turner (2003) argues that the actors might give the informal communication a bigger meaning than they should. The author reminds us that after all there are also formal ways of communication, including source codes, test cases and a modest chunk of documentation which are inevitable for every project. Cohn and Ford (2003) suggest that the lack of communication between the project actors, leads to project failure due to the growing void inside companies that transitioned to agile development methodologies.

1. Introduction
1.1 Background
1.2 Problem
1.3 Purpose
1.4 Delimitations
1.5 Definitions
2. Theoretical framework
2.1 Agile methodologies
2.1.1 Scrum
2.1.2 XP
2.1.3 Kanban
2.2 Transition challenges
2.2.1 Communication challenges
2.2.2 Project Manager role
2.2.3 Change in mindset
2.2.4 Organizational agility
2.2.5 Decision making
2.2.6 Documentation
2.2.7 Tools
3. Method
3.1 Case study
3.2 Data Collection
3.3 Data analysis
3.3.1 Quality evaluation of the research design
3.5 Research ethics
4. Results
4.1 Communication- Encourage communication
4.1.1 Demand social skills
4.2 PM role- Facilitate change
4.2.1 Involve planning
4.2.2 Grow transparency
4.3 Change in mindset- Provide training and support
4.3.1 Clear requirements
4.3.2 Eliminate trust issues
4.3.3 Mitigate chaos
4.4 Organizational agility- Change processes first
4.4.1 Transform upside- down
4.4.2 Persuade middle management
4.5 Decision making- Encourage collaboration
4.5.1 Self- organize
4.5.2 Discuss issues
4.6 Documentation and maintenance- Turn documentation to communication
4.6.1 Need of documentation
4.6.2 Innovate documentation
4.7 Tools and technologies- Self- explore
4.7.1 Self- explore
4.8 Themes Developed in the Content Analysis of the Interviews
5. Discussion
5.1 Results discussion
5.2 Implications for practice
5.2.1 Methods discussion
6. Conclusion
6.1 Limitations
6.2 Suggestions for future research
References
GET THE COMPLETE PROJECT