Keywords

1 Introduction

Organizations use various approaches to project management and to the models of conducting the development activities. Throughout history, these models of management have had various forms. The best known since the second part of 20th century up to now is the advance planning and strict adherence with the plan. This model is suitable for developing products in a stable and predictable environment, which however, is not typical for many companies [1]. As the interest in market continues to grow, companies are confronted with three fundamental problems of the product development as (1) continuous acceleration of market evolvement, (2) ability to change, and (3) the increasing complexity of the product [2]. The Fig. 1 below depicts the conditions [3, 4] for the development of products and services in the current unstable environment.

Fig. 1.
figure 1

Current state of the conditions for the development of products and services (own creation according to [3, 4])

Full size image

The speed of development activities is a major challenge for the development teams. The urgency to accelerate the development activities is advocated as well by Menon from a perspective of competitive economy. Menon argues [5] that a shortened product development cycle of a product will result in a competitive advantage. This argument corresponds with a contribution of J.T.Vesey’s, an author of the idea [6] that traditional management practices were based on an idea of “comfortable time constraints”. Experts in such practices were able to consider options and operate on the projects within a budget with low risk. With regards to the global competitive tender, a pressure is being put on managers to shorten the time for introduction of the products to the market.

A change creates new opportunities and it is often a cause for the development of new products. The market during the development of a new product may change. As a consequence of changes, the original specifics of the new product may become obsolete. After launching of a new product on market the other competing companies are forced to revise their plans. In the relation to the product development Stacey proposed a definition of complexity [7]. He claims, “(…) the nature and the number of sub-tasks, their organization and interrelationships, determine the complexity of the project”. He is assessing a certainty of the predictability of the activities needed to carry out the work. The Fig. 2 indicates the three dimensions of the product development:

Fig. 2.
figure 2

Stacey’s Graph (own creation regarding to [7])

Full size image

  • Requirements scale from the very exact, with low risk of changes to vague requirements, followed by expected changes.

  • Technology; very well known and understood and unknown, involving use of multiple technologies and products.

  • People: verified and regular, including a small number of people in the team and the projects with more than five people, sometimes hundreds, that constantly changing [7].

While advance planning and strict adherence to the plan is suitable for projects from the simple quadrant from Stacey’s graph as their exact requirements are known, “Agile” Approach is suitable for solving complicated projects. Agile manifesto [11] presents 12 principles, which should be respected by any agile framework, and considers (1) satisfaction of any customer with the early and continuous delivery of valuable software and (2) responding to change over following a plan. Continuous delivery and response to change is assured by iterative and incremental planning, with product cycles (3) from a couple of weeks to a couple of months, with a preference to the shorter timescale. Agile approach can be mapped to Menon’s [5] argument for shorter product cycles and therefore, its application on value delivery should result in a competitive advantage.

One of the main drivers of “Agile” Adoption Approach is the need to accelerate time to reach the market. Traditional projects struggle to reach the market fast due to their waterfall approach; the funding is ongoing, but the value, in the form of actual product, is delivered only at the end of the project (Figs. 3, 4). The risk of project failure is accumulating and reaching the highest point at the time of the delivery, when the customer gets to review the finished product. Waterfall approach fixes the project scope in the beginning phases of development, which leads to a higher chance of discrepancy between customer expectations and the actual product. In contrary to the waterfall model, agile projects deliver value in iterations and increments and open up the possibility of scope adoption between each increment. Ongoing feedback loop prevents deviations between customer’s expectations and the actual product and thus, the risk of project with each iteration failure is decreasing [8].

Fig. 3.
figure 3

Value delivery in Waterfall projects (own creation according to [10])

Full size image
Fig. 4.
figure 4

Value delivery in agile projects (own creation according to [10])

Full size image

Accordingly, software applications development supported through the agile process have three times the success rate of the traditional waterfall approach, and a much lower percentage of time and cost overruns. The adaptive nature of agile development and openness to changes of the original scope is one of the factors why finished agile projects may rest classified as “challenged” and not be considered “successful” following the methodology used by Standish Group [8–10].

2 The Concerns of Agile Practices Deployment

Change Management methods and tools during an Agile Adoption can play an important role to facilitate changes, in processes as well as in the corporate culture. According to the Lean Change Management [12, 13] the early involvement of people affected by the changes and the barriers between departments and companies have to be addressed by Organizational Change Management. However, the most important factor for success can be found in the role of senior management.

