Experience Report: Introducing Kanban into Automotive ... · Experience Report: Introducing Kanban into Automotive Software Project ... Keywords:kanban,lean,automotive,scrum,agile

e-Informatica Software Engineering Journal, Volume 11, Issue 1, 2017, pages: 39–57, DOI 10.5277/e-Inf170102

Experience Report: Introducing Kanban intoAutomotive Software Project‡

Marek Majchrzak∗, Łukasz Stilger∗∗

∗Faculty of Computer Science and Management, Wroclaw University of Science and Technology∗∗Capgemini Polska

[email protected], [email protected]

AbstractThe boundaries between traditional and agile approach methods are disappearing. A significantnumber of software projects require a continuous implementation of tasks without dividing theminto sprints or strict project phases. Customers expect more flexibility and responsiveness fromsoftware vendors in response to the ever-changing business environment. To achieve better resultsin this field, Capgemini has begun using the Lean philosophy and Kanban techniques.The following article illustrates examples of different uses of Kanban and the main stakeholder ofthe process. The article presents the main advantages of transparency and ways to improve thecustomer co-operation as well as stakeholder relationships. The Authors try to visualise all of theelements in the context of the project.There is also a discussion of different approaches in two software projects. The article focuseson the main challenges and the evolutionary approach used. An attempt is made to answer thequestion how to convince both the team as well as the customer, and how to optimise ways toachieve great results.

Keywords: kanban, lean, automotive, scrum, agile

1. Introduction

Lean thinking is important because it can dra-matically reduce waste and introduce built-inquality in every process step. It has been shownthat when applying this approach in the manufac-turing or service organisation, the productivityhas at least doubled. Moreover, this method alsosignificantly reduces delivery time for new prod-ucts and decreases overall costs [1, 2].

The paper also describes two softwareprojects in the automotive industry, which haveemployed the Kanban technique in an evolution-ary way. In each of these cases, Kanban wasused to optimise a different process and wasmotivated by other business problems. However,the mutual characteristic was the simplification

of processes and evolutionary adaptation of boththe developer teams and the collaborating clientteams.

The idea was to make the communicationmore efficient, and thanks to that do a projectmore efficiently. It is necessary to continuouslyidentify bottlenecks and wastes. With the leanprinciples and Kanban specific practices it ispossible to visualise the state of the project andfocus on the process.

This paper is organised as follows: an intro-duction to Lean Software Development and Kan-ban technique in Sections 2 and 3. Section 4presents the related work. Section 5 describesprojects and their Kanban technique adoptionhistory. General results and conclusions are dis-cussed in Section 6.

‡This paper was originally published in the KKIO 2015 proceedings P. Kosiuczenko and M. Śmiałek (Eds.), “FromRequirements to Software: Research and Practice”.

http://www.e-informatyka.pl/wiki/e-Informatica

http://www.e-informatyka.pl/attach/e-Informatica_-_Volume_11/eInformatica2017Art2.pdf

40 Marek Majchrzak, Łukasz Stilger

2. Lean software development

The principles of Lean thinking focus on valueadded for the customer [3]. By removing theunnecessary processes, activities and artefacts,and on the other hand organising work asa continuous flow, which recombines labour intocross-functional teams dedicated to that activ-ity and constant improvements across the en-tire company, we have been able to develop,fabricate and sell with half or less of the hu-man effort, tools and overall costs. By intro-ducing Lean thinking and its associated styleof operation, we have been able to react fasterand more flexibly to the ever-changing needsof our Clients and the modern market. Leanthinking requires continuous learning, growthand most importantly, commitment and under-standing from the personnel of any level includingmanagement.

Lean Software Development is the applicationof Lean Thinking to the software developmentprocess. The Poppendieck and Poppendieck [4]illustrated how many of the Lean principles andpractices could be used in the software engi-neering context. They proposed seven principleseliminating and managing the waste in softwaredevelopment:– Eliminate Waste – Do only what adds value

for a customer, and do it without delay.– Amplify Learning – Use frequent iterations

and regular releases to provide feedback.– Delay Commitment – Make decisions at the

last responsible moment.– Deliver Fast – The measure of the maturity

of an organisation is the speed at which it canrepeatedly and reliably respond to customerneeds.

– Empower the Team – Assemble an expertworkforce, provide technical leadership anddelegate the responsibility to the workers.

– Build Integrity In – Have the disciplines inplace to assure that a system will delightcustomers both upon initial delivery and overan extended period.

– See the Whole – Use measurements and in-centives focused on achieving the overall goal.

The automotive software projects use proventechnologies, mostly not the latest developmenttechniques. It is because the business function-ality is more complex than the other softwareprojects. There are many external system in-terfaces which extend at the same time. Leanprinciples offer support to optimise the processeswith focus on following aspects:– Time to market – it is crucial for the software

used in the automotive sector to keep sta-bility and compatibility. However, the rapiddevelopment of industry requires also moreflexibility of software. Automotive companiesconstantly release new car models or versionsof the same car.

– Stakeholder management – at the same time,stakeholder structure was extended in bigorganisations. Each stakeholder (or group ofinterested parties) has their goals which needto converge.

– Domain knowledge – another characteristicdimension in software for the automotive sec-tor is domain knowledge which is based onexperienced subject matter experts.Lean principles support the optimisation of

the processes with a focus on these three aspects:time to market, stakeholder management anddomain knowledge. The main advantages of leanprinciples for automotive software projects isa fast visualisation of the executed processes andbased on it, improve our efficiency.

3. Kanban in software engineering

The name “Kanban” originates from Japaneseand could be translated as “signboard” or“billboard”. It is a flow-control mechanism forpull-driven “just-in-time” production. The ideabehind Kanban is to execute Lean principles inpractice.

David J. Anderson defined 5 Kanban coreprinciples which to agreat extent overlap withLean principles [5].– Visualise the workflow – one has to under-

stand the route covered by an item betweena request and its completion.

Experience Report: Introducing Kanban into Automotive Software Project 41

– Limit WIP – limiting work-in-progress im-plies that a pull system is implemented onparts or on the whole workflow. New work is“pulled” into the new activity when there isavailable capacity within the local WIP limit.

– Manage Flow – the flow of work itemsthrough each state in the workflow shouldbe monitored and reported.

– Make Process Policies Explicit – the processneeds to be defined, published and socialisedexplicitly and concisely.

– Improve Collaboratively (using models & thescientific method) – the use of models allowsa team to make a prediction about the effectof change (or intervention).In software projects, using “Kanban” is be-

coming increasingly popular regardless of theproject stages or production methods. An in-teresting aspect of this technique is that it isbecoming an inside tool in both waterfall andagile processes.

Kniberg [6] points out that Kanban is lessprescriptive than other agile methods like RUP,XP or even SCRUM.

Scrum, XP and RUP are highly adaptivewhile Kanban leaves almost everything open. Theonly constraints are Visualize Your Workflow andLimit WIP, which makes it a great tool for quickand efficient workflow and a process managementtool. Especially, in the case when the prescribedrules and artefacts do not fit project needs. Scrumprescribes the use of timeboxed methods, but inthe case of a support team or a firefighting team,it is hard to plan tasks in a sprint timebox.

