Insights into the Perceived Benefits of Kanban in Software Companies: Practitioners’ Views

  • Muhammad Ovais AhmadEmail author
  • Jouni Markkula
  • Markku Oivo
Open Access
Conference paper
Part of the Lecture Notes in Business Information Processing book series (LNBIP, volume 251)


In the last decade, Kanban has been promoted as a means for bringing visibility to work while improving the software development flow, team communication and collaboration. However, little empirical evidence exists regarding Kanban use in the software industry. This paper aims to investigate the factors that users perceive to be important for Kanban use. We conducted a survey in 2015 among Kanban practitioners in the LeanKanban LinkedIn community. The survey results consist of 146 responses from 27 different organisations, with all respondents being experienced in using Kanban. The results show that practitioners perceived Kanban as easy to learn and useful in individual and team work. They also consider organisational support and social influence to be important determinants for Kanban use. Respondents noted various perceived benefits for using Kanban, such as bringing visibility to work, helping to reduce work in progress, improving development flow, increasing team communication and facilitating coordination. Despite the benefits, participants also identified challenges to using Kanban, such as organisational support and culture, difficulties in Kanban implementation, lack of training and misunderstanding of key concepts. The paper summarises the results and includes a discussion of implications for effective deployment of Kanban before describing future research needs.


Kanban Lean Agile Use Adoption 

1 Introduction

In the last two decades, Agile and Lean approaches have gained wide acceptance in the software industry. In this realm, Kanban emerged in 2004 with a strong practitioner-driven support movement [3, 4], and today, Kanban is increasingly adopted to complement Scrum and other Agile methods. Kanban tends to focus on fast production, rapid and continual user feedback and interaction [1].

Used for controlling the logistical chain from a production point of view, Kanban was developed and applied in the Japanese manufacturing industry in the 1950s [1]. Kanban’s success in the manufacturing industry has convinced software engineers to adopt this approach, with practitioner-driven support furthering this trend. In 2004, David Anderson introduced Kanban to a small IT team at Microsoft, aiming to help the team members visualise their work and put limits on their work in progress (WIP). Kanban has five underlying principles [7], the so-called Kanban properties [10]: visualise the workflow, limit work in progress, measure and manage flow, make process policies explicit and use models to recognise improvement and opportunities.

The motivation behind visualisation and limiting WIP was to identify the constraints of the process and to focus on a single item at a time. Additionally, instead of pushing work on to software developers, Kanban promotes a pull approach: when a team member finishes an existing task, he or she automatically pulls the next item to begin work. In brief, Kanban aims to provide visibility to the software development process, communicate priorities and highlight bottlenecks [5]. This process results in a constant flow of releasing work items to customers, as the developers focus only on a few items at a given time [6]. The proliferation of Kanban in software engineering boomed after the publication of key books. These seminal books included David Anderson’s Kanban [10], which introduces the concept of Kanban in systems and software development, and Corey Lada’s Scrumban [23], which discusses the fusion of Scrum and Kanban. The key motivation for Kanban use involves a focus on flow and the omission of the obligatory iteration cycles in Scrum.

Kanban has received considerable attention from some organisations; others remain reluctant to adopt it. So far, there have been few scientific studies [1, 6, 33] addressing Kanban usage in software organisations, and none of the existing studies report on practitioners’ perceptions of it. Earlier Kanban studies report a number of challenges in its use and adoption, such as organisational, social and technical issues. These studies introduce Kanban as a new way to develop software and systems. Research is still required to identify factors that might influence its effective usage in organisations. Therefore, this study aims to investigate factors that practitioners deem to be important in Kanban use. Conducted in 2015, the study includes Kanban practitioners from the LeanKanban LinkedIn community. LeanKanban is one of the biggest social media communities of professionals who use Kanban at their organisations.

The remainder of the paper is organised as follows. Section 2 explains the research strategy and data collection method, while Sect. 3 provides the results. Section 4 presents validity threats before moving into Sect. 5, which concludes the paper with recommendations for future research.