2.1 The Agile Adoption Reasons

The Agile Adoption might address the three challenges mentioned in introductory section [14]. Following statistics are based on the data in the “State of Agile 2015” annual report. The majority of respondents aim to focus on customer and to increase the predictability by the Agile Adoption. The results indicate [15] that after the transition to Agile up to 70 % of the projects got delivered to the customer and reached the market. Earlier than planned by adopting the Agile Adoption a 5 % of the projects reached the market later than by adopting the traditional approach. The Fig. 5 indicates three of the most frequently mentioned benefits of the Agile Adoption, which are (1) accelerate time to reach the market, (2) simplify a management of the changes prioritization, (3) align the IT with the business goals.

Fig. 5.
figure 5

Reason cited for Agile Adoption (own creation according to [15])

Full size image

2.2 The Agile Adoption Failures

A traditionalist mindset [15] was indicated as the greatest barrier in the adoption process, followed by a resistance to change and the implementation of Agile practices in a traditional environment (Fig. 6). A time required to transition to Agile and the budgetary constraints have the negligible impact on the Agile Adoption.

Fig. 6.
figure 6

Barriers to further Agile Adoption (own creation according to [15])

Full size image

The most frequently recorded concern associated with the Agile Adoption, represented by 34 % was the absence of the one-off planning at the beginning of the project. Of losing their position feared 31 % of respondents (Fig. 7).

Fig. 7.
figure 7

Greatest concerns about adopting agile (own creation according to [15])

Full size image

3 Empirical Data Gathering

The initial phase of the research was based on generalizations of the observed reality for the purpose of gaining a deeper insight of the essence of issues. As an outcome of the initial phase an early draft of research questions was created about Agile Adoption and the Agile practices in the software companies. Later on, by logical deductions based on the interviews conducted with the experts in Agile a formation of research questions was instanced as follows; what kind of concerns have you came across when transiting to Agile? Can these concerns be categorized? Is it possible to assess on the basis of the findings resulting from agility’s current state whether the detected concerns were overcame? Data analysis was carried out in two steps. The first part was focused on compiling a comparative overview of the concerns associated with the implementation of Agile. Based on the acquired theoretical knowledge the individual categories were generalized and each of the concerns originated in societies was subsequently incorporated into particular categories. In total, 200 employees from 5 companies were surveyed (Table 1).

Table 1. Overview of 5 surveyed companies (own creation)
Full size table

Data collection process depends on the type of data required. In this case, primarily qualitative nature data are required, since the objective of the research is to uncover the concerns associated with the implementation of Agile. In order to collect qualitative data, the methods such as an observation, a structured questionnaire and open semi structured interviews were used with the target-oriented groups. The Table 2 below shows the identified concerns.

Table 2. The identified concerns categorized and mapped into dimensions (own creation)
Full size table

4 Post-analysis of Detected Concerns

The cases below represent the challenges identified in Chapter 3. The challenges from each case are listed in the Table 2. All challenges are analyzed according to the (1) organizational perspective and (2) viable solutions.

4.1 Case Company A

While the Agile Adoption in company A was the longest from the group, it was still very brief considering the number of employees impacted by the transition. The fear of changing tasks on the fly was based on the lack of understanding of Agile methodologies and self-organizing teams. At the end of adoption, continuous change of tasks was adopted with positive feedback by the team and leaders. Embracement of self-organizing practices leads to a lower workload on managers outside the team and did not lead to a complete loss of control. In the opinion of management and subsequent confirmation of the team members, successful change of the traditionalist thinking of people was achieved thanks to an extensive mentoring program executed by an external coach. External partner was able to dismantle most of the prejudices, and also provide enough clout to navigate around Agile practice adversaries. Since team members were able to see positive results of the change, their motivation was kept high.

Number of projects per employee was decreased as the company feared, but it did not resulted in decreased productivity. Survey showed that self-organized teams were able to focus more on tasks on hand, and were able to work more effectively with less context switching. At the end of the adoption, the company is able to deliver more projects in a year than it was able to deliver in previous period of the same length. Resource management was adjusted according to agile practices, and the company moved from fixed scope to fixed resources budgeting. Contracting practices were also transferred from fixed price contracts to time and means or fixed units where applicable.