3.1. Metrics – a way of observing factsand finding bottlenecks

To make decisions, the management of a givenproject requires capabilities for adequate situa-tion analysis [7, 8]. This role is served by projectmetrics, correctly selected criteria according towhich the defined parameters can be observed.

A simple visualisation is a great way of in-vestigating the work of a team and the cur-rent state of progress. However, it is mainly em-ployed in the day-to-day planning. When moreaccurate analysis based on a larger volume of

data is needed, it is crucial for creating met-rics or information-gathering schemes. Metricsare collections of updated and adequately repre-sented data used for problem identification anddecision-making.

The value of a good metric is to find a properway to monitor bottlenecks in the whole pro-cesses or at its stages. For instance, one can mea-sure the development processes in detail, i.e thedevlopemnt team, integration, defect handling,system tests and network integration (target en-vironment). One of the key findings is to focuson measuring the flow and not the constraints,which means it is better to identify and thenremove organisational impediments instead ofmeasuring it. Another interesting aspect is notfocusing on speed measurements but on moni-toring capacity. Speed is usually related to thehuman aspect and could foster unwanted com-petition instead of the collective responsibilityfor the project [9]. However, the case presentedin this paper depends more on dynamics devel-opment analysis and not always on sustainabledevelopment of new features. The key conceptsin measuring work efficiency in this specific caseare as follows:– Reaction time: it is the interval time between

reporting an issue and starting an analysisof the problem. A reaction can be defined ina number of ways, however, according to themost common definition the reaction meansdelegating a task to a team.

– Lead time: a total time measured from taskcreation until its c ompletion. Lead time takesinto consideration all of similar events be-tween these two points, both predictable andunpredictable.

– Cycle time: the correct volume of work.Figure 1 is used to portray these two con-cepts. It must be noted here that the entryand exit points for work units, as well as thein-between points, are defined in each project.The purpose of both of these metrics is to showthe current work efficiency and the potentialdecrease in the time and costs of deliveringa valuable work unit. More practical details andthe corresponding results are described in Sec-tion 5.2.


Reaction Time (SLA)

Priority Set Start Work Ticket Live Ticked Created

Cycle Time

Resolution Time (SLA) = Lead Time

Figure 1. Lead time and cycle time

4. Related work

Mattias Jansson, Operations Engineer at Spo-tify1, introduces [10] Kanban in the operationsteam as the answer to the growing number ofdifferent kinds of tasks. Before testing Kanban,the team noticed that although they were quiteefficient, they were not able to plan far in advance.The problem was that they were reactive andnot pro-active. The growing number of “urgent”jobs from other departments was always moreimportant that the internal tasks and the con-text switching decreased the team’s effectiveness.They realised that the company was growing toofast for them to accommodate.

Soon after Kanban’s introduction, they no-ticed that their lead times became shorter, moreinternal tasks were done, and the departmentsthey interfaced with were more satified.

In his book Lean from the Trenches [11]Kniberg described PUST – a digital investigationsystem for the Swedish national police authority.Due to the project scale, the teams, as well as theKanban boards, were divided into subsystems.Besides having WIP limits in regular tasks, theyalso decided to restrict the number of bugs re-ported in the bug tracker. In the case of blockerpriority, the bug had to be fixed immediately or ifit was less important, it had to be replaced withan existing one from the top thirty. Otherwise,it would be ignored. He claimed that such anapproach not only allowed for effective communi-cation (lower number of bugs, highly prioritised

bugs were immediately fixed), but also avoidedcontinued change control meetings to managelong lists of bugs which would probably never befixed.

Ikonen et al. [12] conducted a study ina medium-sized project (13 developers) in theR&D field. The investigation focused on thefollowing project work aspects: documentation,problem-solving, visualisation, understanding thewhole, communication, embracing the method,feedback, approval process, selecting work assign-ment. The presented results indicated consider-able benefits of the Kanban technique includ-ing team motivation and control over projectactivities. Most of the work aspects were posi-tively supported by Kanban techniques insidethe team.

Middleton and Joyce in their BBC World-wide case study [13] showed that as a result ofthe introduction of the Kanban technique, thelead time to deliver the software improved byover 37% and the number of defects reported bycustomers decreased by 24%. They observed verysimilar obstacles to those which may occur afterthe introduction of the lean principles connectedwith the environment and workspace, such as thetension within the existing corporate standardsand processes. Some especially common obstaclesencompass, e.g. office space designed inappropri-ately for Kanban boards, Kanban and reductionof WIP inability to work with milestones andGant charts, close team co-operation with thecustomer may be seen as working beyond the

1Spotify is a music streaming service for desktops and smartphones, which aims to provide a wide-ranging musiccollection.


remit, and the self-managing team of specialistmay be challenging to the managers.

They observed that the Agile approach, es-pecially Scrum, has some similarities. However,they also noticed that the Kanban techniqueand Lean have several advantages over the Ag-ile/Scrum approach. They claim that WIP limitsthe pull work model compared to the ScrumPush and timeboxed approach, it reduces deliv-ery time and allows to develop better qualitysoftware. They also noticed that the ownershipand responsibility of the Scrum “impedimentslist” are diffused. On the other hand, the Leanteam must solve the problem immediately if theyare blocked, because of limited WIP and visu-alisation on the Kanban boards. In this case,all staff members are obligated to eliminate thebottlenecks.

In another case study by Middleton et al. [14]the Timberland Company was analysed whilepractising Lean thinking for two years. Theynoticed many steps without any aded value intheir processes. A survey amongst company staffshowed that the majority of them supportedlean ideas and thought they could be applied tosoftware engineering. Interestingly only a smallminority (10%) was not convinced of the ben-efits of lean software development. The com-pany showed a 25% gain in productivity andtime for defect fixing was reduced by 65–80%.The response on the product released usinglean development from customer site was overallpositive.

The authors of each study emphasise the ben-efits of of the introduction of Kanban and col-laboration both in the team and with the client.The presented work was mainly conducted as in-ternal projects. Moreover, most of the describedprojects were relatively small. Hence, they didnot require the governance of the customer col-laboration process. Additionally, they did notshow how to evolve and build the lean values inthe team and with the client to establish and usethe Kanban technique effectively. Thus we wantto present the Kanban technique in the extensiveproject setting and the way of collaboration withthe external customer.

5. Discovering Kanban

This section presents two different approachesand two different perspectives of Kanban intro-duction. In Project A2 Kanban was introducedas a tool for dealing with unplanned tasks inSprint. In Project B the main goal was to un-block communication in the extensive stakehold-ers structure.

5.1. Project A

5.1.1. Background

The system under investigation covers all as-pects of car purchasing in one of the premiumcar manufacturers in Germany. The system wasdesigned for experts and is used internally bythe customer. It allows to buy, lease or rent carsby the clients’ employees, institutions or VIPs,car fleet management and used car dealers.

The system consists of two main components.One is a new version of the system developedas a modern web-based application. The secondcomponent written in COBOL is the old system’sversion, which is to be replaced by a new versionstep by step. Thus, both systems are availableto the end users, and this, in turn, requires datasynchronisation in real time.