2 Research Strategy and Methods

In this section, we first introduce the theoretical model adopted as a basis for designing the empirical research. The discussion continues with the survey design and data collection process.

2.1 Theoretical Model

As shown in Fig. 1, we adopted Dybå et al. [8] model which is an extension of Riemenschneider et al. [9] research model in order to explore practitioners’ perceptions regarding Kanban use.
Fig. 1.

Conceptual model

Riemenschneider et al. [9] explain software developers’ acceptance of methodologies by comparing five well-known and established theoretical models: the Technology Acceptance Model (TAM), TAM2 (an extension of TAM), Perceived Characteristics of Innovating, Theory of Planned Behaviour and Model of Personal Computer Utilisation. Dybå et al. [8] extend Riemenschneider et al.’s [9] work by incorporating measures of organisational support. The model derives its theoretical foundations by combining prior research in technology acceptance [11, 12, 17] with aspects of innovation diffusion theory [16] as well as empirically-tested research on software developers’ acceptance of methodologies [9]. The model contains five constructs: perceived usefulness, perceived ease of use, perceived compatibility, subjective norms and organisational support.

Perceived usefulness is defined as the degree to which a person believes that using a particular system will enhance his or her job performance [9], which is similar to Rogers’ [16] perceived relative advantage [15]. Software developers generally receive reinforcements for good performance through raises, promotions and bonuses. In this study, perceived usefulness with respect to Kanban implies that a user believes that there is a positive user-performance relationship. The existing research provides evidence that perceived usefulness affects behavioural intention and actual use [9, 11, 12, 13, 17]. This pattern has also been confirmed within the software engineering domain [9]. Perceived ease of use refers to the degree to which a person believes that using a particular system will be free of effort [9]. Riemenschneider et al. found that ease of use played an insignificant role in software developers’ acceptance of methodologies [9]. However, perceived ease of use recurs in several studies as a significant determinant of adoption behaviour [9, 12, 17, 19]. In this regard, compared to other Agile methods, Kanban is perceived to be easier to use and less complex. According to Rogers, perceived compatibility refers to the degree to which an innovation is perceived as being consistent with the existing values, needs and past experience of potential adopters [16]. Rogers further proposes that compatibility positively relates to the diffusion of innovations [16], making it a significant factor in explaining software developers’ acceptance of methodologies [9, 30]. Thus, a positive perceived compatibility may lead to favourable attitudes toward Kanban use. Subjective norms represent the degree to which software developers believe that others who are important to them think that they should use Kanban. This factor implies that the perceived social pressure to perform the behaviour will influence a person’s intentions [3], and some studies indeed demonstrate its importance [9, 13, 17, 18]. Thus, there is reason to believe that peers may influence Kanban use. Research has also noted the importance of organisational support, the degree to which change agents promote or support efforts, as a factor in explaining an innovation’s rate of adoption [14, 16, 29]. Studies therefore suggest that there is reason to believe that organisational support assists in Kanban use.

2.2 Survey Design and Data Collection

Sampling and Population: For the study, we targeted a global population of Kanban practitioners, sending out the survey to a Kanban practitioners group on LinkedIn, administered by LeanKanban Incorporated. The population includes approximately 2000 software industry practitioners using Lean and Kanban in their work.

Prior to administration, we pre-tested the survey with three experts from the software industry and three researchers. On the basis of this feedback, we revised the statements to have clearer wordings. At the beginning of the survey, participants were provided information about the purpose of the research and its benefits as well as information about the researchers. After revision, the survey was launched and remained open for one and a half months, between 20 June and 20 July 2015. During that time, 148 responses were received. Two of these responses were discarded because the participants were not using Kanban. These omissions left us with a total of 146 responses, forming the data for analysis. The survey consisted of three sections:

Demographics: This part captured information about the respondents in terms of their organisations, Kanban experience and type of training received.