4.2 Case Company B

Similar to the case of Company A, presence of a coach on board ensured a smooth transition to Agile and was cited as one of the key factors of success by the management of Company B. Concerns about errors resulting from not splitting requirements into smaller parts prior to the implementation was also based on previous development methodologies, and was proven as unjustified after the transition was complete. Management adapted multi-level planning process, where high-level planning happens on a change advisory board level. Weekly and daily planning activities fall into the competence of assigned product owner, who is also reporting to the CAB if necessary.

Currently the company is going through a phase where if the upper management helps the teams below to adapt mentally to the open culture and survive, and the company slowly begins to move towards enterprise agility.

4.3 Case Company C

Despite its smaller size, Company C was one of the most conservatives in the sample and presented most fears of them all. The young team enthusiastically supported Agile Adoption, but due to continuous malfunction of performed processes, this motivation started to decline. They are currently at the stage where the motivation is being re-gained by the help of an external coach who helps eliminate any discovered issues of concern, which have been confirmed. Initial concerns the management of the freedom of the teams were overcome, and teams are able to organize their work independently without the intervention of higher hierarchy levels. Team leader confirmed that young age of employees is seen as a benefit as it is relatively easy to steer in the right direction as far as for example presentation and social skills are concerned.

Company C was unique where fear of development teams’ insufficient knowledge of the business was presented, but post-implementation survey showed that this fear was not justified. The company was small enough for information to propagate via osmotic methods of communication, and all teams and their leaders confirmed that understanding of the business in not a problem during planning of sprints or during execution of any related planning tasks.

4.4 Case Company D

An initial fear of coexistence of both traditional and agile roles in the company was confirmed. Company D is still dominated by a traditionalist and conservative thinking attitude of individuals, which complicates the deployment of agile frameworks. Strong support of the management board, however, may gradually steer the teams in accordance with agile values and transform the company as a whole. Head of development thinks that promoting positive attitude towards learning on mistakes can motivate all teams to embrace change and reduce the number of opponents to the idea of Agile Adoption on enterprise scale. Teams that started transitioning have mixed feelings, and lack of cooperation and ability to keep the pace up from non-Agile teams is cited as a dominant factor contributing to the decrease of motivation. Actions are to be taken by the head of the development in order to address the issue. Some team leaders are also considering calling on an external partner to help team better organize and reduce the impact of external environment on their work.

Help of external partner is also considered due to increased exposure of team members to external environment. Many team members feel that they are not well prepared to actively participate and give demonstrations during Review ceremonies. The fear of increase in demand for social skills was indeed confirmed in these cases, but new head of development is willing to invest in the employees once the environment is prepared to absorb these changes. Estimation and planning process underwent only minor changes at the moment, as majority of the organization is still running with fixed scope projects in mind. Agile teams see this as a roadblock, as their projects can’t be considered Agile when parts of the scope are fixed beforehand.

4.5 Case Company E

Company E was a very strong organization with a clear direction and very clear vision of enterprise agility and along with Company B lowest number of fears of the implementation. Transition to Agile has lead to the shifting of roles, but did not result in employee dismissals. Leaders became scrum masters, or were assigned different duties in supporting teams. Those who did not possess sufficient knowledge required for the servant-leader role participated in training and coaching programs. As management stated, the overall training time was longer than expected and indeed confirmed their initial fear, but trainings provided by an external partner proved to be very effective and were one of the key factors that helped them achieve positive adoption results.

5 Conclusion

The answers to the research questions are not trivial, because they contain several aspects, which are tied up to each other. Diversity of the detected fear of Agile Adoption carries in itself a meaning in relation to the development teams and the company as a whole. Some sections are explicitly linked to the activities of the development teams and the others are linked to the implementation of Agile into the traditional environment. For the purpose of understanding the complex diversity of the detected concerns, these were categorized into dimensions. After mapping all the concerns there was created a separate category “Agile in the traditional organization”, which is not included in and does not explicitly flow from the Agile Manifesto. The existence of the mentioned concerns relevant from the perspective of individual companies have been demonstrated. Although their occurrence in organisation in some cases has slowed or interrupted Agile Adoption, it was not a barrier that would stop this adoption process. A systematic cooperation of a coach and a management teams bridged almost all arising conflicts of the Agile Adoption process.