The project uses the Scrum framework withcertain small additional procedures, like theadditional Scrum of Scrums meeting and thePO-Team meeting. A typical Sprint takes threeweeks, some of the user stories (US) are approvedduring the sprint, some at the end during thedemo. The majority of US are confirmed andtested by the PO-Team, however, in the caseof larger epics, there are more people involved,including many external IT specialists.

5.1.2. Timeline

The old system version has been being developedsince 1990 using the waterfall software develop-ment model. At the beginning the new versionof the system was also developed using the wa-terfall software development model. The devel-

2Due to a commercial agreement, the project names have been anonymous.


Solution Architects

PO Team JEE Dev Team 1

JEE Dev Team 2

JEE Dev Team 3

HOST Dev Team

Crossfunctional Team

Firefighting TeamFirefighting Team

Support TeamSupport Team

Virtual TeamsVirtual Teams

Figure 2. Project A – team structure

0

5

10

15

20

25

30

35

40

45

2010 2011 2012 2013 2014 2015

WEB Team HOST team

Figure 3. Project A – team grow

opment started in 2010. The first release after16 months showed that it was not possible tointegrate with the old system and that the min-imal end user needs were not covered. In 2012it was decided that to improve co-operation be-tween both systems and ensure faster delivery,new requirements for the whole project will bedeveloped as one Scrum project. After the finaltransition in 2013, as it was mentioned above,the entire team and the customer used Scrum.Currently, a new version is being released at leastquarterly. In the case of urgent requirements, wewill provide minor releases extending the latestproduction version.

It is important to note that the team startedto expand rapidly in 2014 (Figure 3). Untilmid-2013 no particular need of improvement hadbeen noticed. Support and bug fixing were per-formed on a daily basis by one or two experienceddevelopers. Also, issues were stored in severalsystems or delivered via email, hence develop-ers responsible for support and bug fixing hada detailed overview of pending issues.

A dynamic increase in the number of teammembers forced a change of the project processes.A growing number of developers caused code inte-gration problems. Instead of one Scrum Team theScrum of Scrums concept was introduced and a dif-ferent project governancemodel (3 ScrumMasters,Project Manager, PMO3 support). The responsetime and cycle time became longer, mainly dueto the insufficient expertise in the automotiveindustry among new developers and new ProductOwners. Even though the developers mentionedabove have been previously involved in differentautomotive ventures, domain knowledge is often

one of the main obstacles in a software project.For example, the automotive domain consists ofseveral specific sub-domains and a vast number ofprocess details, – which is one of the main reasonsfor building custom software. In general, teammembers do not have all the required knowledge,and the project must acquire additional infor-mation before accomplishing productive work.The sources of this information can be relevantdocumentation, formal training sessions,meetingswith domain experts and key users.

Additionally, several new business compo-nents started to be delivered, which, in turn,resulted in a growing number of support requestsand end-user bugs.

5.1.3. Team composition

The Team consists of 45 people. Aroundone-third of them are connected with the projectfrom the initial stage. Approximately half of theworkers had several years of experience in enter-prise projects. The entire team is divided intoseven sub-teams (see Figure 2), two of them arevirtual. A team member could be assigned tomore than one team because of his/her function.– JEE Development Teams (x3, DT) are re-

sponsible for the new system version, theyuse Scrum. Each team has about six membersand the Scrum Master.

– Host Team is responsible for developing theold system in a Cobol technology. The teamconsists of 5 members and the Scrum Master.

– Fire Fighting and Support Team (FT and ST)consists of 6 members. In most cases, theyare nominated in the sprint beginning from

3PMO stands for Project Management Office.


each development team. The team is respon-sible for the integration and production ofbug fixing and for providing 3rd line support.The members of the team change every Sprintsession.

– Cross-Functional Team (CT) consists of tech-nical leaders from each development teamand solution architects (SA). It focuses onlong-term technical and business decisionsand designs new components and supportscustomer.

– Product Owners (PO) Team consists of 3business architects focused on the new UserStory development. They work and agree ona new functionality directly with end usersand major stakeholders within the organisa-tion.

Up to a 70% of the capacity of people who lackindustry experience are used in the initial fewmonths of the Sprint. The slack time is used forinternal project training provided by experiencedsoftware developers and architects.

Project teams are located in 3 different cities.This type of work is organised in accordance withthe Distributed Scrum concept as described byMajchrzak et al. [15].

The development team and project manage-ment are located in two cities, the stakehold-ers and PO work in the third location. Themain Scrum meetings were conducted in the cus-tomer’s office. These meetings were attended byseveral team members only; the remaining onesparticipated in them via video calls.

Regarding daily contact with the PO team aswell as the major stakeholders, these are managedmostly by means of email communication andvideo calls.

5.1.4. Engineering practices

From the very beginning, we were focused on XPtechniques [16] which could be applied in boththe waterfall and then in Scrum framework:– test-driven development (unit tests);– clean code [17] instead of code documenta-

tion;– automated end-2-end (E2E) testing covering

the user stories;

– continuous integration after each source codechange, nightly build includes long-runningE2E regression tests;

– source control software and rigorous configu-ration management;

– bug-tracking software (JIRA [18]);– documentation in wiki (Confluence [19]).This results in high test coverage. The team canprovide a new release after each sprint. Due toE2E testing, business and technical complexity,the results are not always stable. About 5% ofthe tests fail regularly. The problems appearingbefore the release are checked manually to en-sure that the reported ticket occurs because ofnew functionality or because of bugs. Every timea bug is found, it is promptly reported in the is-sue tracking system. Another aspect which needsto be included in agile projects is the branchingstrategy. Similar to Shabib et al. [20] we havefound that a complex branching strategy couldimpact the quality of software. Despite the factthat the project consists of several teams, a deci-sion is made to reduce the number of branches tothe minimum, and to use the simplest branchingstrategy possible (Figure 4). The reason behindthat was the need of frequent merging (even sev-eral times per day) as well as the choice to use onebranch for the sprint, maintenance branch andrelease branch. This was only possible providedthat the team decide to use rigorous code-changerules, such as frequent commit and integration(several times per day), and quality rules such asno failing JUnit tests (immediate fix or revert)static code analysis before commit, clean codeand alike.

The branching and quality assurance rules,such as XP practices, clean code and fully auto-mated E2E, were also valid for each team work-ing in the Kanban process, hence the changes inSprint and Kanban were visible immediately forevery team member in the project.

5.1.5. Kanban introduction stages

The main impulses for employing Kanban werethe doubts expressed by the team with regard tobug correction and new feature implementation,which had not been explicitly defined during the


< <

<

<

<

V 1.0

V 1.1

merge

merge

Sprint X Sprint X+1 Sprint X+2main

release branch

maintenance branch

Figure 4. Project A – branching strategy

sprint planning. The change requests were oftenreported by end end users as tickets sent directly tothe support team instead of PO. It is worth notingthat the problem was not only which bug and inwhat order a given task or bug was to be corrected,but also the decision determining the incorrectworkings of an application and the decision aboutwho would be the sponsor of a given change.