Factors affecting Kanban use: The factors affecting Kanban-use questions were based on previous studies [8, 9], but adapted to the particular context of this study. All of the variables related to the model’s five factors were measured using a five-point Likert-type scale, ranging from 1 (strongly disagree) to 5 (strongly agree). Survey questions are provided in the Appendix.

Benefits and challenges of using Kanban: Questions regarding Kanban benefits were formulated based on previous studies [1, 6]. A five-point Likert-type scale was used to ask the respondents to rate the significance of particular benefits to their organisations. Further, in open-ended questions, the respondents could explain the obtained benefits and challenges faced in Kanban use.

The data analysis was conducted through descriptive statistics. Before the analysis, the reliability of the factor construct measurements were analysed with Cronbach’s alpha.

3 Results

The collected data set included 146 responses: 92 were from North America, 22 from Europe, 4 from Australia, 1 from South Korea and 1 from Russia. 26 respondents did not specify their country. The majority of the respondents came from North America (62.9 %). The respondents were from 27 different organisations, but 17 of the respondents failed to specify their organisations.

Most of the organisations were involved in software (n = 115) or IT services (n = 13). Other represented industries included telecommunication (n = 1) and hardware manufacturing (n = 1). Sixteen of the respondents did not identify their company’s primary business. Most respondents belonged to big organisations (72.6 %, more than 250 employees); the rest worked for middle size (11 %, number of employees between “50–249”) and small (13.7 %, number of employees between “10–49”) organisations. Very small organisations or start-ups with 10 or less employees represented 2.7 % of the population.

Respondents’ main organisational roles involved work for software development teams (n = 63) and first-level management (n = 33). Table 1 presents the respondents’ Kanban training type, and Table 2 illustrates their level of Kanban knowledge.
Table 1.

Respondents Kanban training

Training type (n = 146)



No training






Peer mentoring



1–4 days training



More than 4 days training



Table 2.

Responds Kanban knowledge

Knowledge level






Advance beginner












The majority of the respondents received (n = 88) Kanban training ranging in duration from 1–4 days (n = 61) to more than 4 days (n = 27). Only 10 respondents had no formal training but gained familiarity with Kanban. Most respondents use Kanban on most or all organisation projects (68.8 %). 23.9 % have used it for a few projects, and only 8.2 % have used it on an experimental basis.

We performed a reliability analysis to test the reliability of scale constructs [27] using Cronbach’s alpha, which measures the internal consistency of the factor measured by different variables. Table 3 demonstrates that the reliability of the factor measurement is high; the Cronbach alpha value varied between 0.763 for subjective norms and 0.941 for perceived usefulness.
Table 3.

Results of the factors affecting Kanban use

Constructs (n = 146)







Perceived ease of use

Easy to learn




High reliability

Does not require a lot of mental effort



Clear and understandable



Easy to use



Useful in my job




Excellent reliability

Perceived usefulness

Improves my job performance




Increases my productivity



Enhances the quality of my job



Makes it easier to do my job



Overall using Kanban is useful in my job



Perceived compatibility

Compatible with all aspects of my work




High reliability

Fits well with the way I work



Compatible with the way our team organises work



Subjective norms

People who influence my work think that I should use Kanban




High reliability

Co-workers think that I should use Kanban



Organisational support

Specialised Kanban training is available




High reliability

Written Kanban instructions are available



Management provides necessary help and resources



Attitudes towards Kanban are quite positive among Kanban users, with an average of around 4 for all variables related to perceived ease of use, perceived usefulness and perceived compatibility. Perceptions of subjective norms and organisational support appear to be somewhat lower, with averages of 3.7 and 3.6, respectively.

The high average for perceived ease of use variables indicates that Kanban practitioners have a positive attitude towards using Kanban because it does not require a great deal of mental effort to learn, and it is easy to use in their work. Previous studies have reported similar findings regarding software development methodologies [9, 13].

