individual work flow. The following caused difficulties pertaining to the correct defini-tion of general state of work, i.e. defining a completed task (Definidefini-tion of Done), report-ing on critical productive errors (escalations) and seereport-ing the fully complete picture of work in the entire project. Having standardized the work flow, it became do-able to create a root for visualising the Kanban board. In its initial stages it comprises of every-day work (daily business), meaning the current tasks. It consists of the following stages:
T-Shirt sizing: an initial assessment of a task, which is a relative description of size that is an outcome of complexity, uncertainty and repeatability In this stage, the estimates are not precise and the analysis itself should not exceed 4 hours. Possible values are: S - small, M - Medium, L - large and XL - extra-large.
Problem analysis: in this stage a detailed analysis occurs based on an earlier es-timate. The purpose of this stage is the definition of scope of work and its costs.
Development: in this stage realization occurs on the basis of an earlier analysis.
The purpose of this stage is the engineering of a registrable change in software.
Deployment: the final stage is the employment of software change and in the majority of cases this is the most complex process. The goal is the delivery of change within the production environment.
It is possible that a problem gets solved on each of these levels, which then completes the process.
Step 2: Visualization processes. Visualization is the best way to achieve common understanding the state of the project, the best way to keep shared vision. We can find the bottlenecks only when everything is measured and visualized to the whole team. The reality of communication is that every stakeholder can have different interests. In this phase of introducing Kanban, it became crucial to start collaborating in the same ”lan-guage”. A Kanban board has been created on the basis of an earlier study of the said workflow. (see Figure 5).
Figure 5. Project B – Team Structure
28 From Requirements to Software: Research and Practice
Visualization is not only communication improvement, it is also a key element to achieve shared vision and promote it around the project. After the introduction of the visualizations following behaviors were noticed in the teams:
the processes were described and changes were continuously supplemented,
the board was continuously adapted,
the processes were always visible to all members of the the team and they were proposing improvements (feedback loop).
Step 3: Introducing the culture of self-improvement. Project approaches based on nimble philosophy are extremely difficult to implement for multiple reasons, among many of which are the requirements for experience and courage. A given situation can be much simpler if there exists an environment open to the Agile and Lean thinking. It is fair to say that their deployment is not possible without the culture of change and constant improvement in place.
In the process of change within a large organization, one must not forget about socio-logical processes. One of such phenomenon is the Adoption Curve (see Figure 6) [17].
It is precisely this model that became used in the process of employing change to the project and its close environment. The specific technique used was, among others, the selection of the ’so-called’ Change Ambassadors (Early adopters), who were recruited from the management of selected feature teams. It was this group, who was the main communicative target in relation to Kanban deployment techniques. In the aforemen-tioned ’Early Majority’ means a Team.
Instilling the Lean culture allows the use of techniques such as Kanban. Simultaneously, an organisation promotes an adaptive approach on a wider scale, moving far beyond the scope of this project.
Step 4: Managing improvement from the team. The Coach is a very important role in this operation and his position is not to be underestimated. However, his role is to guide the Team towards learning the process of coming to correct conclusions. Just as a parent bringing up a child teaches it to walk and then allows it to reach full independence, so does the Team Coach by pointing out specific problems and then teaching the Team members a lesson on independence.
Figure 6. Innovation Adoption Lifecycle
The Project Management Perspective on Software Value: a Literature Review 29
The first problem, which has been noticed thanks to visualisation and the common workflow, was the lack of comprehensible understanding for the Definition of Done (DoD). In the beginning, each Team has defined their DoD in their own way. Unsurpris-ingly, it has invariably led to serious misunderstandings during the realization of said agreement, especially towards the final stages of the project.
Second of all, certain knowledge limitations have became apparent within the Team.
The Kanban board has made it immediately and painfully aware as to which module lacked the necessary knowledge, where fewer tasks existed and where there was poten-tial for certain key moves. Through the act of standardizing the workflow and pro-gramming it correctly in the JIRA, we have succeeded in improving both the executive documentation procedure as well the communication regarding production difficulties:
documentation concerning current problems consists of the necessary meta in-formation i.e. contact persons, references to other existing documents (i.e.
change request)
summary of existing problems is being documented in a uniform manner.
Step 5: Introducing the processes to the Customer. Now as a result of the other changes, we have become able to work with the process improvements. But how can we work on improvements together with the Customer? The first step was to visualize a set of data. A special Kanban board with set of data has been prepared. There are special instances of Kanban boards for a specific customer. Special cases for each group of stakeholders:
IT Department: the board shows all scope and parameters. With the complete overview in front of him, the customer can easily decide and prioritize work.
Problem management: this group on customer side is responsible for the inter-nal customer processes, e.g. ITIL [18]. With this special case of the Kanban board, they can proceed relatively fast aligning our work to their processes.
Local IT Departments within the factories. They have used our software direct-ly and plan on its upgrading in the future. They have used special boards in-cluding details limited to their scope of interest (only pertaining to issues from one particular factory).
5.2.3. Results
One of the most significant consequences of Kanban introduction is the ability to meas-ure process, as an example quoting such defined metrics as:
an increase in the number of called-in tickets relative to the closed cases (see Figure 7),
a possibility to measure the average time for closure and costs of fabrication (Lead Time i Cycle Time),
cyclical report for shifts in the original estimate, which meant a comparison of adequate work estimation in the T-Shirt sizing phase to the actual volume of
30 From Requirements to Software: Research and Practice
work being done. The report has made it possible for an early detection of the most incorrect estimates and their causes
the quality of task documentation coming from the Client is also being meas-ured, which in turn has allowed for an introduction of multiple improvements.
The end effect has been an improved communication with respective Client departments.
Additionally, SLA values (Service Level Agreement) are being measured within the scope of the said project based on the previously agreed parametres. The achieved SLA may shift up to a certain extent. The following SLA indicators exist in the project:
Reaction time meaning from the moment a work unit was created until the ac-tual work has begun (Early analysis),
Time of the initial analysis (T-Shirt sizing).
In the analysis phase (Problem analysis, Development i Deployment), a high level of vagueness has made it impossible to introduce SLA that would measure up an end of work. An exemplary cumulative chart (see Figure 8) has highlighted the piling up of tickets in the analysis phase for the final period between September to November. Such a visualization has very much given credibility to reports for the Client.
Figure 7. Created vs. Resolved Chart
Figure 8. Cumulative Flow Diagram
6. Summary and Key Observations
In a progressively larger number of IT projects, one can easily notice a trend to-wards process and actions optimization within the scope of executed projects. Both the Development Teams and Clients have spotted flaws in processes imposed by diverse methodologies. The said ones are in many cases over the top, worthless and unnecessary and their existence is only justifiable solely on the merit of each selected approach.
Moreover, frequently chosen software development methodologies do not encompass certain much needed processes.
Although the Kanban technique is not a subject of frequent analysis and has not been as promoted as the Scrum or XP ones, it has become more and more usable in IT projects as one of the tools of ”Lean thinking”. It can be used with positive results in
The Project Management Perspective on Software Value: a Literature Review 31
each project type regardless of whether it might be a ”Agile” or ”Waterfall” style opera-tion. It is worthy of a notice that this simultaneously basic and at the same time intuitive mechanism is a powerful tool allowing for an easy optimization of nearly every activity and process within the software projects. In both cases, we have seen noticeable profits both on the side of our Team as well as on the Client’s side over a relatively short peri-od of time.
The most important aspects of the aforementioned are undoubtedly visualisations, regular process order and the creation of a cooperative platform, which can be easily modified and adapted to any given target group.
Whilst analyzing the consequences of Kanban deployment another perspective has emerged. Taking into account the human factor, It is noticeable that Kanban’s use trig-gers a gradual self-improvement from within each Team, a sort of evolutionary step towards the betterment of documentation and fabricating processes. Hence, unlike something forced upon us by the management or outside specialists, the Kanban results in an all-natural, symbiotic and adaptive process.
7. About Capgemini and Nearshore Center Wrocław
With more than 130,000 people in 44 countries, Capgemini is one of the world’s foremost providers of consulting, technology and outsourcing services. The Group re-ported 2012 global revenues of EUR 10.3 billion. Together with its clients, Capgemini creates and delivers business and technology solutions that fit their needs and drive the results they want. A deeply multicultural organization, Capgemini has developed its own way of working, the Collaborative Business Experience and draws on Rightshore® , its worldwide delivery model.
Nearshore Center of Capgemini exists in Wroclaw since 2004, and is thus part of the worldwide Righshore® of delivery centers. More than 650 IT experts currently work in Wroclaw delivering high quality services in the areas of software development, software package implementation and application life cycle services to German-speaking clients.
Capgemini in Poland employs more than 5000 consultants and IT as well as busi-ness process experts. Centers for IT and busibusi-ness process outsourcing services exist in Wroclaw, Krakow, Katowice and Opole with the main office serving the Polish market based in Warszawa.
8. References
[1] David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, April 2010.
[2] Atlassian. JIRA Documentation, 2014.
[3] Atlassian. Specification - Confluence Advanced Editor, 2014.
[4] Kent Beck. Embracing Change with eXtreme Programming. Computer, 32(10):70–77, 1999.
32 From Requirements to Software: Research and Practice
[5] Marko Ikonen, Elena Pirinen, Fabian Fagerholm, Petri Kettunen, and Pekka Abrahamsson. On the Impact of Kanban on Software ProjectWork: An Empirical Case Study Investigation. In Engineering of Complex Computer Systems (ICECCS), 2011 16th IEEE International Conference on, pages 305–314.
IEEE, 2011.
[6] Daniel T. Jones James P.Womack. From lean production to the lean enterprise. Harvard Business Review, apr 1994.
[7] Henrik Kniberg. Kanban and Scrum - Making the Most of Both. Lulu.com, 2010.
[8] Henrik Kniberg. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Bookshelf, 2011.
[9] Julia Koplin, Stefan Seuring, and Michael Mesterharm. Incorporating sustainability into supply management in the automotive industry - the case of the Volkswagen AG. Journal of Cleaner Production, 15(11):1053–1062, 2007.
[10] Marek Majchrzak, Lukasz Stilger, and Marek Matczak. Working with Agile in a Distributed Environment. In Practice Software Engineering from Research and Practice Perspective (Eds. Lech Madeyski, M. Ochodek), Scientific Papers of the Polish Information Processing Society Scientific Council:41–54, 2014.
[11] Mattias Jansson Michael Prokop. Use of kanban in the operations team at spotify. InfoQ, sep 2010.
[12] Peter Middleton, Amy Flaxel, and Ammon Cookson. Lean Software Management Case study:
Timberline inc. In Extreme Programming and Agile Processes in Software Engineering, pages 1–9.
Springer Berlin Heidelberg, 2005.
[13] Peter Middleton and David Joyce. Lean Software Management: BBC Worldwide Case Study.
Engineering Management, IEEE Transactions on, 59(1):20–32, 2012.
[14] Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production. Productivity, Cambridge, MA, 1988.
[15] Kai Petersen and Claes Wohlin. Measuring the Flow in Lean Software Development. Software: Practice and Experience, 41(9):975–996, 2011.
[16] Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003.
[17] Everett M Rogers. Diffusion of Innovations, 5th Edition. Simon and Schuster, 2003.
[18] Arraj Valerie and Compliance Process Partners LLC. ITIL®: The Basics. OGC. Whitepaper, jul 2013.