The main stimulus to implement the im-proved process of error and support request man-agement originated from the developers’ team.The team initiated efforts to improve the alreadyexisting processes due to the growing amount ofcorrespondence (delays and handoffs), new teammembers scattered across localities (delays), do-main knowledge (waiting for solution approvals)and some restrictions stemming from the Scrumframework such as timeboxing and the sprinttarget (switching tasks and relearning – in thecase of a new sprint).Step 1: Identify work to be done. The firststep aimed at systemizing the volume of workbeing done outside the sprint was to create onelist of errors and problems from various sourcesand then organise them in the JIRA system. Inthe project, because of diverse users and condi-tioning, the above mentioned errors and queriescould be called in using many ways, i.e. by email,by telephone but also with the help of HPQCand Peregrine. From the developer’s perspective,many sources of those were impossible to accom-modate and respond to, similarly to prioritisingdecisions.

The unified bug list was not the right solu-tion as the following drawbacks were found veryquickly:1. The developer had to arrange who would be

the sponsor of a change or error – fixing.

2. In the case of the lack of symptoms, manytasks had the In Progress status. It is worthnoting that the developer was usually as-signed to the FT team for approximatelyonly two weeks. As a result, the said developerwould begin many tasks (the work in progresswas not defined or limited) and practicallywould not complete any in real life. Thenthe tasks would be returned to the “To Dolist” and the whole procedure would be re-peated. Consequently, some errors would waitfor weeks before being solved or rejected.

3. All of the agreements and contacts with POand stakeholders were chaotic. From the pointof view of each user group their bugs or taskshad the top priority. Undoubtedly, it resultedin misunderstandings and also caused addi-tional arduous communication by email.

Step 2: Identify workstreams. The next stepwas to identify the workstream and WIP ar-rangement (Figure 5). For instance, people work-ing on subjects connected with support receivedtheir boards or were able to use the commonone, but their tasks were marked with differ-ent colours. Similarly, people working on errors(FT) owned their boards. Very quickly anotherproblem emerged, it was connected with theproject characteristics. Some of the bugs hadto be fixed using a different budget, which meantfor example that only 1 FTE4 could be assigned.Another problem was the fact that many errorswere marked as a new feature (CR) and fromthe project standpoint, they were then investi-gated in a different budget and with the useof various resources. The constraints mentionedabove required the introduction of additionalKanban boards. Then the question concerningthe person who would make a choice between

4FTE – Full-time equivalent is a unit that indicates the workload of an employed person.


Classification Board

Support Board

Integration Bugs Board

CR Board

ToDo In Progress Resolved Prio 1

Prio 2

Prio 3


Prio 2

Prio 3


Prio 2

Prio 3


Prio 2

Prio 3

Production Bugs Board

Bugs Board


Prio 2

Prio 3

Work Stream View: Change Controll Board

PO Team and Development

PO Team and End Users

In case not 3rd Level Support


Prio 2

Prio 3

Figure 5. Project A – Kanban boards– work streams

General Issues Board

SupportBoard

Project TicketsBoard

Produktion BugsBoard

Int. BugsBoard

Change Request Board

Bugs Board

Level 0

Level 1

Level 2

Level 3

Figure 6. Project A – Kanban processes view

workstreams arose. Certainly, more boards wereadded and experienced developers or solutionarchitects used them to investigate the issue anddecide where it belonged.

Because of plenty of boards, this approachmight seem very complicated. However, fromthe FT point of view, the “To Do Lists” wereshortened and the focus was only on bug fixing.Step 3: Improve the communication. Theintroduced division between work streams wasoptimal from the FT and ST point of view. Onthe other hand, from the management’s andthe client’s perspectives (PO-Team), the existingwork streams did not always meet their needsBecause of this, to improve communication theefficient conduct of prioritisation meetings, wedefined many options which grouped the chosenwork streams but still retained simplicity. For in-stance in Figure 5 Change Control Board formedfrom Support Board and Change Request Boardwas identified.

5.1.6. Results

After nearly a year since the introduction of theabove process, process, an interview similar tothe one suggested by Ikonen et. all [12] was con-ducted. Opinions concerning the high complexityof the project structure and different expecta-tions were collected from each of the teams. Sincethe main work stream was done in sprints, wehave focused only on selected work aspects.

The hierarchy of the Kanban processes wasbuilt (Figure 6), it provides information for par-ticular team members depending on their level.

Each project member can find the right perspec-tive and reduce the amount of information de-pending on their needs. For instance Level 3 suitsthe FT as they will concentrate solely on selectedand initially analysed bugs. On the other handLevel 0 or Level 1 would meet the needs of theproject management team in terms of the generalproject state and SLA.Documentation. Dispersed exchange of infor-mation by email and arrangements during severalmeetings have been replaced by cohesive com-ments within the scope of a given task. Theyallowed us to understand each given problemand the process in which a decision was made.To a developer, it become evident what and whyneeds to be done. A member of the ST addition-ally states:

“Documentation has been improved, there isno worry about losing parts of data. Oncesomething has appeared on a Kanban board,it will not be forgotten or omitted, and it willbe equipped with the correct commentaryserving afterwards as a source of knowledgein similar problems.” [ST]

The error log and new feature request stored inone place allow for a significantly more straight-forward analysis of the changelog. It consequentlyhelps to understand who made a decision to in-troduce a change, and what were their reasonsas well as motivations for such an alteration.

“Due to the significant number of tasks re-garding various components and business pro-cesses, we have made a decision for all theinformation to be included in the commentsof a given bug or task. This simplifies the


correlation detection between tasks and bugsand the root cause analysis.” [CT]“Bugs are well commented on, hence wecan reuse historical information during laterstages.” [SM]

From the developer team’s point of view, the keyaspect is the task status and in particular theinformation which may impact the current tasksin the sprint.

“We are aware of errors and how they aremanaged; earlier on we used to lose such data,whereas at present we can obtain statuses oferrors which are of interest to us.” [DT]

Problem solving. The introduction of Kanbanallowed for easy task assignment to suitable peo-ple in the correct order. In the case when a de-veloper or a customer finds a bug or requestsa new feature, he or she can easily issue a newticket without the need for consultation with theScrum work model and budget, which made itpossible to continue work without delays:

“It facilitates work and provides a structureerror correction.” [FT]“Developers are not blocked and know thatthe reported problem will be properly clas-sified and solved. They are not blocked byunplanned tasks and can develop new userstories without changing the context.” [CT]

Even though most of the team thinks that cer-tain progress has been made, ST and CT stillsee some room for improvement:

“Using Kanban has not solved all of our prob-lems. Too much of a mess occasionally stillhappens.” [ST]“Still, a large number of tasks, e.g. copyingemails and HPQC Bugs into JIRA require ad-ditional time and should be automated.” [ST]

Also, one of the FT members pointed out thatthere are still problems due to a largely rotatingteam:

“On the other hand, we have to improvethe process of bug fixing itself. A task oncestarted does not always get completed beforeit is time for a developer to leave the FTteam.” [FT]

Visualization. The process of error fixing andCR management is much simpler and more trans-parent from the team’s point of view. Bug sta-

tuses and workloads are always visible. Eachmember can easily select a given board and thenthe related task:

“Kanban boards look much better and pro-vide more information than a long buglist.” [SM]

The Team and stakeholders understand what thesupport and bug fixing process looks like:

“Once upon a time, I found it difficult to de-scribe the way in which we worked. A projectseems to be much more mature, once itit becomes clear how a given process func-tions.” [ST]“Above all priorities are error statuses anddevelopers who make such errors. Such infor-mation is indeed favourable in case of a sig-nificant number of various errors.” [FT]