The respondents perceived that Kanban is useful in terms of improving their job performance, productivity and quality of work. This finding aligns with prior research [9, 13]: when new methodologies and practices are perceived as enabling job performance, they are more likely to be used and adopted. Respondents perceived Kanban as compatible with how they organised their individual and team work. Previous empirical studies have verified the importance of perceived compatibility in development methodologies [9, 13, 30]. The emphasis on teamwork in software development creates social pressure on individuals. Kanban software development teams emphasise collaborative work, which may bring about social pressure at the individual level. Therefore, practitioners are more likely to adopt Kanban when the subjective norms for use are strong. Some studies have found subjective norms to be significant [9, 20], while others found them to be insignificant [8, 13]. In this study, the participants’ responses were positive in regards to subjective norms. The respondents were also positive in their responses regarding organisational support. They noted that their organisations provide necessary resources to support Kanban use, including training and written Kanban guidance documents. The literature shows that organisational support, such as external training and consultation, plays an important role in the use of Agile methodologies [20]. Training brings fresh perspectives to software industry practitioners while enabling their use of Kanban. Studies suggest that training positively affects individuals’ beliefs about the perceived compatibility of an innovation [20, 31]. Because methodology training is the key to successful implementation [28], Kanban adoption is more likely to be successful with organisational support.

3.1 Kanban Benefits

As presented in Fig. 2, the Kanban practitioners rated the significance of particular benefits [1, 6]. Respondents further explained their obtained Kanban-use benefits with the help of open-ended questions.
Fig. 2.

Kanban benefits (Color figure online)

The top two benefits were improved visibility of work and improved development flow, findings verified in previous studies [1, 3, 5, 6, 10]. Respondents elaborated as follows:

The most important benefit is how the visualization of your workflow increases the need for continuous improvement”.

Kanban provides a very large increase in the ability to identify and minimize impediments as well as allow the team to self-swarm and work to bring resolution to potential trouble areas”.

Benefits from Kanban include quicker identification of issues, bottlenecks, etc., of our processes, thus creating performance evaluation, control and continuous improvement opportunities for our development teams”.

The third identified benefit of Kanban is that it helps to reduce WIP. It forces team members to work on a limited number of tasks at a given time, which reduces their mental stress and leads to faster completion of tasks. Respondents further explained as follows:

“Working on one story at a time reduces the stress”.

“Limiting work in progress makes it much easier for the team leaders to see what is happening in the team at any given moment in time. Before with a large amount of WIP, it was very hard to keep track of who was working on what and how each of our feature groups were progressing. Also, limiting WIP and focusing on our oldest stories has helped us to dramatically control our cycle time”.

When WIP limits are reduced, the teams work on smaller chunks that can be completed more easily, a finding also reported in previous studies [1, 3, 5, 6, 10]. A respondent expressed his or her team experience as follows: “[With Kanban, it is] easier to get smaller work items done. We had the problem that smaller items didn’t get worked on because the development team only concentrated on the larger products as directed by the product team. By splitting large work items up into smaller [pieces] we could get the smaller work items through as well”.

Finally, Kanban helps to improve communication and collaboration inside the teams and with related stakeholders. The respondents explained that Kanban “improves communication with the customers and other stakeholders, helps to collaborate and find solutions, improves the knowledge about the processes collecting data and using metrics”. The teams work collaboratively on tasks and find solutions for any impediments, which is a sign of team self-organisation.

3.2 Challenges in Kanban Use

In an open-ended question, respondents shared challenges in using Kanban in their organisation. These challenges are organised in three main categories.

Lack of proper training and misunderstanding of Kanban is a major challenge in its use. Surprisingly, the respondents demonstrated positive attitudes towards organisational support variables in the adopted research model. This finding could be due to the fact that respondents mentioned that co-workers usually teach Kanban’s key concepts and ways of working within organisations. This mentoring process can transfer bad habits and misunderstandings of Kanban’s key concepts. One respondent explains, “It (Kanban) is mostly taught through peer reviews and co-workers. If a set of people have a bad habit, that habit is often duplicated by those they train”.

Other respondents made these statements:

Kanban is very often misinterpreted and seen only as having work items visualised and progressed through on a board”.

The biggest challenge I face is the lack of knowledge and understanding about what Kanban really is and the technical aspects of how to do it. Many people think they know but they really don’t know anything about it. So demystifying it for them has been an on-going and challenging issue”. Interestingly, similar challenges have been reported in earlier studies [1, 5, 6, 25].

Organisational culture and mind set is the second major challenge mentioned by respondents. They noted that management is quite busy and fails to devote attention to improving work processes. Further, there is mind-set challenge because managers prefer to use traditional methods, resisting the new way of working. Similar to other Agile methods, Kanban faces challenges in organisational culture and people’s mind-sets [1, 5, 6, 25]. Respondents mentioned the following:

Time is not reserved for improving ways of working” “People and management are too busy to improve, resulting in not caring about process management methods. Some managers still prefer Microsoft projects and traditional methods”.

Silos are created by top management and defended by middle management. Upper management seems hesitant to adopt Kanban”.

Many people are resistant to change; there is a lack of proper culture and management involvement and commitment”.

Difficulties in Kanban implementation can be linked to a number of other challenges. For example, the respondents noted that there was a lack of proper planning before introducing Kanban to teams. With poor planning, the teams found it difficult to determine and respect WIP limits. They also found it challenging to work with remote offices and to see the big picture of work when broken down into smaller pieces. These challenges were expressed in these statements:

Work is broken down into smaller pieces, which make it more difficult to see the big picture”. “After a period of time, we need to level set to get back on WIP limit awareness and Kanban board protocol. It is challenging to determine correct WIP limits. Stories are often so closely related that developers are conflicting with each other, resulting in difficult merges, etc. Developers have no power to change the process. When work is impeded, it’s unclear what the impeded developer is supposed to do. Kanban slows everything down for the sake of providing information”.

Again, earlier studies confirm these findings [1, 5, 6, 25, 28].

4 Validity Threats

In this study, we considered threats to validity throughout the research process by following the guidelines outlined by Runeson and Höst [26]. With online surveys, there is always a risk that questions may be misunderstood. To reduce this risk, we pre-tested the survey with three experts from the software industry and three researchers. It is important to take in consideration that this study is not empirically validating the adopted model. There could be other factors which are affecting Kanban actual use.

The survey was posted on LinkedIn; there was no control for the researchers with respect to external validity (i.e., the general applicability of the results). What can be observed is that the respondents come from various sectors, such as software companies, telecommunication services and hardware manufacturing companies. It is important to note that the study subjects were individuals who represented different organisations. Therefore, it would have been impossible for a single person to answer on behalf of the whole organisation. Additionally, respondents’ positions and roles vary within the organisations. Respondents in different organisational positions may have divergent views about the organisational practices and varying knowledge about Kanban, factors that could affect the reliability of the results to some degree. The respondents that opted to answer are more positive towards Kanban use; it may cause positive bias in the study.

We intentionally selected the LeanKanban LinkedIn community to obtain an appropriate data sample because the community has an understanding of Kanban and its use at work. LinkedIn professional are considered groups to be a good source of data collection for researchers and practitioners from all seniority levels [32].

5 Conclusion and Future Work

This research sought to explore the factors that practitioners consider to be important in the use of Kanban. It also investigated participants’ perceived Kanban benefits and challenges. The study indicates that perceived usefulness, perceived ease of use, perceived compatibility, subjective norms and organisational support can play important roles in Kanban use. Kanban practitioners find it easy to learn and use in their individual and team work. They also believe that Kanban is compatible with their work and useful in terms of improving job performance, productivity and quality.

In general, it is important for managers to monitor and evaluate innovation factors, such as perceived usefulness and perceived compatibility. Such monitoring will help to sustain effective Kanban use while enabling recognition of any need for change. Higher management support remains vital to Kanban initiatives in order to sustain visible benefits throughout the organisation.

