Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Background

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 [1–3], 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.

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 [6]. 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 [4], the so-called Kanban properties [5]: 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 [6]. 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 [7]. The proliferation of Kanban in software engineering boomed after the publication of key books. These seminal books included David Anderson’s Kanban [5], which introduces the concept of Kanban in systems and software development, and Corey Lada’s Scrumban [8], 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.

2 Empirical Study Plan

Kanban has received considerable attention from software industry. The existing limited literature explored dynamics of Kanban which is tend to be more concentrating on its obtained benefits and less on Kanban pitfall [6, 7, 9, 10] in Brownfield project. Whereas, there is no evidence of Kanban use is reported for Greenfield project. The reason can be that in software industry Kanban is still in the early adoption phase. A Greenfield project could be one developing a system for a totally new environment, without legacy systems. Brownfield development could be one developing and deploying new software feature or systems in the existing legacy software applications or systems. This study explores the hidden pitfalls of Kanban in software development projects. The aim is to discover the reasons behind the Kanban pitfalls and failure. Additionally, to shed light on a phenomenon by discussing similar experiences among industry experts and find out what topics are most challenging for software companies. The study finds answers relevant to following research questions:

RQ1. What are the hidden pitfalls of Kanban in software development projects?

In our research group we have strong collaboration between the authors institute and Finnish leading software industry. In order for our research to have relevance, we need to work on problems that have been identified by practitioners. We work with organisations in the following way: we identify a relevant topic or challenge, conduct case studies to explore the topic or challenge within its organisational context, and conduct a literature review to identify suggested solutions. We discuss our findings with the organisation, engage in a dialogue with them about mitigation strategies and undertake research into changes made. We then publish our findings as academic papers for the research community [6, 9, 12].

2.1 Data Collection and Analysis Methods

We will deploy a ‘Kanban pitfall wall’ at XP Conference 2016. The participants can be a mixture of Agile and Lean practitioners, business representatives and academics researchers. The Kanban pitfall wall can be positioned with Kanban poster in a visible place in the conference venue with a stack of pens and small cards. The small cards will be used for writing individual pitfall as shown in Fig. 1. Participants can fill out the cards anonymously and attached it to the wall next to the poster for others participants to read. Similar data collection approach is used in earlier studies [13].

Fig. 1.
figure 1

A Kanban pitfall card

Full size image

Participants can write one pitfall per card, and could fill in as many cards as they wished. The pitfall wall will be a trigger point for discussions between participants of the conference and the interviewees. The discussion central point will be the nature and context of the identified hidden pitfalls.

After compiling the Kanban pitfalls, separate one to one interviews will be scheduled with the interested volunteers and “key informants” to discuss it in more detail. The key informant technique is used to identify experts and assures rich and high quality data acquisition from them [14]. Interviews could be conducted face to face or remotely via appropriate communication channel such as Skype.

We will use a thematic analysis approach for data analysis. It describes and organises the data set in rich detail and interprets different aspects related to the research topic [11].