Visualisation also helps people working on regu-lar Sprint tasks, and they claim that:

“It is easy to observe whether a person isworking to solve a problem which has blockedus and what is its priority.” [DT]“When we need to have a general overview,Kanban boards offer a great deal of assis-tance.” [CT]

Communication. Internal communication be-tween teams and the PO has improved dra-matically. Instead of having dedicated meet-ings to discuss each critical error, regular meet-ings for the selected work streams have beeninitiated:

“The number of meetings has grown, how-ever, they have become shorter and allowedus to manage the tasks on given boards effec-tively.” [CT]“The number of meetings has increased,which could be considered a major improve-ment. Instead the inefficient information flowvia emails, it is much faster to conducta meeting drawing on the Kanban boardand thanks to this keeping the changesup-to-date.” [SM]

From the team’s point of view, the informationconcerning prioritising error-correction and thedetails concerning them have been set in place.On the other hand, from the PO’s point of view,communication with the development team hasbeen improved:


“The client knows who to speak to with re-gard to a given task and when to expect thesolution to a particular error.” [FT]

Another equally important aspect is the optionof regular progress monitoring.

“We can see the status of work immediately.I don’t have to interrupt people and ask whatthey are doing.” [SM]

A different point of view is presented by develop-ers working on tasks in Sprints. As far as theyare concerned, communication has been reducedto the minimum.

“Not relevant in the case of a developmentteam. We do not have to cope with bugs be-cause we know that the right people from theFirefighting Team will support the process,and we do not have to be involved.” [DT]

Approval process. The basic advantage of thedefined process was the improvement of workstream choices for new tasks:

“In the case of fixed bugs, our process stillneeds improving. Despite the fact that devel-opers know that they should fix and test thebug, we additionally need a Verify columnin order to explicitly emphasise the need fora test and verification.” [DT]“It is easier to approve bugs and to assignthem to the proper work stream.” [SA]

Additionally, the introduction of rules concerningthe flow and identification of the sponsors respon-sible for error-correcting has improved supportwork:

“In the case when a task cannot be eas-ily solved, because we have to deal witha non-trivial bug or simply with a new feature,we can easily move it to another board.” [ST]“The PO Team checks the Kanban boards,provides some additional information and,most importantly, sets the right prior-ity.” [FT]

Despite the above improvements, the team hasstill seen the need for enhancing the process:

“Unfortunately, as of now, we have notbeen able to establish a correctly-function-ing approval process. We need another state(column) – Verified. Fortunately we havea proper release process, we can see on the

Kanban board what got released and whatdidn’t.” [SM]

Selecting work assignment. Through closeinteraction with the Customer and PO, we havebeen able to set our priorities right, which in turnhas allowed for optimal task accomplishment bythe team:

“You simply take the first task from the firstcolumn. You don’t have to search for tasksor ask others.” [SM]“Together with the PO-Team, we conduct theprioritisation, thus the most important tasksare at the top of the To Do column.” [SA]

Taking into account the aspect of a budget forparticular error types, the choice of a task isclearly sensible from the Team member’s pointof view:

“Different boards help us find bugs from dif-ferent work streams.” [FT]“Tasks are split into work streams andcould be easily selected based on priorityorder.” [DT]“We use issue priority in order to select workassignments. If the tasks have the same pri-ority, we simply select the oldest ones.” [ST]

5.1.7. General problems and future work

One of the most difficult challenges found inthe processes described earlier is the need toperform numerous activities manually. Clearly,using extra human resources, e.g. in order tocopy emails to Jira, would be considered a wastein the process. The next step should be the intro-duction of such systems as Jira Service Desk [21],and e.g. ConnectAll [22] to integrate HPQCand Jira.

It was also observed that assigning new peo-ple to a virtual team at the beginning of eachSprint may result in wasting time and and re-sources. Certain tasks sometimes require severaldays to analyse, fix and test. If the members ofvirtual teams are changed while tasks are still inprogress, new developers have to start them al-most from the beginning. Thus, it was decided toallow people to work on a given task, even thoughthey are assigned only to Sprint development.


5.2. Project B

The project involves the manufacturing of pro-duction software in a large automotive concern.A part of this software supports the direct steer-ing of car production in three separate stages:body construction, paint shop and assembly. Thesteering systems are critical because each poten-tial software error generates relatively expen-sive problems. The said software is employed inseveral dozen factories belonging to the afore-mentioned automotive concern. The goal of thisproject is the delivery of services within a spec-ified time frame and with specified availability,namely the development of new functions andthe support of current and existing functionsin the production environment.The support islimited to the most difficult problems requiringchanges in the software or specific changes inthe system configuration. In Project B, the mainchallenge in the introduction of the lean philos-ophy with Kanban techniques was combiningtransparency principles and contractual issues.Many contractual constraints originate from theextensive structure of stakeholders on the cus-tomer’s side.

In general, it is possible to visualise manyprocesses on a Kanban board, e.g. governance,transition, staffing, knowledge management, tech-nology and infrastructure, financial and contrac-tual elements.

5.2.1. Extensive structure of stakeholders oncustomer side

In this case, the customer is one of the biggestworld manufacturing consortiums with many lay-ers of interests. On the one hand, there is a needfor simplicity, however, however, on the handthe goals is to deliver the production of software– a crucial part of the customer’s business. Tomeet these contradictory expectations a set ofstakeholders was identified, however, this articlefocuss on the following groups:– The IT department which is the main stake-

holder from the contractual point of view.– Factories which are most important in case

of the continuity of the project.

– Quality assurance which is most importantto evidence our quality.

5.2.2. Team composition

Due to the massive system function complexity,the team was extended. Taking into account var-ious functions and tasks, the project was dividedinto the following teams (see Figure 7):– Feature Team (x4) – these are people directly

responsible for software manufacturing. Theteam consists mainly of Programmers andTesters. Each Team is responsible for specificbusiness components.

– Project Support (cross-functional team 1 ) –responsible for the infrastructure and continu-ity of project functioning in relation to techni-cal data, namely integrating both Client’s andcontractor’s networks as well as supportingthe build and configuration of managementprocesses.

– Governance (cross-functional team 2 ) – re-sponsible for the management and clientco-operation takes key decisions concerningthe project. It is involved in all the exist-ing aspects of project management includingchange and risk management.

5.2.3. Kanban introduction stages

The deployment of the agile approach is muchmore challenging within the realms of a largeorganisation and an extensive stakeholder struc-ture. The above project description does notfocus on organisational or business limitations, itfocuses on the employment of the Kanban tech-niques instead. Because of critical and limitedfunctionality, all of the process changes had to beintroduced carefully, i.e. with risk management,which is an indispensable element of the empiricalproject approach.Step 1: Establishment of the commonworkflow. At the initial stages, the arrange-ment meant that each of the Teams functionedaccording to their rules and used their individualworkflow. The following issues caused difficultiespertaining to the correct definition of the generalstate of work: defining a completed task (Defini-


Project Support (cross-functional

team 1)

Governance (cross-functional

team 1)

Feature Team 1

Feature Team 2

Feature Team 3

Feature Team 1

Figure 7. Project B – team structure Figure 8. Innovation adoption lifecycle

tion of Done), reporting on critical productiveerrors (escalations) and seeing the fully completepicture of work in the entire project. After stan-dardising the workflow, it was possible to createthe root for visualising the Kanban board. In itsinitial stages, it comprises everyday work (dailybusiness), meaning current tasks. It consists ofthe following stages:– T-Shirt sizing: an initial assessment of a task,