The results show three primary benefits of using Kanban: improved visibility of work, stronger development flow and reduced WIP. The respondents expressed that starting to use Kanban at work is not a straightforward process; rather, it requires convincing managers, developers and trainers. Kanban practitioners also reported three main challenges in Kanban use: organisational culture and mind set; lack of training and misunderstanding of Kanban; and difficulties in Kanban implementation.

In the future, similar studies are needed in different regions and countries. Such studies would enable comparison of the latest trends in Kanban use and adoption around the globe. Additionally, future qualitative studies should focus explicitly on issues and problems.



We would like to thank the participants and companies who take part in this study. This research was carried out within the DIGILE Need for Speed program, and partially funded by Tekes (the Finnish Funding Agency for Technology and Innovation). We would like to thank LeanKanban incorporated and the participating companies.


  1. 1.
    Al-Baik, O., Miller, J.: The kanban approach, between agility and leanness: a systematic review. Empirical Softw. Eng. 20(6), 1–37 (2014)Google Scholar
  2. 2.
    Liker, J.: The Toyota Way. McGraw-Hill, New York (2004)Google Scholar
  3. 3.
    Hiranabe, K.: Kanban applied to software development: From agile to lean, InfoQ. Accessed 4 May 2015
  4. 4.
    Shalloway, A., Guy, B., Trott, R.J.: Lean-agile Software Development: Achieving Enterprise Agility. Pearson Education, Boston (2009)Google Scholar
  5. 5.
    Ahmad, M.O., Markkula, J., Oivo, M., Kuvaja, P.: Usage of Kanban in software companies: an empirical study on motivation, benefits and challenges. In: Proceedings of 9th International Conference on Software Engineering Advances (2014)Google Scholar
  6. 6.
    Ahmad, M.O., Markkula, J., Oivo, M.: Kanban in software development: a systematic literature review. In: Proceedings of IEEE 39th Euromicro SEAA (2013)Google Scholar
  7. 7.
    Boeg, J.: Priming Kanban: A 10 Step Guide to Optimizing Flow in Your Software Delivery System, 2nd edn. Trifork, Amsterdam (2012)Google Scholar
  8. 8.
    Dybå, T., Moe, N.B., Mikkelsen, E.M.: An empirical investigation on factors affecting software development acceptance and utilization of Electronic Process Guides. In: Proceedings of Software Metrics, 10th International Symposium (Metrics 2004), pp. 220–231 (2004)Google Scholar
  9. 9.
    Riemenschneider, C.K., Hardgrave, B.C., Davis, F.D.: Explaining software developer acceptance of methodologies: a comparison of five theoretical models. IEEE Trans. Softw. Eng. 28(12), 1135–1145 (2002)CrossRefGoogle Scholar
  10. 10.
    Anderson, D.: Kanban – Successful Evolutionary Change for Your Technology Business. Blue Hole Press, Sequim (2010)Google Scholar
  11. 11.
    Davis, F.: Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Q. 13(3), 318–339 (1989)CrossRefGoogle Scholar
  12. 12.
    Davis, F., Bagozzi, R., Warshaw, P.: User acceptance of computer technology: a comparison of two theoretical models. Manage. Sci. 35(8), 982–1003 (1989)CrossRefGoogle Scholar
  13. 13.
    Hardgrave, B.C., Johnson, R.A.: Toward an information systems development acceptance model: the case of object-oriented systems development. IEEE Trans. Eng. Manage. 50(3), 322–336 (2003)CrossRefGoogle Scholar
  14. 14.
    Iivari, J.: Why are CASE tools not used? Commun. ACM 39(10), 94–103 (1996)CrossRefGoogle Scholar
  15. 15.
    Moore, G.C., Benbasat, I.: Development of an instrument to measure the perceptions of adopting an information technology innovation. Inf. Syst. Res. 2(3), 192–222 (1991)CrossRefGoogle Scholar
  16. 16.
    Rogers, E.M.: Diffusion of Innovations, 4th edn. The Free Press, New York (1995)Google Scholar
  17. 17.
    Venkatesh, V., Davis, F.: A theoretical extension of the technology acceptance model: four longitudinal field studies. Manage. Sci. 46(2), 186–204 (2000)CrossRefGoogle Scholar
  18. 18.
    Taylor, S., Todd, P.: Understanding information technology usage: a test of competing models. Inf. Syst. Res. 6(2), 144–176 (1995)CrossRefGoogle Scholar
  19. 19.
    Adams, D.A., Nelson, R.R., Todd, P.A.: Perceived usefulness, ease of use, and usage of information technology: a replication. MIS Q. 16, 227–247 (1992)CrossRefGoogle Scholar
  20. 20.
    Chan, F.K., Thong, J.Y.: Acceptance of agile methodologies: A critical review and conceptual framework. Decis. Support Syst. 46(4), 803–814 (2009)CrossRefGoogle Scholar
  21. 21.
    Wang, X., Conboy, K., Pikkarainen, M.: Assimilation of agile practices in use. Inf. Syst. J. 22(6), 435–455 (2012)CrossRefGoogle Scholar
  22. 22.
    Kniberg, H., Skarin, M.: Kanban and scrum – Making the most of both, InfoQ (2010)Google Scholar
  23. 23.
    Ladas, C.: Scrumban – Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press, Salt Lake City (2009)Google Scholar
  24. 24.
    Middleton, P., Joyce, D.: Lean software management: BBC Worldwide case study. IEEE Trans. Eng. Manage. 59(1), 20–32 (2012)CrossRefGoogle Scholar
  25. 25.
    Rodríguez, P., Markkula, J., Oivo, M., Turula, K.: Survey on agile and lean usage in Finnish software industry. In: Proceedings of the ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, pp. 139–148. ACM (2012)Google Scholar
  26. 26.
    Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empirical Softw. Eng. 14(2), 131–164 (2009)CrossRefGoogle Scholar
  27. 27.
    Kline, P.: The Handbook of Psychological Testing. Routledge, London (1999)Google Scholar
  28. 28.
    Roberts, T.L., Hughes, C.T.: Obstacles to implementing a system development methodology. J. Syst. Manage. 47(2), 36–40 (1996)Google Scholar
  29. 29.
    Nerur, S., Mahapatra, R., Mangalaraj, G.: Challenges of migrating to agile methodologies. Commun. ACM 48(5), 73–78 (2005)CrossRefGoogle Scholar
  30. 30.
    McManus, J.: Team agility. Comput. Bull. 45(5), 26–27 (2003)CrossRefGoogle Scholar
  31. 31.
    Agarwal, R., Prasad, J.: A field study of the adoption of software process innovations by information systems professionals. IEEE Trans. Eng. Manage. 47(3), 295–308 (2000)CrossRefGoogle Scholar
  32. 32.
    de Mello, R.M., da Silva, P.C., Travassos, G.H.: Investigating probabilistic sampling approaches for large-scale surveys in software engineering. In: Proceedings of 11th Workshop on Experimental Software Engineering (2014)Google Scholar
  33. 33.
    Ahmad, M.O., Kuvaja, P., Oivo, M., Markkula, J.: Transition of software maintenance teams from Scrum to Kanban. In: 49th Hawaii International Conference on System Sciences (2016)Google Scholar

Copyright information

© The Author(s) 2016

<SimplePara><Emphasis Type="Bold">Open Access</Emphasis> This chapter is distributed under the terms of the Creative Commons Attribution-NonCommercial 4.0 International License (, which permits any noncommercial use, duplication, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, a link is provided to the Creative Commons license and any changes made are indicated.</SimplePara> <SimplePara>The images or other third party material in this chapter are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.</SimplePara>

Authors and Affiliations

  • Muhammad Ovais Ahmad
    • 1
    Email author
  • Jouni Markkula
    • 1
  • Markku Oivo
    • 1
  1. 1.M-GroupUniversity of OuluOuluFinland

Personalised recommendations