which is a relative description of the size ofa task resulting from its complexity, uncer-tainty and repeatability [23, Chapter 7, 16].At this stage, the estimates are not precise,and the analysis itself should not exceed 4hours. The t-shirt sizing technique is similarto Planning Poker [24]. However instead ofusing the Fibonacci sequence, t-shirt sizes areused (XS, S, M, L, XL).

– Problem analysis: at this stage, a detailedanalysis is conducted based on the earlierestimate. The purpose of this stage is thedefinition of the scope of work and its costs.

– Development: at this stage the earlier analysisis used to perform the task. The purpose ofthis stage is the engineering of a registrablechange in software.

– Deployment: the final stage is the employ-ment of software change and in the majorityof cases this is the most complex process.The goal is the delivery of the change in theproduction environment.

It is possible that a problem is solved at each ofthese levels, which then completes the process.Step 2: Visualisation processes. Visualisa-tion is the best way to achieve a common under-standing of the state of the project, the best wayto keep a shared vision. It is possible to find the

bottlenecks only when everything is measuredand visualised to the whole team.

The reality of communication is that everystakeholder can have different interests. At thisphase of introducing Kanban, it became crucialto start collaborating in the same “language”.A Kanban board was created on the basis ofthe earlier study of the said workflow (see Fig-ure 9). The workflow of problem managementis described in Paragraph 5.2.3. Visualisation isnot only communication improvement, but it isalso a major factor in achieving the shared visionand promoting it in the whole project. After theintroduction of the visualisations, the followingobservations were made in the teams:– the processes were described and changes

were continuously supplemented;– the board was continuously adapted;– the processes were always visible to all mem-

bers of the team, and they were proposingimprovements (feedback loop).

Step 3: Introducing the culture ofself-improvement. The project approachesbased on nimble philosophy are tough to im-plement for multiple reasons, such as the re-quirements for experience and courage. A givensituation can be much simpler if there is an en-vironment open to the Agile and Lean thinking.It is fair to say that their deployment is not pos-sible without the culture of change and constantimprovement in place.

In the process of change within a large organ-isation, one must not forget about sociologicalprocesses, an example of which can be the Adop-tion Curve (see Figure 8) [25]. It is preciselythis model that became used in the process ofemploying change to the project and its close


T-Shirt sizing Problem analysis Development Deployment in progress done in progress done in progress done in progress done

problem management workflow

Figure 9. Project B – Kanban board – problem management workflow

environment. The technique used in the projectwas, among others, the selection of the “so-called”Change Ambassadors (early adopters), who wererecruited from the management of selected fea-ture teams. It was this group to be the main com-munication target in relation to Kanban deploy-ment techniques. In the aforementioned “EarlyMajority” means the Team.

Instilling the Lean culture allows the use oftechniques such as Kanban. Simultaneously, anorganisation promotes an adaptive approach ona wider scale, moving far beyond the scope ofthis project.Step 4: Managing improvement from theteam. The Coach is a crucial role in this oper-ation, and their position is not to be underesti-mated. However, their role is to guide the Teamtowards learning the process of coming to correctconclusions. Just as a parent bringing up a childteaches it to walk and then allows it to reachfull independence, so does the Team Coach bypointing out specific problems and then teachingthe Team members a lesson on independence.

The first dilemma, observed thanks to visuali-sation and the common workflow, was the lack ofcomprehensible understanding of the Definitionof Done (DoD). At the beginning, each Team de-fined their DoD in their own way. Unsurprisingly,it invariably led to serious misunderstandingsduring the execution of the said agreement, es-pecially at the final stages of the project.

Second of all, certain knowledge limitationsbecame apparent within the Team. The Kan-ban board immediately made the team painfullyaware which module lacked the necessary knowl-edge, where fewer tasks existed and where therewas a potential for certain key moves. Throughthe act of standardising the workflow and pro-gramming it correctly in the JIRA, both theexecutive documentation procedure and the com-

munication regarding production difficulties weresuccessfully improved:– documentation concerning current problems

consists of the necessary meta information, i.e.contact persons, references to other existingdocuments (i.e. change request);

– summary of existing problems is documentedin a uniform manner.

Step 5: Introducing the processes to theCustomer. In the described here case, beingable to implement the process of improvementswas a direct result of the steps taken at theprevious stages. One of the most efficient waysto achieve lean principles is visualising a givenprocesses. Together with identified stakeholders(see Section 5.2.1) we decided to start with threeworking areas: problem management, governanceprocesses and release managementProblem management board. This visualisa-tion shows the whole scope and the parameters ofthe daily state of work. The content of the boardconsists of a set of tickets (problems) which weresent to the development team. The goal of theproblem management board is to simplify thefeedback loop with the factories – one of thecrucial stakeholders identified for the project.

The problems (tickets) are prioritised and del-egated to the appropriate team member. Theycan proceed with a particular case of the Kan-ban board relatively fast, aligning work to theirprocesses and also completing the gaps in thespecification.Governance workflow. The work with the gov-ernance processes was dynamic, which was possi-ble thanks to a frame contract joining two com-panies by agreements that set out the terms andconditions for delivery services. In this projectthe goal was the delivery of the 3rd level devel-opment support. The frame contract allows toadjust the financial part of the delivery – each


service can be negotiated separately. For instance,the workflow of offering (see Figure 10) consistsof following steps:1. Service request: the customer requests a spe-

cific offer.2. Capacity: project management checks the ca-

pacity of the team, inclusive of the know-howin other projects (if needed).

3. Offer : a full offer is made to the customer.4. Confirmation: the customer accepts or rejects

the offer.The real workflow is more complex than de-scribed here. However, this example shows howthe crucial part of the processes can also be in-volved in the Kanban visualisation. The projectmanagement team and the customer’s IT depart-ment work jointly on the governance board. Asa result, a faster “one-piece flow” is achieved. Itis the crucial part of Lean Manufacturing [26]and also works well with software development.Release management processes. Besides en-suring the quality of the software solution, itis necessary to deliver software packages to thefactories. The development team delivers varioustypes of ensembles: release, service pack, fix packand hotfix. The roll-out team in the factory in-stalls the corresponding package and ensures thecontinuity of production. The development teamsupports packages in case of emergency. Qualityassurance is the most important stakeholder inthis area. With the visualisation of the releasemanagement processes, the delivery can be pri-oritised more easily and additionally, the steps ofthe processes can be adapted relatively fast. Theworkflow of release management (see Figure 11)consists of the following steps:1. Development: preparation of delivery.2. Ready for tests: finishing delivery and releas-

ing it for the customer.3. Tests: the customer conducts acceptance

tests.4. Ready for roll-out: finishing the delivery and

releasing it for roll-out (installation).

5.2.4. Results

One of the most significant consequences of theintroduction to Kanban is the ability to measure

a process, for example by quoting such definedmetrics as:– an increase in the number of created tickets

relative to the closed cases (see Figure 12);– a possibility to measure the average time for

closure and the costs of fabrication (LeadTime and Cycle Time);

– cyclical report of shifts in the original esti-mate, which meant a comparison of adequatework estimation in the T-Shirt sizing phaseto the actual volume of work being done. Thereport made the early detection of the mostincorrect estimates and their causes possible;

– the quality of task documentation comingfrom the Client is also measured, which inturn allowed for the introduction of multipleimprovements. The final effect was improvedcommunication with respective Client depart-ments.

Additionally, SLA values (Service Level Agree-ment) are measured within the scope of the saidproject based on the previously agreed parame-ters. The achieved SLA may shift up to a certainextent. The following SLA indicators are used inthe project:– Reaction time from the moment a work unit

was created to the beginning of actual work(early analysis),

– Time of the initial analysis (T-Shirt sizing).In the analysis phase (Problem Analysis, De-velopment and Deployment), the high level ofvagueness made it impossible to introduce theSLA which would measure the end of work. Ansample cumulative chart (Figure 13) highlightedthe piling up of tickets in the analysis phase forthe final period between September to Novem-ber. Such visualisation enhanced the credibilityof the reports for the Client. The goal of metricsis to monitor the state of the project and reactwhen problems occur. In this case most valuablemetrics are: Reaction Time, Lead Time and Cy-cle Time. In practical terms, the results of themetrics are not always easy to understand, whichwas also the experinece gained in this project.Matters which need to be interpreted separatelyare described below.– Incompletion of the data – there was some-

times a gap between real processes and the


Service request Capacity Offer Confirmation in progress done in progress done in progress done in progress done

governance offering workflow

Figure 10. Project B – Kanban board – governance workflow

Development Ready for tests Tests Ready for rollout in progress done in progress done in progress done in progress done

release management workflow

Figure 11. Project B – Kanban board – release management

Figure 12. Created vs. resolved chart Figure 13. Cumulative flow diagram

documented data; for example, a requestwhich was not registered in the system. Itwas assumed that these data were not crucialfor this metric.

– The learning curve while introducing changesto the processes – the whole process of intro-ducing lean changes with Kanban techniquesis relatively time-consuming. Establishing theefficient workflow of tickets lasted more thansix months, and the following six months wererequired to teach the entire team. It was as-sumed that there always was a learning curveand the measured data were calibrated withtime. Hence, it effectively corresponded withthe reality.

– Team rotation – the real problem was whenthe capacity of the team varied. All projects

need to deal with such issues not only becauseof the growing numbers in teams on the team,but also because of technical experience anddomain knowledge, which should be takeninto account. Unfortunately, the impact ofthis issue on the presented results cannot beaccurately compared.

– Bad multitasking – the more tasks there arein the progress, the less efficient the workingtime is. The Kanban visualisation allows us tominimise this problem. However, this aspectneeds considering when interpreting the finalresults.

– The complexity of business knowledge – itis a well-known fact that the software forproduction systems is complicated because ofvarious elements, such as interface systems,


real-time constraints, security aspects andproduction continuity. There is no direct rela-tion between the level of business complexityand the quality of the project; yet in metrics,it was observed that in the tickets, compar-ison to the others, this adverse effect canbe eliminated by using medians instead ofaverages.

Reaction time. The total time from reportinga problem to the moment the development teamcan start dealing with it. Table 1 and Figure 14show the effects of the described aspect of thedescribed aspect “the learning curve during theintroduction of changes to the processes”. Theyear 2014 was the learning phase. From 2015Q1 tuning the reaction time through minimizing“bad multitasking” was started.Lead time and cycle time. The lead time isthe total time required to develop a solution tothe problem including corresponding activities,both the predicted as well as the unpredictedones. It is the time from task creation until itscompletion. Cycle time is the correct volume ofwork.

In both tables (Table 2, 3) one can observe thedifference between averages and medians. Thecause of the difference is that a small amount oftickets was extremely complex. It correspondsto the described issue “complexity of businessknowledge”. In Figure 15 one can observe how thecost of the delivery was optimised. The periodbetween 2013 Q4 and 2014 Q2 was the time whenmeasuring data was not complete. From the 2014Q3 team rotation begins. In the first quarter of2015, we finished installing all modules of thesoftware.

6. Summary and key observations

In a progressively larger number of IT projects,one can easily notice a trend towards processand tools optimisation. The software companiesand its customers have spotted flaws in the cur-rent perspective based on waterfall approaches.There is a big potential in creating waste, e.g.through administrative behaviour. Moreover, fre-quently chosen software development method-

ologies do not encompass certain much-neededprocesses.

Although the Kanban technique is not thesubject of many analyses and was not promotedas much as the Scrum or XP ones, it is more andmore frequently used in software projects as oneof the tools of Lean thinking. It can be used withpositive results in each project type regardless ifit is an “Agile” or “Waterfall” style operation.

It should be noted that this basic and simul-taneously intuitive mechanism is a powerful toolallowing for the easy optimisation of nearly everyactivity and process within software projects. Inboth cases, substantial profits were observed bothon the side of our Team as well as on the Client’sside over a relatively short period.

As mentioned above, the most important as-pects of those undoubtedly are visualisations,process regular order and the creation of a coop-erative platform, which can be easily modifiedand adapted to any given target group.

During the analysis of the consequencesof Kanban deployment another perspectiveemerged. Taking into account the human factor,it can be observed that Kanban uses triggers asa tool for gradual self-improvement of each team,a sort of evolutionary step towards the reform ofdocumentation and fabricating processes. Hence,unlike something forced upon the staff by themanagement or outside specialists, Kanban re-sults in an all-natural, symbiotic and adaptiveprocess.

7. About Capgemini and SoftwareSolutions Center Wroclaw

With 180,000 people in over 40 countries,Capgemini is one of the world’s foremostproviders of consulting, technology and outsourc-ing services. The Group reported 2014 globalrevenues of EUR 10.573 billion. Together withits clients, Capgemini creates and delivers busi-ness, technology and digital solutions that fittheir needs, enabling them to achieve innova-tion and competitiveness. A deeply multicul-tural organisation, Capgemini has developed itsown way of working, the Collaborative Business


Table 1. Project B – reaction time

Period Reaction Time

year quarter average median issues

2013 Q4 6d 8h 1h 21m 732014 Q1 2w 5d 6h 3d 3h 1562014 Q2 1w 4d 23h 19h 14m 1952014 Q3 3w 14h 21m 16h 52m 2002014 Q4 2w 8h 38m 20h 42m 1712015 Q1 3w 7h 41m 6h 31m 1762015 Q2 1d 15h 5h 30m 1612015 Q3 2d 6h 4h 31m 1792015 Q4 1d 15h 3h 2m 223

0

5

10

15

20

25

30

Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

2013 2014 2014 2014 2014 2015 2015 2015 2015

Reaction time median [h]

Figure 14. Project B – median of reaction time

Table 2. Project B – lead time (time line)



2013 Q4 6w 5d 20h 7w 3h 26m 252014 Q1 4w 3d 19h 2w 1d 10h 762014 Q2 8w 4d 4h 6w 2d 2h 972014 Q3 9w 6d 5h 5w 6d 4h 1662014 Q4 16w 5d 22h 11w 6d 4h 1732015 Q1 22w 1d 7h 15w 1d 19h 2312015 Q2 15w 5d 16h 10w 6d 22h 1482015 Q3 17w 5d 8h 10w 3d 6h 2052015 Q4 16w 3d 5h 6w 1d 6h 427

Table 3. Project B – cycle time (in progress)



2013 Q4 3w 1d 2w 3d 1h 412014 Q1 3w 5d 5h 2w 3d 22h 622014 Q2 4w 6d 3h 3w 1d 5h 1072014 Q3 4w 6d 12h 3w 5h 44m 1302014 Q4 9w 21h 6m 5w 3d 2h 1772015 Q1 7w 6d 14h 5w 10h 20m 2002015 Q2 8w 1d 16h 3w 3d 20h 1712015 Q3 6w 6d 8h 2w 6d 15h 1912015 Q4 5w 1d 21h 1w 2d 23h 328

0

500

1000

1500

2000

2500

3000

Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

2013 2014 2014 2014 2014 2015 2015 2015 2015

Lead time median [h] Cycle time median [h]

Figure 15. Project B – median of lead time and cycle time

ExperienceTM, and draws on Rightshore R©, itsworldwide delivery model. Capgemini in Polandemploys 6500 consultants and IT as well as busi-ness process experts. Centres for IT and busi-ness process outsourcing services has operated inWrocław, Poznań, Kraków, Katowice and Opolewith the main office serving the Polish marketbased in Warszawa. Capgemini Software Solu-tions Center exists in Wroclaw since 2004. Morethan 800 IT experts currently work in Wroclawdelivering high-quality services in the areas of

software development, software package imple-mentation and application lifecycle services toGerman-speaking clients.

References

[1] T. Ohno, Toyota Production System: BeyondLarge-Scale Production. Cambridge, MA: Pro-ductivity, 1988.

[2] J. Koplin, S. Seuring, and M. Mesterharm, “In-corporating sustainability into supply manage-ment in the automotive industry – the case of the


Volkswagen AG,” Journal of Cleaner Production,Vol. 15, No. 11, 2007, pp. 1053–1062.

[3] J.P. Womack and D.T. Jones, “From lean produc-tion to the lean enterprise,” Harvard BusinessReview, Apr. 1994.

[4] M. Poppendieck and T. Poppendieck, Lean Soft-ware Development: An Agile Toolkit. Boston,MA, USA: Addison-Wesley Longman PublishingCo., Inc., 2003.

[5] D.J. Anderson, Kanban: Successful EvolutionaryChange for Your Technology Business. Blue HolePress, Apr. 2010.

[6] H. Kniberg, Kanban and Scrum – Making theMost of Both. Lulu.com, 2010.

[7] K. Petersen and C. Wohlin, “Measuring the flowin lean software development,” Software: Prac-tice and Experience, Vol. 41, No. 9, 2011, pp.975–996.

[8] M. Host, B. Regnell, J.N. och Dag, J. Ned-stam, and C. Nyberg, “Exploring bottlenecksin market-driven requirements management pro-cesses with discrete event simulation,” Journalof Systems and Software, Vol. 59, No. 3, 2001,pp. 323–332.

[9] M. Staron and W. Meding, “Monitoring bottle-necks in agile and lean software developmentprojects,” Product-Focused Software Process Im-provement, 2011, pp. 3–16.

[10] M.J. Michael Prokop, “Use of kanban in theoperations team at spotify,” InfoQ, Sep. 2010.

[11] H. Kniberg, Lean from the Trenches: Manag-ing Large-Scale Projects with Kanban. PragmaticBookshelf, 2011.

[12] M. Ikonen, E. Pirinen, F. Fagerholm, P. Ket-tunen, and P. Abrahamsson, “On the impact ofKanban on software project work: An empiricalcase study investigation,” in 16th IEEE Inter-national Conference on Engineering of ComplexComputer Systems (ICECCS). IEEE, 2011, pp.305–314.

[13] P. Middleton and D. Joyce, “Lean softwaremanagement: BBC worldwide case study,”IEEE Transactions on Engineering Management,Vol. 59, No. 1, 2012, pp. 20–32.

[14] P. Middleton, A. Flaxel, and A. Cookson, “Leansoftware management case study: Timberline

Inc.” in Extreme Programming and Agile Pro-cesses in Software Engineering. Berlin, Heidel-berg: Springer, 2005, pp. 1–9.

[15] M. Majchrzak, Ł. Stilger, and M. Matczak,“Working with agile in a distributed environ-ment,” in Software Engineering from Researchand Practice Perspective, L. Madeyski andM. Ochodek, Eds. Polish Information ProcessingSociety Scientific Council, 2014, pp. 41–54.

[16] K. Beck and C. Andres, Extreme Program-ming Explained: Embrace Change, 2nd ed.Addison-Wesley Professional, 2004.

[17] M. Robert C., Clean Code: A Handbook of AgileSoftware Craftsmanship, 1st ed. Upper SaddleRiver, NJ, USA: Prentice Hall PTR, 2008.

[18] Atlassian, JIRA documentation, (2016). [On-line]. https://confluence.atlassian.com/display/JIRA/JIRA+Documentation

[19] Atlassian, Specification – confluence advancededitor, (2016). [Online]. http://confluence.atlassian.com/display/DOC/Specification+-+Confluence+Advanced+Editor

[20] E. Shihab, C. Bird, and T. Zimmermann, “Theeffect of branching strategies on software quality,”in 2012 ACM-IEEE International Symposiumon Empirical Software Engineering and Mea-surement, ESEM, 2012, pp. 301–310. [Online].http://doi.acm.org/10.1145/2372251.2372305

[21] Atlassian, JIRA service desk documentation,(2016). [Online]. https://confluence.atlassian.com/servicedeskserver030/

[22] Go2Group, Connect all, (2016). [Online].http://www.go2group.com/connectall/

[23] K.S. Rubin, Essential Scrum: A Practical Guideto the Most Popular Agile Process, 1st ed.Addison-Wesley Professional, 2012.

[24] M. Cohn, Agile Estimating and Planning. UpperSaddle River, NJ, USA: Prentice Hall, 2005.

[25] E.M. Rogers, Diffusion of Innovations, 5th ed.Simon and Schuster, 2003.

[26] K.L. Jeffrey, The Toyota Way: 14 ManagementPrinciples From The World’s Greatest Manufac-turer. McGraw-Hill, 2004.

https://confluence.atlassian.com/display/JIRA/JIRA+Documentation

https://confluence.atlassian.com/display/JIRA/JIRA+Documentation

http://confluence.atlassian.com/display/DOC/Specification+-+Confluence+Advanced+Editor



http://doi.acm.org/10.1145/2372251.2372305

https://confluence.atlassian.com/servicedeskserver030/

https://confluence.atlassian.com/servicedeskserver030/

http://www.go2group.com/connectall/

Documents

Experience Report: Introducing Kanban into Automotive ... · Experience Report: Introducing Kanban into Automotive Software Project ... Keywords:kanban,lean,automotive,scrum,agile