kanban for small software projects - School of Computer Science

KANBAN FOR SMALL SOFTWARE PROJECTS

A dissertation submitted to the University of Manchester for the degree of Master of Science in the Faculty of Engineering and Physical Sciences

2011

By Lucas D. Rola School of Computer Science

Contents Abstract

8

Declaration

9

Copyright

10

Acknowledgements

11

1 Introduction 1.1 Project Context . . . . 1.2 Aims and Objectives . 1.3 Scope . . . . . . . . . . 1.4 Dissertation Overview

. . . .

12 12 13 13 14

. . . . . . . . . . . . . .

15 15 15 16 17 18 19 20 20 21 21 22 23 25 26

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Project Background 2.1 Software Project Management . . . . . . . . . . . . . . 2.1.1 Characteristics of Software Project Management 2.1.2 Historical Perspective . . . . . . . . . . . . . . . 2.1.3 Contemporary Software Industry . . . . . . . . 2.1.4 Problems and Challenges . . . . . . . . . . . . . 2.2 Toyota Production System . . . . . . . . . . . . . . . . 2.2.1 Elimination of Waste . . . . . . . . . . . . . . . 2.2.2 Just-In-Time . . . . . . . . . . . . . . . . . . . 2.2.3 Production Levelling . . . . . . . . . . . . . . . 2.2.4 Teamwork . . . . . . . . . . . . . . . . . . . . . 2.3 Lean Principles in Software Development . . . . . . . . 2.3.1 Waste in Software Development . . . . . . . . . 2.3.2 Cross-functional Development Teams . . . . . . 2.4 The Kanban Method . . . . . . . . . . . . . . . . . . .

2

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

2.5

. . . . . . . .

26 27 28 28 29 30 31 33

. . . . . . . .

37 37 38 38 39 40 43 46 47

. . . . . . . . . . . . .

48 48 49 49 50 51 55 60 60 64 69 70 72 74

5 Other Case Studies 5.1 Project Gamma . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79 79

2.6 2.7

The Five Core Properties of Kanban . . 2.5.1 Visualising Workflow . . . . . . . 2.5.2 Limiting Work in Progress . . . . 2.5.3 Managing Flow . . . . . . . . . . 2.5.4 Making Process Policies Explicit . 2.5.5 Improving Collaboratively . . . . Minimum Marketable Features . . . . . System in Operation . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 Research Methodology 3.1 Research Methodology and Data Collection Methods 3.1.1 Systematic Self-Observation . . . . . . . . . . 3.1.2 Archival Case Studies . . . . . . . . . . . . . 3.2 Data Analysis and Evaluation . . . . . . . . . . . . . 3.2.1 Cumulative Flow Diagram Analysis . . . . . . 3.2.2 Nine Aspects of Project Work Analysis . . . . 3.2.3 Waste Analysis . . . . . . . . . . . . . . . . . 3.2.4 Risks Associated With the Methodology . . . 4 System Testing 4.1 Overview of The Projects . . . . . . . . . . 4.2 Project Alpha . . . . . . . . . . . . . . . . . 4.2.1 Motivation . . . . . . . . . . . . . . 4.2.2 Project Alpha - Stage 1, Initial Setup 4.2.3 Empirical Data . . . . . . . . . . . . 4.2.4 Project Evaluation . . . . . . . . . . 4.3 Project Alpha - Stage 2 . . . . . . . . . . . . 4.3.1 Empirical Data . . . . . . . . . . . . 4.3.2 Project Evaluation . . . . . . . . . . 4.4 Project Beta . . . . . . . . . . . . . . . . . . 4.4.1 Initial Setup . . . . . . . . . . . . . . 4.4.2 Empirical Data . . . . . . . . . . . . 4.4.3 Project Evaluation . . . . . . . . . .

3

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

5.2

5.1.1 Explanatory Interview 5.1.2 Discussion . . . . . . . Project Delta . . . . . . . . . 5.2.1 Implementation . . . . 5.2.2 User’s Evaluation . . .

. . . . .

. . . . .

6 Kanban Productivity Tools 6.1 AgileZen . . . . . . . . . . . . . . 6.2 Kanbanery . . . . . . . . . . . . . 6.3 KanbanPad . . . . . . . . . . . . 6.4 Discussion and Recommendations

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

7 Project Evaluation 7.1 Suitability for Small Software Projects 7.1.1 Projects’ Scope . . . . . . . . . 7.1.2 Personal Kanban . . . . . . . . 7.1.3 Group Kanban . . . . . . . . . 7.2 Analysis of the Project Methodology . 7.3 Review of the Project Plan . . . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

. . . .

. . . . . .

. . . . .

80 82 84 85 86

. . . .

88 88 90 92 93

. . . . . .

95 95 95 97 98 99 100

8 Conclusion and Future Work 102 8.1 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 8.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Appendices

104

A Project Alpha - Stage 1

104

B Project Alpha - Stage 2

108

C Project Beta

113

Bibliography

114

Word Count 27,745

4

List of Tables 2.1 2.2

Lean principles and tools . . . . . . . . . . . . . . . . . . . . . . . Waste present in manufacturing and software development . . . .

22 23

3.1

Nine Aspects of Project Work (NAOPW) . . . . . . . . . . . . . .

44

4.1 4.2 4.3 4.4 4.5

Summary Summary Summary Summary Summary

. . . . .

57 58 67 76 77

6.1

Features available in different Kanban productivity tools . . . . .

93

7.1

Applicability of a research model to different Kanban projects . .

99

of of of of of

NAOPW present in project Alpha - stage 1 waste observed in project Alpha - stage 1 . waste observed in project Alpha - stage 2 . NAOPW present in project Beta . . . . . . waste observed in project Beta . . . . . . .

5

. . . . .

. . . . .

. . . . .

. . . . .

List of Figures 2.1 2.2 2.3 2.4 2.5 2.6

Basic Kanban board . . . . . . . . . . . . . . . . Cycle and lead times . . . . . . . . . . . . . . . . Initial Kanban board . . . . . . . . . . . . . . . . Kanban board with an uninterrupted workflow . . Kanban board blocked by a process . . . . . . . . Kanban board with a blocker and team’s response

. . . . . .

. . . . . .

. . . . . .

27 29 34 34 35 36

3.1 3.2 3.3 3.4 3.5 3.6

Project’s research model proposed by the author . . . . . . . . Example of a cumulative flow diagram . . . . . . . . . . . . . Little’s Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of a cumulative flow diagram with a large WIP area Example of a cumulative flow diagram with irregular flow . . Waste analysis model . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

39 41 41 42 43 46

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Project Alpha - Stage 1, Kanban board version 1 . . . . . . . Project Alpha - Stage 1, State 2 from 12.04.2011 . . . . . . . . Project Alpha - Stage 1, State 3 from 15.04.2011 . . . . . . . . Project Alpha - Stage 1, State 4 from 17.04.2011 . . . . . . . . Project Alpha - Stage 1 - Cumulative Flow Diagram . . . . . Project Alpha, Kanban board version 2 . . . . . . . . . . . . . Project Alpha - Stage 2, State 1 from 10.07.2011 . . . . . . . . Project Alpha - Stage 2, State 5 from 24.07.2011 . . . . . . . . Project Alpha - Stage 2, State 8 from 08.08.2011 . . . . . . . . Project Alpha - Stage 1, State 10 from 18.08.2011 . . . . . . . Project Alpha - Stage 1, State 11 from 20.08.2011 . . . . . . . Project Alpha - Stage 1, State 12 from 24.08.2011 . . . . . . . Project Alpha - Stage 2 - Cumulative Flow Diagram . . . . . Comparison of two CFDs from stages 1 and 2 of project Alpha UML Data Structure Diagram For PeopleTalk application . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

50 52 53 54 56 59 61 62 63 64 65 66 67 68 69

6

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4.16 4.17 4.18 4.19 4.20 4.21

Project Project Project Project Project Project

Beta, PeopleTalk, Main Window Beta - Initial Setup . . . . . . . Beta, State 2 from 26.07.2011 . . B, State 3 from 28.07.2011 . . . Beta, State 4 from 01.08.2011 . . Beta - Cumulative flow diagram

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

70 71 72 73 73 75

5.1 5.2 5.3 5.4

Team’s Project Project Project

partial implementation of the Kanban system Delta - Interface . . . . . . . . . . . . . . . . Delta - Graph Prototype . . . . . . . . . . . Delta - Kanban board used in the project . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

81 84 85 86

6.1 6.2 6.3 6.4 6.5

AgileZen - Process Overview Window . . . . . AgileZen - Board Section . . . . . . . . . . . . Kanbanery - Simple Software Project’s Board Kanbanery - Program’s Interface . . . . . . . KanbanPad - Interface . . . . . . . . . . . . .

A.1 A.2 A.3 A.4 A.5 A.6 A.7

Project Project Project Project Project Project Project

Alpha Alpha Alpha Alpha Alpha Alpha Alpha

-

Stage Stage Stage Stage Stage Stage Stage

1, 1, 1, 1, 1, 1, 1,

B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8

Project Project Project Project Project Project Project Project

Alpha Alpha Alpha Alpha Alpha Alpha Alpha Alpha

-

Stage Stage Stage Stage Stage Stage Stage Stage

2, 2, 2, 2, 2, 2, 2, 2,

. . . . .

. . . . . .

. . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

89 90 91 91 92

State State State State State State State

1 from 01.04.2011 . 5 from 19.04.2011 . 6 from 19.04.2011 . 7 from 26.04.2011 . 8 from 01.05.2011 . 9 from 02.05.2011 . 10 from 03.05.2011

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

104 105 105 106 106 107 107

State State State State State State State State

2 from 11.07.2011 . 3 from 14.07.2011 . 4 from 18.07.2011 . 6 from 28.07.2011 . 7 from 04.08.2011 . 9 from 12.08.2011 . 13 from 28.08.2011 14 from 30.08.2011

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

108 109 109 110 110 111 111 112

C.1 Project Beta, State 5 from 01.08.2011 . . . . . . . . . . . . . . . . 113 C.2 Project Beta, State 6 from 04.08.2011 . . . . . . . . . . . . . . . . 113

7

Abstract Kanban is a tool developed by Toyota Motors Corporation to increase productivity and eliminate waste from their large-scale manufacturing processes. Recently, the system has been used as a tool of choice in Lean software development. New variations of the system are becoming increasingly popular in the industry, but ever since there has been no comprehensive and critical evaluation of the Kanban system applied to small-scale software projects. This report describes the Kanban system, its origins and recent adaptations to the area of software engineering. It also discusses the philosophy behind the system and rationale for using its individual components. After that the implementation side of the experiment is outlined and its testing and findings presented. Moreover, the study compares and comments upon a range of productivity tools available for Kanban oriented teams. The paper’s aim is to be used as a manual for all developers who decide to use Kanban for managing their own small software projects. The practical side of the experiment conducted was based on qualitative methods and some statistical analysis including a comprehensive analysis of existing archival case studies. The author, developed and tested a new process refinement framework based on the latest findings in the field of Lean software development. The methodology was used to assess the suitability of Kanban to small software projects which ranged from that of one person to the group of four developers. The experiment shows how Kanban can be successfully used in the context of small software projects which vary in scale and complexity. The paper concludes that the methodology can be freely applied to a wide range of projects. However, its effectiveness decreases with projects’ size becoming smaller. This applies especially to the process refinement methodology which application in some situations does not result in substantial productivity gains.

8

Declaration No portion of the work referred to in this dissertation has been submitted in support of an application for another degree or qualification of this or any other university or other institute of learning.

9

Copyright i. The author of this thesis (including any appendices and/or schedules to this thesis) owns certain copyright or related rights in it (the ‘‘Copyright’’) and s/he has given The University of Manchester certain rights to use such Copyright, including for administrative purposes. ii. Copies of this thesis, either in full or in extracts and whether in hard or electronic copy, may be made only in accordance with the Copyright, Designs and Patents Act 1988 (as amended) and regulations issued under it or, where appropriate, in accordance with licensing agreements which the University has from time to time. This page must form part of any such copies made. iii. The ownership of certain Copyright, patents, designs, trade marks and other intellectual property (the ‘‘Intellectual Property’’) and any reproductions of copyright works in the thesis, for example graphs and tables (‘‘Reproductions’’), which may be described in this thesis, may not be owned by the author and may be owned by third parties. Such Intellectual Property and Reproductions cannot and must not be made available for use without the prior written permission of the owner(s) of the relevant Intellectual Property and/or Reproductions. iv. Further information on the conditions under which disclosure, publication and commercialisation of this thesis, the Copyright and any Intellectual Property and/or Reproductions described in it may take place is available in the University IP Policy (see http://www.campus.manchester.ac. uk/medialibrary/policies/intellectual-property.pdf), in any relevant Thesis restriction declarations deposited in the University Library, The University Library’s regulations (see http://www.manchester.ac.uk/ library/aboutus/regulations) and in The University’s policy on presentation of Theses 10

Acknowledgements This dissertation is dedicated to my parents who taught me how to smile and never give up. They have always provided me with strength and believed in my potential and will always deserve my deepest respect and gratitude. Kocham was i szanuje ponad wszystko! To my supervisor Dr Mary McGee Wood who together with Dr Thierry Scheurer who were providing me with their support and attention throughout the course. Thank you also for never losing faith in my academic abilities and motivating me to always strive for more. I wish everyone to have the fortune of being able to work with you. Being your apprentice has always been an honour and great privilege. It must have been difficult to turn somebody with linguistic background to turn into a computer scientist. Nevertheless, a thousand miles journey has only just started and you have have strived to provide me with the means to carry through it with the best foundations and confidence. I would also like to thank everybody who contributed to my educational and professional successes. To all my teachers, friends and mentors who respect my gratitude and respect, who through their commitment and enthusiasm motivated me to improve myself. I also hope this end result does not let you down through your support all along the long and not always easy way. Tu ne cede malis, sed contra audentior ito

11

Chapter 1 Introduction 1.1

Project Context

The information-based societies of today are in constant need of new and innovative software solutions [Iko10]. Worldwide IT services revenue totalled $763 billion in 2009 [MT10]. As a result of this the contemporary customer-oriented software industry has become demanding and fiercely competitive. This made it an attractive market to get into for many start-up software firms. These software firms are trying to find methods of managing their projects in a low-cost, reliable and efficient way. Over the years, there have been many attempts to tackle these issues. Some of them will be described in this paper, starting with the formal methods of the Waterfall process followed by its iterative adaptations and finishing with the Agile school of software development. The promise of meeting today’s demanding project management requirements comes from Japan, where the creator of Toyota Production System, Taiichi Ono conceived a management system known around the world as Kanban [Ohn88]. For the past few years many multinational companies have become intrigued by its apparent simplicity, transparency and ease of use. Furthermore, it is showing some promising results, particularly when used by small and versatile development teams, where short feedback cycles and small iterations are expected [Kni10]. This is supported by [Kni10] who claims that the method can provide a basic set of tools for rigorous and disciplined software development for small teams.

12

CHAPTER 1. INTRODUCTION

1.2

13

Aims and Objectives

One of the main advantages of Kanban is its flexible and non-prescriptive nature. It provides the team with a small set of guidelines for managing any project. After the primary rules have been applied the project manager needs to make decisions based on his team’s size and performance [Ohn88, Kni10]. The manager can make changes and modify certain attributes of the system. This apparent advantage of Kanban can become an issue for inexperienced users who have never used the method before. Therefore, the purpose of this paper is to evaluate this new methodology in the context of small software projects and make recommendations about the best practices which could be applied to improve their current projects. In order to do that, exhaustive testing and evaluation of the method in question will be conducted. This project will address issues such as: the optimum size of the team, their experience and roles, projects size, use of time and resources. The main aim and originality of this project comes from the investigation of small projects whose scope is outlined in the next section.

1.3

Scope

In order to accomplish the objectives mentioned before, the scope of the project needs to be clearly defined. For instance, it needs to be established what the term ‘‘small software project” means. Despite the existence of many complex software metrics systems the author decided to simplify the one developed by Royce [Roy98]. Royce proposed seven metrics which are under two main categories Management and Quality. Since the quality of software projects is hard to estimate for projects of such a small scale, the author decided to focus on the Management category which includes: project’s budget, lines of code and people involved. Therefore, in this paper a project is considered to be small if it meets the following criteria: • Lines of code: Less than 5000 • Budget, working hours: Less than 1000 hours • People involved: 5 or less

CHAPTER 1. INTRODUCTION

14

Projects of this nature tend to be relatively smaller compared to the rest of the industry. Nevertheless they are common especially when it comes to academia or small software firms. This type of project tends to be iterative in nature, does not require complex domain knowledge nor extensive documentation, and the quality requirements are not very high either [RM00].

1.4

Dissertation Overview

The rest of the document is organised in the following manner. • Chapter 2 introduces some basic concepts related to this project. First of all it describes the area of software development with some of its wellestablished project management models practised in the industry. After that, the chapter also explores the philosophy behind the Toyota Production System and its application to the domain of software engineering. • Chapter 3 describes the way in which the project will be executed together with its research methodology and evaluation criteria. It outlines the individual phases together with the reasons for conducting them. It also describes the research methods which will be used to gather and analyse data and how these will be used in the process of continuous improvement. • In chapter 4 the practical side of the experiment is presented which tests the system on three projects, two using the writing process of the project background report and this document and the third one describing the development process of a small web application. • In the following chapters two case studies are presented using Kanban in the development of their own projects. After that chapter 6 describes and evaluates the productivity tools which are available to the practitioners of Kanban. • The document ends with two chapters concerned with the evaluation and conclusion of the project. These are chapters 7 and 8. The first one evaluates the entire project with respect to the research plan. The second one concludes the project with assessing the methods chosen for its evaluation and implementation. Finally, the paper makes recommendations for conducting other case studies in the future.

Chapter 2 Project Background This chapter will discuss the background to Kanban used for small software projects. We will start by looking into what management and leadership are, and why they matter in project development. This will be followed by an overview, analysis and comparison of different project management methodologies. We will then analyse the history, characteristics and status of contemporary software project management. Finally, the chapter will outline and comment on some of the challenges that the software industry faces today.

2.1

Software Project Management

2.1.1

Characteristics of Software Project Management

‘‘Management is the activity of directing people to accomplish certain desired objectives using available resources effectively. It involves planning, scheduling and assigning work to people.” [SS05] ‘‘Software project management is the art and science of planning, monitoring, leading and controlling software projects.” [SG05] Software project management encompasses many sub-fields such as: risk management which aims at measuring or assessing risk and developing strategies to reduce or completely avoid it; requirements management which is concerned with identifying, eliciting and analysing clients’ requirements; release management which is the process which identifies, documents and schedules releases of new versions of programs. Furthermore, in order to successfully complete desired tasks, organisations need to exercise a certain level of leadership which is defined as: 15

CHAPTER 2. PROJECT BACKGROUND

16

‘‘The action of leading a group of people or an organization, or the ability to do this.” [SS05] However, it is not yet clear how much leadership is required to help development teams. Ikonen and Poppendiecks [Iko10, PP03], for example, both claim that some level of leadership is beneficial for project management as it helps to eliminate waste, and provides a team with a sense of direction. On the other hand Kotter [Kot96] argues that in terms of software development a clear authority can be both chaotic and liberating as it allows greater flexibility for the team, but at the same time can result in disorganisation and lack of clearly defined objectives. When it comes to software engineering it was thought that management practices from the manufacturing world might be successfully transferred, and that such a transfer could be accomplished by someone with business training but no or little programming skills. Reynolds [Rey08, p. 1] however, argues that software engineering is entirely focused on design work, which makes it difficult for somebody without technical background to manage it effectively. According to him, manufacturing is the repeated construction of identical objects, while software is the construction of unique ones. He then goes on to compare a manager who is not familiar with programming languages to the managing editor of a newspaper who cannot write. This feature of software project management must be taken into consideration if we wish to effectively plan a project. The other thing that seems to separate software engineering from other types of software management is its apparent dynamic and unpredictable nature which manifests itself with rapidly changing requirements.

2.1.2

Historical Perspective

Long before everyone had their own personal computer, computer software was developed for dedicated dedicated machines and purposes. Back then, most of the programmers were skilled mathematicians who produced code which was not meant to be reused. In the 1960s Object-Oriented programming became popular and companies realised that repeatable solutions were possible with componentbased software engineering. The software industry became aware of the potential that software programming had over hardware circuitry. The software industry grew very rapidly in the 1970s and 1980s. In order to complete most of the tasks companies decided to apply proven management methods from manufacturing


17

industry. However, most projects were not finished in time or within their budget. Poppendieck [PP03] claims that the reason behind that was the misunderstanding of the true nature of the discipline and misapplication of their methods to the field of software development. Companies soon realised that matching user requirements to delivered products was essential to the success of their projects. As a result the Waterfall model was developed. This methodological approach to software engineering focused on producing extensive documentation of ‘‘Up-Front Requirements” before the design, implementation, testing and maintenance phases. Once each of these phases had been completed, it was impossible to go back and modify it. The methodology is now widely criticised, especially by practitioners of the agile approach for its lack of flexibility and ineffectiveness in coping with changing requirements and system design. McConnell, on the other hand, claims that the methodology can prove useful for some projects, and although it is not as effective in the consumer-driven market of today, it might still be successfully used for certain types of software projects where application security is essential or slow continuous change is expected. He also shows that the bugs found in early stages of project development are up to 200 times cheaper to fix than without using methods based on the Waterfall model [McC04]. This might be an important argument for using the waterfall process in projects that require security and predictability.

2.1.3

Contemporary Software Industry

Today software project methods are still evolving. However, current trends are tending to lead towards iterative development with short release life cycles and continuous contact with clients [DC03]. Examples of such approaches are lean methods and variations of agile software management methodologies [SB01] in particular. These approaches have captured the attention of academics and practitioners in the past few years. There are studies which demonstrate the effectiveness of iterative practices. Together with it a new vocabulary has emerged that defines software in terms of ‘‘components”, and their behaviours as ‘‘use cases” [DC03]. Over the past few years this trend has been sustained, with some new developments in the area. One of them is the attempt to adapt Kanban, the production system used by Toyota Corporation into the field of software engineering. The


18

system can become a good alternative for managers who need an easy-to-follow set of guidelines for their project management without having to resort to weeks of training. With the growing need for IT services around the world, there is a growing trend to create small businesses. These small firms are invaluable contributors to the economy, providing 60% to 80% of new jobs each year, and innovation through competitiveness and a fresh outlook on the market which is beneficial for the economy [DB01]. It has been debated what causes small businesses to fail, because reasons can be numerous. However, in most cases one of the key factors is bad management [DB01]. It will undoubtedly be helpful for these small companies to acquire new, innovative, and easy-to-learn project management methods.

2.1.4

Problems and Challenges

Despite having a myriad of project management methods to choose from, the Chaos Report [Gro95] argues that the vast majority of software firms have their projects abandoned, overdue, or not meeting clients’ requirements. These findings have been questioned by [EV10] who claims that these figures are ‘‘unrealistic and biased”. This might be because of the difficulty of defining what constitutes a successful project, which will be elaborated on in the following section. Charette [Cha05], on the other hand claims that the problems which the contemporary software industry is facing are due to its failure to confront reality, and there is a pressing need for a change in development practices. This can be supported by the fact that in a recent study nearly 2000 government and private sector organisations voluntarily reported the maturity of their software management practices to the U.S. Software Engineering Institute, in Pittsburgh. The research concluded that for over half of these organisations were inadequate in terms of quality management practices [Cha05]. The consequences of bad software management are not isolated from the public domain. In 1986, the London Stock Exchange started to automate its system for settling stock transactions. Seven year after starting it and spending $600 million, it decided to stop it because the management of the project was, to quote one of the managers, ‘‘delusional” [Cha05]. Investigators concluded that no one seemed to have been interested in what the status of the project was. Therefore, the issue of software management seems imperative for modern IT-dependant societies of today and its importance should not be underestimated. These are only some


19

of the numerous examples of ineffective management and unreasonableness in software engineering. Charette concludes that such behaviour happens frequently and is illogical in cases where the likelihood of success is non-existent [Cha05]. Furthermore, since the ‘‘Dot-com bubble” companies have been looking for Return on Investment (ROI) of less than a year, while in the period preceding it the three- to five-year ROI was the norm. This indicates that developing software is more unpredictable and hectic than ever before. Denne [DC03] states that the answer lies in new software development methodologies which are able to divide projects into smaller market identifiable constituents called Minimum Marketable Features (MMF). As it happens, MMF is the main domain of the Kanban system which will be described in later sections.

2.2

Toyota Production System

The history of lean manufacturing goes back to the late 1940s. Right after the war the Japanese automobile industry was in deep crisis because of Japan’s low economic growth. It needed to compete with modern mass-production oriented and technologically advanced American manufacturers whose cars were selling much better due to the state and size of their economy [Ohn88]. Back then the productivity rate of American to Japanese work forces was 1-to-9 in terms of production throughput. This prompted the founder of Toyota Motor Corporation, Toyoda Kiichiro to utter these words: ‘‘We have to catch up with America in three years. Otherwise, the automobile industry of Japan will not survive.” Toyoda Kiichiro According to the father of the Toyota Production System (TPS), Taiichi Ohno, the conventional model of mass production used by Americans stops being profitable when confronted with a recession or periods of slow economic growth. This is when the demand for different types of cars is high and predictions about production levels are hard to estimate [Ohn88]. After the Oil Crisis of 1973 managers at Toyota realised that imitation of the American production system was not suitable to their needs. The idea was to make a system that would minimise or completely eliminate a factory’s inventory and eliminate waste, thus reducing overall production cost. The objective was to create a system which was responsive, and worked without delays, or unnecessary processes.


2.2.1

20

Elimination of Waste

Ohno claims [Ohn88] that the system’s main goal and the fundamental principle is the total elimination of any non-value-adding activity (NVA) from the production process. This new concept of waste was considered then to be a revolutionary idea. It was believed however, that the complete elimination of waste would result in a well synchronised system that would quickly respond to change, making the Japanese production system cheaper and more efficient than the American one. Ohno lists seven kinds of waste that are present in any production system. For instance, there is the waste of inventory related to overproduction and extra processes. Before it was thought that inventory should be kept reasonably large, so that orders could be completed fast. In fact, excess inventory is considered to be the worst types of waste, because it can hide all other type of waste. This may happen even when the system runs uninterrupted and uses its full capacity. This could produce unneeded items which waste the companys resources [Ohn88]. The next one is the waste of waiting, connected to the waste of motion and transportation, which is a symptom of the system’s poor synchronisation. The results are delays in production and decreased throughput of the entire system. One of the basic rules of Kanban is to never send defective products to the subsequent processes. Without applying this principle, the stock of defective components would pile up, making it impossible to assemble properly working final products. This could cause the process to accumulate waste, not only by overproducing items, but also by using manpower, funds and time taken to create defective products. This means that the early recognition of defective products and its solution should be given the highest priority. The biggest challenge is to recognise the biggest sources of waste and their incremental removal, until there is no waste left and all NVAs become absent.

2.2.2

Just-In-Time

Production systems around the world can be categorised into push and pull oriented. The manufacturing process conceived by Henry Ford is an example of a standard push method in which quantity to be produced is determined by demand predictions, and inventory at hand determines the succeeding production periods. When it comes to the pull process used by the TPS, the process is handled in reverse order. The later process withdraws quantity needed from the


21

earlier one, resulting in low levels of inventory and greater adaptability of the entire system to external changes [Ohn88]. The TPS uses the pull method which is supported by the just-in-time (JIT) approach. JIT makes it possible to decide as late as possible, thus eliminating the danger of overproduction, waiting and transportation. The perfect scenario would be to assemble and deliver a product immediately after a customer placed an order. This results in a higher level of system’s adaptability, making it better suited to changes of requirements and market fluctuations [Ohn88].

2.2.3

Production Levelling

Ohno claims that production consistency is more effective than rapid changes and fluctuations in manufacturing processes [Ohn88]. Using JIT with innovative management methods and Kanban board makes it possible to implement ‘‘production levelling”. This is achieved by limiting the capacity of certain stages in the production process, which creates what is referred to as ‘‘flow”. The reduction in workload on each workflow state helps to reduce inventory and equipment depreciation, which prevents individual constituents of the system from becoming overloaded. As a result of the equal distribution of resources it becomes easier to eliminate any defects present in the system. This in turn also facilitates the elimination of waste related to the production of defective products which, as was mentioned before, is one of the central objectives of lean manufacturing.

2.2.4

Teamwork

For years, it has been a common practice for Japanese companies to rotate their employees across different departments in their factories, asking them to work at different stages of the development process. This allows for development of different competencies and expansion of employees’ skill set. According to Ohno [Ohn88] it is more profitable for a company to have a skilled team of cross-functional members rather than a team of specialists. As a result members can be easily replaced because their skills overlap. This creates a higher level of involvement and cooperation within a team, and gives employees a sense of belonging which will be further discussed in the section devoted entirely to cross-functional teams in agile and lean software development.


22

The second most important pillar of the TPS after just-in-time, is the idea of ‘‘autonomation” or ‘‘automation with a human touch”. Ohno argues that machines cannot work independently and need to be maintained and controlled by a skilled workforce. This means that when an abnormal situation arises, the worker would stop the production line and diagnose the problem, learning from it. This allows employees to engage in problem-solving activities, allowing them to become an independent, self-organised and qualified workforce which does not need to rely on external support. Furthermore, the principle of autonomation prevents defective products and overproduction waste. In principle autonomation is a quality control system, which ensures that similar problem will never recur in future [Ohn88].

2.3

Lean Principles in Software Development

The application of lean philosophy to software engineering has been of interest in industry recently. Poppendiecks has rigorously analysed and listed seven lean principles for software engineering [PP03, Hen10] which can be seen in table 2.1. Also according to Poppendieckss the most important principle is the elimination of waste [PP03]. The first column corresponds to the principles of lean software development while the second one contains tools that can be used to successfully implement them in practice. Lean principle Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole

Tools to implement the principle Seeing waste, value stream mapping Feedback, iterations, synchronisation The last responsible moment, making decisions, options Pull systems, queuing theory, cost of delay Self-determination, motivation, leadership, expertise Perceived integrity, conceptual integrity, refactoring, testing Measurements, contracts

Table 2.1: Lean principles and tools as in [PP03]


2.3.1

23

Waste in Software Development

Because waste is listed as the most important principle of lean software development, the author decided to describe and discuss its type, source and origin. As mentioned before the two fields are concerned with different types of artefacts. Therefore, the type of waste which can be observed in both fields also differs in certain aspects. Consequently, [PP03] in her book compares the corresponding types of waste from manufacturing and software engineering (table 2.2). The seven wastes of The seven wastes of software manufacturing engineering Inventory Partially done work Extra processing Extra processes Overproduction Extra features Transportation Task switching Waiting Waiting Motion Motion (humans, handoffs) Defects Defects Table 2.2: Comparison of waste present in manufacturing and software development [PP03] Partially Done Work and Extra Features: Poppendiecks also shows that partially done work tends to become obsolete, and might become a financial and managerial obstacle to finishing projects [PP03]. This is because of the developers’ uncertainty as to whether the partially done software will work properly when integrated with the rest of the project. Unfinished development is wasting a company’s resources and therefore can carry high financial risk. Also adding extra features to the project which are not needed by a client produces waste which is similar in nature to partially done work. For instance, a company might have an unfinished part of a project which was successfully developed and tested, but unless it can be sold it remains an investment with no return. Consequently, minimising or completely removing extra these two types of waste can be both risk-reducing as well as waste-reducing strategy. Extra Processes: Software engineering is often full of paperwork, requirements documentation and other documents. Paperwork consumes resources and slows down a team’s productivity. According to [PP03] the worst type


24

of paperwork is the one that carries no value for anybody on the team, but is done merely for procedural purposes. Poppendiecks suggests using a template-based format in order to reduce the size of requirements documentation and rapidly validate and understand its content [PP03]. Also unreasonableness and overburdening people with work produces waste as it can cause task-switching, fatigue and general loss of productivity, and proliferation of defects. Waiting: Waiting caused by staffing, excessive requirements documentation, reviews, testing and approvals are amongst the biggest wastes in software development [PP03]. In case of a new requirement delays can slow down the team’s ability to respond quickly. The amount of damage that can occur from this type of waste generally varies between projects. Poppendiecks [PP03] suggests deciding as late as possible in managing software projects as a method of dealing with uncertainty and making informed decisions. Motion: When the sum of all knowledge of a given team is unevenly distributed, people learn from each other by asking questions, which often results in physical movement. Development and coding requires a great deal of concentration, which is usually lost through movement and task-switching; although [IKA10] argues that team communication should not be considered waste since it generally improves a team’s skill set and involvement in the project. There are also other things that can move like documents, requirements and code which needs to be sent from coders to testers. Also, in the case of documentation of requirements, there are a number of things that are not explicitly expressed. This results in incomplete documentation and people’s misinformation which can generate additional waste. Defects: Defects in software development can either mean a problem lasting three minutes or several months depending on its severity. If the problem is small it can be fixed right away by a developer. It can also be ignored and left in the system without being fixed which will make it even more difficult to fix in later stages. For this reason Poppendiecks following recommendations of the ‘‘lean” manufacturing advises fixing defects as soon as possible [PP03].


25

Management Activities: There is no direct correlation between management activities and adding value to a product. However, they do have an impact on waste reduction in an organisation as stated by [PP03]. Project tracking, and control systems also do not add value but help to reduce waste and implement JIT philosophy. This is supported by Ikonen who claims that ‘‘the amount and significance of waste can be significantly reduced with the right leadership” [Iko10]. There should be a balance between system complexity and its usefulness for a particular project [PP03]. Poppendiecks also claims that seeing waste is an ongoing process of changing the way people think about things, and is usually easier to identify in a crisis.

2.3.2

Cross-functional Development Teams

As mentioned before a cross-functional team is one of the most important characteristics of a ‘‘Lean-oriented” development process. Therefore, as a result of its significance for the methodology it needs to be discussed. In [Hen10] there are numerous examples supporting self-organised software teams. Most of these sources support autonomy, collaboration and initiative of self-organised and cross-functional teams. Cohen and Bailey for instance categorised the advantages of having an empowered and lean software team. These amongst others include increased job satisfaction and commitment to work, trust in the management, increased participation, and less redundancy [CB97]. Autonomous teams might also prove more effective when projects are highly innovative and are developed under uncertain and changing circumstances, thus requiring more creativity and inventiveness from their members [Hen10]. This is supported by [Pin09] who in his speech shows the ineffectiveness of reward-based, incentivised production systems, in the context of complex and creative types of tasks. Furthermore, Karhatsu suggests a ‘‘subtle” form of control over the team, which can help to sustain team’s spontaneity and creativity while strengthening its sense of direction and purpose. [Hen10, Iko10]. On the other hand other sources cited in [Hen10] question the effectiveness of autonomous software teams. Some of them claim no connection between empowerment and success . Others identify the limitations of such teams in the context of big organisations [Hen10]. However, big software projects are not the subject of this paper. Karhatsu also shows that the self-organised team can easily become disintegrated if it does not follow certain lean principles [Hen10].


2.4

26

The Kanban Method

The Kanban method is ‘‘an approach to gradual and evolutionary process and systems change for organisations” [Dav10]. It uses work-in-progress in order to expose problems, stimulate collaboration and continuously improve the system. One example of such a pull system, is the Kanban system from which the method takes its name. According to [Dav10] the Kanban Method can be implemented as an evolutionary change of an existing system in a give organisation. The Kanban method is rooted in three basic principles: Start with what you do now There is no universal prescribed set of rules which would work for every company, team or project. The team or person who wants to implement this approach should continuously strive to implement changes into her or his existing system. Agree to pursue incremental, evolutionary change The organisation or team must agree to incrementally improve the way they work. Because of organisations resistance to change the incremental change will prove more effective. This encourages small changes which have more chance of being sustained by the team. Respect the current process, roles, responsibilities & titles The fear of change might be due to the organisations’ processes or elements that are generally accepted and might be worth preserving. By agreeing to respect current roles and job titles it becomes possible to eliminate initial fears. This helps to gain greater support for the new system. Presenting the Kanban Method as an alternative to sweeping changes in titles, roles or responsibilities might help individuals become more aware of its advantages.

2.5

The Five Core Properties of Kanban

According to David Anderson [Dav10] there are five core principles which are present in each successful implementation of the Kanban Method: 1. Visualising the workflow 2. Limiting Work In Progress (WIP) 3. Managing Flow


27

4. Making Process Policies Explicit 5. Improving Collaboratively (using models & the scientific method)

2.5.1

Visualising Workflow

The main way of visualising the workflow is by using the tool called a Kanban board. It can for example be a whiteboard with stickers on it or an electronic card wall system. Figure 2.1 shows a basic Kanban board with the most common sections used. It is divided into columns each of which represents a different stage in the product development. The board in figure 2.1 is divided into five stages each capable of receiving different components of the project. Most Kanbans include their own ordering of columns but typically, each version would have its own version of ‘‘To do”, ‘‘Work-in-progress”, and ‘‘Done” column. When a request or ticket is added into the ‘‘Work-in-progress” section it needs to stay on the board until it reaches the ‘‘Done” column. The entire process will be discussed at length in section 2.7.

Figure 2.1: Example of a basic Kanban board as in [Kni10]. Numbers show WIP limits for each individual process in the workflow. The Kanban board is the most integral and important element contributing to the system’s transparency and its ability to reduce waste. It makes the entire process transparent to the team, exposes bottlenecks, queues and most important all waste [Kni10]. Furthermore, from the team’s point of view it contributes to cultural change, encouraging collaboration and discussion, which is supported by


28

early case studies [Kni10, Iko10]. This results in constant improvement of the system providing the team with the sense of control and responsibility for the entire project [Kni10].

2.5.2

Limiting Work in Progress

Kanban prescribes designating a column which is used for the things that are currently being worked on. It needs to be limited based on the team current performance, cycle times, number of people involved in the project, team structure and other considerations. Setting the optimum number of items allowed to be in work in progress is essential to the system efficiency and should be set for each Kanban system separately [Kni10]. Setting the limits too high, will overburden the team with work creating waste and idle tasks. On the other hand, if the limits are set too low, then people can become idle which leads to bad productivity. Kniberg [Kni10] suggests first setting the WIP by taking the number of members in a given team and subtracting one from it. The reason is to increase collaboration and communication within the team [Kni10]. Having a limited WIP allows a team to limit the work it has to its current capacity. The method of limiting WIP is based on the Theory of Constraints which increases teams’ responsiveness to prospective problems helping them to finish more items in less time and fewer defects [Kni10].

2.5.3

Managing Flow, Measuring Cycle and Lead Time

There is a difference between what the users of Kanban call lead and cycle times. As cited by [Roo10] cycle time is the time measured when the actual work begins on the request and ends when the title is ready for delivery. On the other hand the lead time clock starts when the request is made and ends at delivery. Lead time is more important from the customers point of view while cycle time is the way of measuring process capability by the developers [Roo10]. As it can be seen in figure 2.2 lead time is normally much longer than. It might take developers 100 days to agree on a feature with a client, and result in 1 day of development work. Brodzinski [Bro10b] suggests measuring cycle time from the moment that an item is placed in the WIP and ends up in the ‘‘done” column, rather than as from the ‘‘backlog” column. As a reason for that he states that his team can often


29

Figure 2.2: Cycle and lead times as in [Roo10] shuffle the requests in the ‘‘backlog” column which makes it difficult to measure the cycle time precisely. Measuring cycle time allows developers to measure the system throughput and provides them with an indication of its performance. It also allows the effective allocation of resources in a team. For example, when a team does not complete a specified number of tasks within some period of time it might indicate that the WIP limits are set too high, or the number of columns is improperly organised. The cycles should not be too long nor too short to allow receiving regular feedback from the client and giving the team enough time to make a high quality component for client demonstration. It also allows developers to make predictions about the completion of each task, thus managing client’s expectations more effectively [Kni10].

2.5.4

Making Process Policies Explicit

The main use of a Kanban board is to drive communication within a team and to make process policies explicit. Doing so is said to be a key enabler of evolutionary, collaborative change in a Kanban system. Until a process is understood and apparent to its users it is often hard or impossible to discuss its improvement. According to [Dav10] without this, any discussion of problems tends to be emotional, anecdotal and subjective. Making processes explicit makes it possible to hold rational, empirical and objective discussion of relevant issues. Because of that the entire organisation needs to identify opportunities to improve the system and become involved in its implementation and management. This in turn will make learning become the major goal of the organisation.


2.5.5

30

Improving Collaboratively With Models and The Scientific Method

When teams share an understanding of theories about work, workflow, process and risk, they are more likely to contribute through shared comprehension and actions which resulted from a consensus. The Kanban Method suggests using scientific methods to implement continuous and evolutionary change. The common methods used are: The Theory of Constraints (TOC) This theory states that processes, organisations can be vulnerable because the weakest person can adversely affect the outcome. This phenomena can be illustrated by the following idiom: ‘‘A chain is no stronger than its weakest link”. An analytic approach of TOC tries to identify the system’s constraints which prevent the system from achieving more of its goal [GOL98]. This methodology is closely linked to the Toyota Production System which was described before. Its premise is that organisations can be measured and controlled by variations on three measures: throughput, operational expense and inventory. Furthermore, constraints can be categorised as internal or external to the system. External constraints come mostly from the external market which can either demand too much or too little throughput from the system. In either case the system can generate waste either in overproducing items or not taking advantage of the market’s full potential to yield profit. The internal constraints can be: equipment, people and policies. The equipment can be obsolete, hence preventing its users from working efficiently. People can also limit the system by holding mental models which become a constraint themselves. Finally, policies written or unwritten can prevent the system’s users from effectively achieving their goals [GOL98]. The System of Profound Knowledge This theory was proposed by William E. Deming who also advocates the transformation of organisation’s management style [Dem00]. He says that this transformation requires a view from outside because of people’s involvement and attachment to the process. This philosophy advocates changes that an individual can take to change his organisation, these are: a) Appreciation of a system: one should seek to understand the processes involving suppliers, producers and customers of goods and services.


31

b) Knowledge of variation: the range of causes involving variation in quality, the use of statistical sampling in measurements. c) Theory of knowledge: the concepts related to epistemology1 explaining knowledge, its origin, nature and limits. d) Knowledge of psychology: concepts involving human nature, cognitive processes, motivation and emotions. According to Deming one does not need to be an expert in any of the above in order to successfully apply them in his or her organisation. He also claims that workforce is responsible for only 15% of mistakes where the system and management for 85% unintended consequences [Dem00]. Lean Economic Model The model was explained in detail in section 2.3. It involves elimination of waste, identification and optimisation of flow and value streams, implementing the system’s resistance to change and striving All of these models complement each other in one way or another and strive to improve the organisation by learning about it and making constant small improvements for the process called Kaizen (jap. change for the better).

2.6

Minimum Marketable Features

Before any work can be started and tasks can be assigned to team members the program needs to be split into a set of minimum marketable features (MMF). The term was first introduced by Denne and Cleland-Huang as ‘‘A chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity” [DC03]. These are pieces of functionality of a computer program which are as small as possible yet sellable to a potential customer. In his book Denne’s shows how frequent delivery can improve value and ROI. In one of the examples he shows that ROI increased from 47% to 188% just by delivering multiple releases. Furthermore, it improved the internal rate of return from a borderline 13% to 36%. All of this resulted in much better cooperation with a customer which resulted in less code refactoring2 and a project which effectively became self-funding. This illustrates that phased delivery can be very 1

the theory of knowledge, especially with regard to its methods, validity, and scope, and the distinction between justified belief and opinion. [SS05] 2 A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour. [Fow01]


32

effective if it is done properly [DC03]. However, the concept of ‘‘incremental funding methodology” which MMF is a part of proves to be an ambiguous concept which is scarcely discussed in most of the relevant literature. In NetObjectives glossary, for instance it is defined as: ‘‘The smallest set of functionality that must be realized in order for the customer to perceive value. An ‘‘MMF” is characterized by the three attributes: minimum, marketable, and feature. A feature is something that is perceived, of itself, as value by the user. ‘‘Marketable” means that it provides significant value to the customer; value may include revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty. A release is a collection of MMFs that can be delivered together within the time frame.” [Tea11] Brodzinski however, claims that in real life marketability needs to be sacrificed in order to maintain the similar size of features. Also there are many components of a computer program which might be difficult to sell to a potential customer such as, architectural changes or rewriting one of integration interfaces from the beginning [Bro10c]. Also MMF can be easily understood by domain experts but not necessarily by average customers or can have no demonstrable value to them [Chr10]. Another criticism of MMFs is that the functionality containing a few dozen lines of code can represent the same functionality to the customer as the one containing several thousands lines of code. In the case in which MMF vastly differ in size the average cycle and lead times can be deemed useless since any prediction which will be based on them will be inaccurate [Bro10c]. Brodzinski recommends an alternative which he refers to as Standard Sized Features (SSF). According to him SSFs have the advantage of being easier to estimate. This in turn allows the team to measure Cycle and Lead times more accurately. A similar approach is advocated by David Anderson, the creator of Kanban for Software Engineering who believes that the Lean/Kanban community is not adhering to the Denne and Cleland-Huang definition. Consequently, Anderson [And03] proposes the term ‘‘Minimum Marketable Release (MMR)” which is said to be: ‘‘A set of features that are coherent as a set to the customer and useful enough to justify the costs of delivery”. The advice which [Chr10] gives, recommends assessing the rationality of a particular feature by imagining an email from a potential customer summarising


33

the features as bullet points of a new release. If the feature’s inclusion in such a list cannot be justified then it should not be made a separate MMF. The same author prescribes visualising a particular feature as a part of a larger hierarchy of features. For example ‘‘geotag photo” can be a descendant of ‘‘photo sharing” which in turn can be a descendant of ‘‘iPhone client”. Therefore, the abstract can no longer be in the backlog, but many of their descendants can. This idea is consistent and very useful to developing Java applications which are based on inheritance, modularity and abstract collection of classes [Chr10]. Moreover, Shore recommends ‘‘just-in-time” design and elimination of technical dependencies by reducing the need to build extra technical architecture up-front. The principle of continuous design seems to be used by most Kanban teams by introducing an extra column called ‘‘design” [Sho04].

2.7

System in Operation

Before the actual work can be started the team members need to be assigned roles. For the purpose of discussion let us suppose that there is a team consisting of four members. There is Andy who is a project manager and developer, John and Mark who are also developers and Emma who acts as a tester. Andy is responsible for the ‘‘Release” column which is used for integrating the software modules and accepting them by the client. He also supervises the project and arranges the tickets in the ‘‘To do”. The order depends on the client’s current priorities. Also, the team that has just been described is cross-functional which means that each of its members can perform a different role within a team if necessary. As shown in figure 2.3 the team decided to split their workflow into five sections. ‘‘To do” section can hold up to 5 requests. Columns ‘‘Development” and ‘‘Testing” were also split into two additional columns ‘‘ongoing” and ‘‘done”. Kniberg [Kni10] suggests this solution as a way of indicating which stories are completed, and can be moved to the subsequent process. The team also has decided to set the WIP limits in ‘‘Development” column to 3, because of having two nominal developers with one project manager who as mentioned before can work as a developer. Moreover, the team decided to set ‘‘Testing” and ‘‘Release” section’s WIPs to 2 since the team has got only one nominal tester and testing is relatively quick.


34

Figure 2.3: Initial Kanban board Finally, before the features can be posted on the Kanban board, first the project in agreement with the client needs to be split into user stories in the form of Minimum Marketable Features (MMF) [DC03, Coh04]. Figure 2.4 is an example of Kanban working properly without any unexpected problems. In this case the tickets can easily move from the left side of the board to the right through every stage of the process. Once the ticket was selected as a priority it goes to the ‘‘Development” section after which it waits in the ‘‘done” column to be moved into the testing phase. It can happen only if the WIP is not reached by the ‘‘testing” phase. The entire process is self-explanatory and can be easily understood by looking at figure 2.4.

Figure 2.4: Kanban board with an uninterrupted workflow


35

When an abnormal situation arises items can no longer move freely across the board. As can be seen in figure 2.5 there is a problem with item ‘‘B” which is referred to as a ‘‘blocker”. In the process of testing the items, Emma reported item ‘‘B” as being unable to compile. She tried to fix the problem herself but failed after which she decided to report the problem through the Kanban board. Thanks to the visual nature of Kanban the team is able to immediately identify the problem and respond accordingly.

Figure 2.5: Kanban board blocked by a process In order to remedy the situation, relocation of the team’s resources is necessary. As it can be seen in figure 2.6 due to the ‘‘blocker” being present in the system, Andy, Mike and John are either completely idle or unable to utilise their full capacity. Since John and Mike were involved in the development stage of the item mentioned, their expertise can prove useful in solving the problem. Furthermore, when the team is working together on the bottleneck they are likely to learn form each other and contribute to the team’s overall competency [Kni10]. For that reason, Andy decided to send John to assist Emma in fixing the problem and, since he finished working on item ‘‘H”. As seen in figure 2.6 Andy is being idle in the ‘‘Release” section of the process, therefore his skills can be utilised to test item ‘‘D” in order to make it ready for moving to the ‘‘Release” section.


36

Figure 2.6: Kanban board with a blocker and team’s response Chapter Summary In this chapter a description of the software industry has been presented with its history, current trends and recent developments. The section’s primary focus was to describe the philosophy and application of lean production methods developed by Toyota Corporation to the domain of software engineering. It described in detail the most recent adaptation and characteristics of Kanban to the domain of software engineering. The chapter also described how the Kanban system might be used in the context of small development teams. It also described how small teams’ capacity can be fully utilised by using the effective use of Kanban.

Chapter 3 Research Methodology The purpose of this section is to describe the theoretical framework behind the project. It describes the methods to be used in order to collect, interpret and evaluate the data. Each of these methods has its own purpose with associated risks. Consequently, the reasons for choosing them will be provided and potential ways of mitigating them listed. The section will also address the risks associated with the project itself and outline the plan of its implementation.

3.1

Research Methodology and Data Collection Methods

Although it is possible to use more than one type of data, the author decided that the main approach of his research will be qualitative. This is due to the project’s nature which will involve extensive descriptions of mechanisms and meanings which are more suitable to be analysed qualitatively [Hen10]. Moreover, in qualitative research it is possible to make use of existing archival materials which are suitable for this experiment [Yin03] . The empirical part of this research consists of three case studies. The first two will be conducted on the author’s own projects. These include a small software project developed in the course of his masters degree called ‘‘Project Beta”, and a project which aims at monitoring the process of his dissertation writing called ‘‘Project Alpha”. The third case study called ‘‘Project Gamma” was planned to be be conducted on a group of students from the School of Computer Science at The University of Manchester who were going to use Kanban as a part of developing

37

CHAPTER 3. RESEARCH METHODOLOGY

38

their MSc projects. However, the decision was made not to use it for reasons which will be provided in later section. The project also includes data from archival case studies of projects using the methodology which were conducted in the past. The research methodology will mostly consist of self-observation and the analysis of existing case studies. The approach of the experiment is to analyse projects of different sizes in order to perform their comparative analysis and evaluation.

3.1.1

Systematic Self-Observation

The goal of Systematic Self-Observation (SSO) is the generation of field notes that are accurate descriptions of participants’ experience. They are highly subjective, and the observer is encouraged to describe the experience in his or her own words. According to [RR02] it is an adaptable, practical, economic and productive research strategy as well as a legitimate source of information and insight. The method can be successfully applied to the study because of its minimal financial requirements. What is required from the researcher are critical thinking skills and the ability to accurately record his insights of a given phenomenon. The plan was to collect the data from the projects using notes, photographs and audio recordings. One of the major risks of this method is its subjective nature which can lead to scientific biases, for instance confirmation bias, which is a tendency of people to favour information that confirm their hypotheses regardless of its credibility. The next subsection will explain the ways of reducing this risk.

3.1.2

Archival Case Studies

In order to stay abreast with the latest innovations in the field of lean software development, this research will make extensive use of recent sources of information about the domain. This will be conducted by the use of blogs and case studies which are available on the internet. Also, when making use of the online material one has to be aware of its elusive nature. For this reason, the author decided to make use of the sources which have been available on the internet for at least a year. The case studies from this project can also be successfully used by the author to gather data and the analysis of existing case studies. All of the projects mentioned vary in size and complexity. This wide spectrum of project’s scope will provide the author with an opportunity for their objective evaluation and comparison.


3.2

39

Data Analysis and Evaluation

After the project has been completed the data from different sources will be consolidated and conclusions will be drawn. The author will seek to understand how Kanban impacts software projects of different types and sizes, from the team of one person developing a small software project to the one involving more participants. The hypothesis is that as the group dynamics change and there will be fewer communication pathways involved, the cooperation and team’s learning might be further amplified, together with the elimination of waste related to decision-making and waiting. On the other hand since there are fewer people involved it might result in smaller throughput of the entire team causing the system to be more of a burden and less of a helpful tool. These will be answered after the data from different sources has been collected and critically analysed against each other. Consequently, the conclusions about the effectiveness of Kanban for small software projects and recommendations for its use will be made.

Figure 3.1: Project’s research model proposed by the author In accordance with the improvement process mentioned before called Kaizen and Deming’s concept of profound knowledge [Dem00] the author decided that after the completion of each project’s individual stage the critical analysis and evaluation was necessary. Consequently, after stages 1 and 2 of the Project Alpha and after completing project Beta an analysis and optimisation of their processes will be performed. In order to do that there is a need for a structured approach of collecting and evaluating qualitative data. With that said, the author decided to perform an Analysis of Cumulative Flow Diagrams [Yer11], Waste Analysis [IKA10], Nine Aspects of Project Work [IPF+ 11], of each project and his own subjective evaluation of each of the projects. The research model illustrating this approach can be seen in figure 3.1. The figure shows that after implementing and testing of each project its evaluation will be conducted using the three evaluation frameworks selected by the author. Based on that, the improvements will be made after which the next phase of a given project will be conducted. This approach


40

is iterative in nature and is aimed at reinforcing the Kaizen process. At the end of this process the data from all projects supported by case studies will be consolidated and evaluated. This will result in conclusions about the usefulness of the Kanban method for small software projects.

3.2.1

Cumulative Flow Diagram Analysis

One of the tools that Agile/Lean oriented teams use in order to analyse and evaluate their project’s flow is called a Cumulative Flow Diagram (CFD). The diagram shows a detailed picture of an entire process. The horizontal axis of the diagram represents days during which the project was being developed. The vertical one is used to indicate the number of stories that a given column contained in a particular period of time. By analysing the diagram the team can visually identify which phases need refinement and where the system is the least effective in generating throughput. Furthermore, the tools can provide the team with information about its throughput, lead time and cycle time discussed in section 2.5.3, wait time, blocked time and project’s efficiency. The diagram can reveal any bottlenecks and work-in-progress which can have an impact on the team’s performance. It is a useful analytical tool for improving the system’s performance based on its past performance. Diagram 3.2 shows an example of such diagram. The workflow can be visualised as a state of a Kanban board at any given time. As can be observed in figure 3.2, in week 12 there were approximately 13 items in the ‘‘deployed” column, 18 in ‘‘approved”, and 20 in ‘‘QA”. The lead time at any point in time (the X axis), can be read as the distance between the top left area and the bottom right one. For instance, in week 18 the lead time was 13 weeks [Hel09]. This means that in week 18 the average time to market for a single feature was 13 weeks. The relationship between WIP, Lead Time and Arrival Rate can be explained with Little’s Law (figure 3.3). Let’s assume that one wants to reduce the lead time. As can be seen in the equation, reducing the WIP will also reduce the lead time provided that the throughput remains constant or is increased. In consequence, between weeks 13 and 18 the team deployed 69 new features. This gives us an average throughput rate of approximately 5.3 features per day. As was mentioned in section 2.5.3 the lead time is the total time that the feature was being developed, including analysis, design and acceptance phases. On the other hand, the cycle time is the total time when the feature was being actually developed usually in


41

Figure 3.2: Example of a cumulative flow diagram [Yer11]

T hroughput =

W IP Lead T ime

Figure 3.3: Little’s Law the ‘‘in progress” phase. The cycle time is defined as an inverse of throughput. In the example above it was approximately 0.19 weeks per feature which means that the team finished was able to finish approximately 1 feature per day [Hel09]. The diagram shown in figure 3.2 is what might be considered an example of a regular and consistent flow. As can be seen the WIP is decreasing over time and the number of items in the ‘‘Deployed” column is decreasing at a rate which is significantly greater than the number of items in the ‘‘Backlog” column. The lead time is also decreasing which is a good indicator of team’s increased productivity, probably through collaboration, learning and short feedback loops from the client.


42

Figure 3.4: Cumulative flow diagram with a large WIP area [Yer11] In contrast to this let’s have a look at figure 3.4. This CFG diagram shows that there are possibly many features in progress which the team is unable to finish. Another explanation might be that the next stage cannot hold more items because of being blocked. Figure 3.5 is an example of a so called fingerchart diagram where a certain column or stage in the process holds a number of items for some period of time. As can be seen in the figure, the ‘‘BA/QA” band thickens in the region shown. This could mean that the client is waiting until the end of the week for signing off stories and moving them to the ‘‘Done” column. This situation does not need to have an adverse effect on the flow, however its cause should be investigated. The source of delay might be something that the team needs to inquire about as a sign of the customer becoming overwhelmed with features being sent to him or perhaps other causes. To conclude, each of the three practical projects which are developed by the author will be analysed using this technique. In order to provide the system with evolutionary change, an analysis is to be conducted and possible improvements will be suggested.


43

Figure 3.5: Example of a cumulative flow diagram with irregular flow [Yer11]

3.2.2

Nine Aspects of Project Work Analysis

This research framework of analysing a Kanban based project was proposed by [IPF+ 11]. Table 3.1 consists of nine literature-based aspects of project work (NAOPW) with the expected influences that Kanban is likely to have on them. As suggested by [IPF+ 11] the influence of these nine aspects is reflected in the Kanban process model. These aspects are then contrasted with the waterfall process model because of its historically important and strong impact on software development projects. The values of the agile approach are also taken into account because they are considered to solve many problems of plan-driven, conventional software development method i.e. the waterfall process model. The amount of documentation The waterfall model implies a lot of documentation [IPF+ 11] because every phase produces documents for the next one. Agile manifesto on the other hand places ‘‘working software over


44

Aspect of work Documentation Problem solving

Expected influences of Kanban Only if the customer needs it Unexpected problems are found quickly on the Kanban board; they are thus tackled immediately Visualization The work is visualized on the Kanban board Understanding the whole One of the Lean key principles; Kanban does not offer tools though Communication Rapid and plenty Embracing the method An intuitive method (e.g., visualisation) Feedback Rapid and plenty; Supports also regular meetings with the customer Approval process Best expertise is at each workstation or developer; no complex approval process Selecting work assignments Developers select and pull their work voluntary and individually Table 3.1: Nine Aspects of Project Work as suggested by [IPF+ 11] comprehensive documentation”. In Kanban the documentation is provided only if the customer requests it so it is ‘‘pulled” from the software developers rather than developers ‘‘push” it to the customer [IPF+ 11]. Problem solving As pointed out by [IPF+ 11] waterfall tends to hide problems. They tend to surface late in the development process and are often ignored. On the other hand Agile and Lean philosophy is welcoming to the changing requirements. The Lean philosophy recommends solving problems immediately as to prevent them from re-occuring in the future. Visualization The waterfall model is visual because of the documentation it produces. This documentation shows the amount of work that was done. According to [IPF+ 11] Agile process remains non-visualized even though agile Scrum process model1 asks to monitor and update the progress. In contrast visualization has always been the central idea of Kanban. By looking at the board its different elements can be easily traced, whether it is a single task or an entire board. 1

An iterative, incremental framework for software project management which is seen in agile software development. It contains a set of practices and predefined roles that are used in the Agile process.


45

Understanding the whole The waterfall model supports understanding the whole, because the system is known after the specification phase [IPF+ 11]. Agile principles explicitly ignore this issue. In contrast as was mentioned before one of the most important principles of Lean is seeing the whole. However, this principle is not directly supported by the Kanban system since the board does not tell its developers how much work is in the system altogether. Communication Informal communication is not encouraged in the waterfall model since each phase produces comprehensive documentation. Agile together with Kanban directly encourage communication. In both approaches obstacles are removed in order to facilitate it. Good communication according to the Lean philosophy is the key to learning, effective problem solving and evolutionary change of the whole team. Embracing the method Poppendieck [PP03] suggests that if a particular methodology is not easy to adopt, the developers will most likely ignore it. According to [IPF+ 11] the waterfall model provides an illusion of being orderly and accountable. It requires deep knowledge of the problem field and process itself in order to become successful in using it. Furthermore, Agile process models are said to be hard to follow especially by inexperienced users. The Kanban method on the other hand encourages evolutionary change and provides developers with more freedom. However, the only rule it enforces is that the workflow must be visualised [IPF+ 11]. Feedback The waterfall model is limited in giving feedback except between the phases. Feedback is usually considered to be inferior to the predefined plan that every developer should follow. Agile methodology encourages changing requirements and high level cooperation with the customer [Ben01]. Finally, Kanban encourages even more frequent and regular feedback loop from the customer [IPF+ 11]. Approval process The approval process is said to be ‘‘strenuous” when using the waterfall process [IPF+ 11]. After each phase the management needs to approve the documents. Agile and Lean approaches stress the meaning of selforganised and independent teams. Furthermore, extensive documentation and paperwork is considered to be a waste.


46

Selecting work assignments The waterfall model does not prescribe how to prioritise or select tasks of work to be executed. According to the Lean and Agile philosophy the work is self-organising and work should be prioritised in order to achieve maximum level of customer’s satisfaction by delivering a valuable product [IPF+ 11].

3.2.3

Waste Analysis

The author will also seek to analyse waste present in software projects of different size using a framework developed by [IKA10] figure 3.6. Following Poppendieck’s and Ikonen’s guidlines [PP03, IKA10] the first step is to recognise waste corresponding to one of the seven categories of waste. Step two is concerned with determining the source of waste and the final step involves finding its causes. This can be evaluated by three different team members each of them representing different roles: less experienced, more experienced, and the team leader. The reason behind this is to create more perspectives and greater objectivity of the method. The data collection can be done using thematic interviews, asking users to provide arguments supporting their claims related to their recognition of waste. However, as was mentioned before the group experiment was only partially implemented. Therefore, the author decided that using the existent framework to analyse and self-reflect upon the projects which he developed will be the best course of action.

Figure 3.6: Waste analysis model suggested by [PP03]


3.2.4

47

Risks Associated With the Methodology

As mentioned the method is not free of scientific biases, for instance, the confirmation bias which was mentioned before. Another challenge is related to the capturing of data which might overload the observer’s memory. The risk can be minimised by developing a template for making notes and by careful design of an experiment. As suggested by [Yin03] the triangulation of data sources can be an effective way of minimising the risks mentioned. Following this, the author intends to use multiple sources of evidence in order to increase the objectivity of the observation. These will include daily notes from all the experiments, the decisions made, photographic evidence of all Kanban boards and how the project is progressing. Chapter Summary This chapter discussed different methods of data collection and its evaluation. It first presented the different methods of collecting data from observation of case studies, and surveying of case studies from literature. The advantages and challenges of all the methods were listed and reasons behind choosing them were elaborated upon. The section also presented the evaluation framework which will be used to critically analyse each of the projects to be undertaken in the course of this study. Finally, the author discussed the risks inherent to the evaluation framework together with the methods of mitigating their adverse effects.

Chapter 4 System Testing After specifying and describing the implementation of the project, its empirical testing needs to be conducted. Thus, the main purpose of this chapter is the practical application and evaluation of the three projects undertaken by the author. The experiment will result in a set of observations which will then be evaluated. This will need to be done before each project in order to utilise the process of continuous improvement called Kaizen. The final evaluation and analysis of the methodology tested will be conducted in the subsequent chapter. Also, it should be noted that for readability reasons only a few snapshots of the Kanban board from each project were included in this chapter. The rest of them can be found in Appendix A.

4.1

Overview of The Projects

The empirical part of the project consisted of three projects which differed in size, complexity and nature. The first one called ‘‘Project Alpha” was focused on managing the process of writing this dissertation and the author’s MSc project background report. This project was divided into two stages which corresponded to developing each of these two documents. As will be seen later, each stage was divided into ‘‘states” which are snapshots of the Kanban board at a particular moment in time. The second project was named ‘‘Project Beta” was concerned with the development of a small web application called PeopleTalk which was one of the assignments for the ‘‘Developing Web Applications” module. The third one ‘‘Project Gamma” was supposed to be a group project involving students from the University of Manchester developing a Personal Learning Environment 48

CHAPTER 4. SYSTEM TESTING

49

application as a part of their MSc project. However, due to the circumstances that will be explained in Chapter 7, the decision was made not to implement Kanban entirely, but instead use some of its features.

4.2

Project Alpha

Project Alpha was divided into two stages. The first one was concerned with the development of the project background report by dividing it into standard-sized features which will be its chapters and sections and then composing them. The second stage focused on the development of this dissertation paper. Also, the action of describing the dissertation will be need to be done simultaneously with its development. This means that although this stage is the second part of project Alpha, it will be done at the end of the project’s development, as to guarantee the presence of the material to be described.

4.2.1

Motivation

The main reason behind using a writing process as an illustration of managing a production is their similar nature. For instance, Kufmann claims that both of these are multi-step processes for organising and communicating complex information which involve top-down design, implementation and testing stages. She also claims that six programming issues of computer programming are clearly reflected in technical writing. These are: modularity, modifiability, user interface, fail-safe programming, style and debugging [Kau88]. Moreover, both activities involve modularity through top-down design, in programming these are classes, objects and functions, while in writing these can be chapters, sections, subsections etc. Then through modifiability these can be edited or implemented in any order, hence making the entire development process robust and easily manageable. With respect to debugging, in computer programming this involves recognising even the smallest syntactical, typographical or logical errors. Again, this applies to technical writing as well, since continuous flow of information and well organised coherent structure are essential to express the writer’s ideas. Kaufmann goes as far as to create an analogy which compares the process of understanding written technical documents to the execution of computer programs. Documents just like programs pass instructions and data to the reader (computer) whose actions are later shaped by what they have acquired, stored from it [Kau88]. With that said,


50

it becomes clear why writing a report was chosen as an example of managing a software project. Firstly, it can be divided into separate components and then individually implemented and modified. Secondly, the project will involve two people; the author who is a developer and his supervisor who will act as a client and tester.

4.2.2

Project Alpha - Stage 1, Initial Setup

Kanban Board As can be seen in figure 4.1 the Kanban board was divided into six sections. As described in chapter 2, the entire cycle will involve a feature moving from the ‘‘Backlog” section of the board to the ‘‘Done” section. The ‘‘Background reading” section corresponds to the ‘‘Design” section of most Kanban-oriented projects which is used for planning and background research related to the implementation stage of an item. However, in this case the background reading is related to acquisition of information and collection of references related to a particular section. The section was divided into two sections and its WIP limit set to 2 items.

Figure 4.1: Project Alpha - Stage 1, Kanban board version 1 The ‘‘In progress” section was divided into two sections and its limit set to 3. In theory, this configuration will allow for two features to be ready to be sent to the reviewer as soon as the previous features were sent back to the developer and the space for the new ones has been created. It will also allow for the smooth transition of features from the ‘‘In progress” section into ‘‘Supervisor’s review” and for the simultaneous development of another feature. One the other hand one should be aware that the creation of two many so called ‘‘buffer zones” should be avoided as it might result in waste and inefficient, interrupted flow. The right


51

balance should be achieved by experimentation and collection of empirical data and is different for each project size and its nature, team and project’s nature. The reason for doing so is the unpredictability of the supervisor’s feedback time. Realistically speaking a supervisor or client in a real world application might be busy with his or her other responsibilities and tasks. In author’s opinion the effect of this type of scenario should be minimised at all cost by creating appropriate buffer areas right before the feedback dependant stage. The ‘‘Supervisor’s review” section WIP limit was set to 2, allowing another small ‘‘buffer zone” to be created before the amendments section. The amendments section was set to 1 and was not divided since the last section is ‘‘Done” which has no limits set. With that said the cycle time is estimated to take no more than 3 days, which means that in this period 2 sections are predicted to be produced, checked and amended in a given week.

4.2.3

Empirical Data

Figure A.1 shows a Kanban board version 1 of the project on its first day on 1 April 2011. There are 3 chapters divided into 8 MMFs with a set of additional features for preparing the bibliography, abstract, formatting, appendices and table of contents. Almost all the features need to go through the ‘‘Background reading” section of the board. However, the author was aware of the necessity to remove this section of the board after finishing the features requiring the literature survey. For instance, for sections related to the practical side of the project such as ‘‘implementation”, ‘‘testing” and ‘‘evaluation” there is little or no background reading necessary. Before the process of writing was started the author needed to to do background reading around the Kanban related literature. The reason for that was acquisition of the relevant information to the project. The process took almost two weeks after which the information from different sources was consolidated into a series of notes and drafts. Immediately after the work was started the first two features with the highest priority were pulled onto the subsequent section called ‘‘background reading” (figure 4.2). After this step the author was able to stay fully focused on the task of skimming through the book by Taiichi Ohno [Ohn88] and prioritising the content to be written about. The other feature which took three days to be completed was researching about the software project management in software industry. In


52

Figure 4.2: Project Alpha - Stage 1, State 2 from 12.04.2011 the author’s opinion setting the WIP limits to 2 proved to be a good decision. It allowed him to have greater flexibility and versatility in researching specific information. For instance, when all the information was gathered about one subject area, he could easily start researching information on a different subject. After approximately three days the author started writing about the information gathered in the previous step. As can be seen in figure 4.3 the first two features were pulled by the ”In progress” column. Because its WIP limit is set to 3 it was still able to pull another feature, either for its development or waiting to be pulled to ‘‘Feedback” section. Chapter 1 of the background report was relatively short which resulted in its relatively quick completion. Then, features 2.2 and 2.1 were pulled from the ‘‘done” stage of the ‘‘In progress” column onto the ‘‘Feedback” section in which they were being proofread by the supervisor. This resulted in the WIP limit of the ‘‘feedback” column being reached, which in turn meant that in the mean time the author had to fully focus


53

Figure 4.3: Project Alpha - Stage 1, State 3 from 15.04.2011 his resources on other stages and activities that were present in the system. For instance, the background reading and development of the remaining features. The next state of the project is an example the bottleneck present in the ‘‘feedback” column (see figure A.2). This blockage could have possibly resulted in disruptions of the project’s flow, which would have generated waste. Fortunately, the supervisor’s meeting was scheduled on the same day which finalised the development of these tasks and released them into the last column. This was very important as there was feature 2.3 waiting in the queue to be pulled for proofreading and acceptance. This state also shows the system being fully utilised with all the stages being involved in the development of the project. In the next stage of this project, the relation of the project’s supervisor as a client or an inseparable member of team involved in the development will be evaluated. This will prompt some changes in the project’s Kanban board. As was mentioned before, features 2.1 and 2.2 were proofread by the supervisor and after the author’s few amendments were accepted by the supervisor (see figure A.3). This meant that feature 2.3 which was waiting in the ‘‘done” column could finally be pulled onto the subsequent stage. As shown in figure A.3 there is also another feature 2.4 which was going to be pulled onto the next stage right after the next meeting because the author wanted to disperse the project’s resources.


54

Figure 4.4: Project Alpha - Stage 1, State 4 from 17.04.2011 This allowed him to work on his coursework developing the web application for project Beta and in the meantime to give his supervisor the opportunity to read a section 2.3 of his report. State A.4 shows chapter 2.3 completed and chapter 3.2 and bibliography with the rest of the additional features still staying in the ‘‘backlog” column. Furthermore, chapters 3.1 and 2.5 were still being worked on. Following the completion of chapter 2.3, chapter 2.4 was immediately pulled into the ‘‘Feedback” section and sent to the supervisor for approval. As can be seen in figure A.5 chapters 3.1 and 3.2 were still being written. Also, the phase’s WIP limit of 3 was not fully utilised, since the last feature had to be done after completing all other features. Chapter 2.5 was waiting in the ‘‘Feedback” phase for approval and 2.4 was successfully accepted by the supervisor. Figure A.6 shows chapters 3.1 and 3.2 still being developed. As can be seen from figure the cycle time and feedback loop of the last stories increased dramatically as the result of proper background reading and the approaching deadline for submission. Finally, in figure A.7 shows the ‘‘Done” column filled with completed features. This means that after the final acceptance by the prospective client or in this case


55

project’s supervisor the project can be considered as being successfully completed. The ‘‘bibliography, abstract and the additional features” story was the last one to be completed. The entire project took exactly one month to be finalised. In the subsequent section the full analysis of the empirical data gathered in the course of this and other experiments is provided. The chapter mainly analyses the cycle and lead time of the project. The analysis involves the use of cumulative flow diagrams and statistical data. Together with the exploration of waste which was present in each project and the author’s qualitative evaluation it will serve as a useful and comprehensive analysis of this personal Kanban system.

4.2.4

Project Evaluation

Before the next part of the experiment can be started it was important to perform a preliminary evaluation of the methodology which will inform the next stage of the process. The research framework that will be used was explained in section 3. Also it should be noted that the project developed using the methodology was delivered on time and met the expectations of its author and the intended audience who praised both its structure and timely implementation. Project’s Workflow Analysis The first thing which needs to be analysed is the cumulative flow diagram of this stage. As can be seen in figure 4.5 and Little’s Law the throughput was on average 0.5 stories per day. Taking into consideration the average length of a story which was around 5 pages, this results in 2 or 3 pages per day. The throughput was consistent throughout the process, however the lead time changed significantly from 14 to 7 days in the last stage of the experiment. This might be due to this fact the author decided to reduce the WIP limit of the ‘‘In progress” section in order to increase the Lead time and feedback loop between him and his supervisor. This was performed by removing the ‘‘background reading” section which had a WIP of two. Following that the overall WIP of the entire board has decreased by 2 which should result in shorter lead time. It should also be noted that the author selected two stages of the diagram which corresponded to the later section of the process and can be used as a good illustration of a change in trend in the process’ workflow.


56

Figure 4.5: Project Alpha - Stage 1 - Cumulative Flow Diagram Furthermore, the ‘‘feedback” and ”background reading” stages were consistent throughout the project. It can be seen that after the 19.04.2011 the ‘‘Background reading” column of the experiment stopped being used. From the diagram it can be concluded that the section stopped being useful after all the background reading was completed. Because of the next stage of the experiment and the process of writing it do not require much background reading this section was deemed to be redundant and removed from the next version of the board. Nine Aspects of Project Work The project’s supervisor did not express any need for documentation. However, the project background report itself can be thought as being a documentation of the project as such. With that said, the author decided to indicate it in table 4.1 as being as being supported by the system. With respect to problem solving it was also supported and incorporated into the project since problems

CHAPTER 4. SYSTEM TESTING Aspect of work Documentation Problem solving Visualization Understanding the whole Communication Embracing the method Feedback Approval process Selecting work assignments

57 Expected influences of Kanban Supported Supported Strongly supported Strongly supported Supported Supported Strongly supported Strongly supported Strongly supported

Table 4.1: Summary of NAOPW present in project Alpha - stage 1 with the writing process and its content were consulted right after they occurred. This aspect of work can be therefore thought as being supported by the system. The visualisation aspect of work was also strongly supported by the system as it allowed the author to track the progress of his writing process and pick the stories from the ‘‘backlog” depending on their priority. This seems to be consistent with the findings of [IPF+ 11] who also claims that this feature of Kanban provides its users with the greatest amount of information. However the information that was missing from the process was the inclusion of different colours corresponding to different sections of the final project. Understanding the whole was implemented by the tools suggested by [IPF+ 11]. It was utilised by reviewing a wide array of reports which helped the author to generate and evaluate new ideas for the project. Communication was proved to be very flexible. The visual nature of Kanban supported by the weekly meetings with the project’s recipient supported communication which was always relevant and focused on the features that the author was currently working on. With respect to embracing the method, the author and its supervisor found the method very intuitive and simple to use, there was no need for extra explanation what a particular situation was indicative of in terms of its presence on the Kanban board. The feedback was constant, explicit and focused on a specific area of interest. Weekly meetings together with the discussion of the Kanban board supported the whole process making it seamless and straightforward. The approval process was also straightforward and there was nothing that would need to be changed in order to further simplify the process. The supervisor would approve a story as soon as it has been received and proofread. Finally, selecting work assignments was

CHAPTER 4. SYSTEM TESTING Type of waste Partially done work Extra processes Extra features Task switching Waiting Motion Defects

58 Observation somewhat observed Observed not observed somewhat observed observed not observed somewhat observed

Table 4.2: Summary of waste observed in project Alpha - stage 1 performed by prioritising the stories and choosing which one was more important for the project’s success. Normally, the most difficult or stories explaining a certain phenomena would be chosen first from the ‘‘backlog”. To conclude, most aspects of project work were supported in the project and after the initial analysis there did not seem to be too many aspects of the process which needed improvement. Waste Analysis The analysis of waste in the project showed there was no particular waste observed. Although, there were still a few issues that needed to be addressed. For instance, there was some partially done work which resulted from task switching. There were also some defects that needed to be fixed after they were consolidated into the final background report. This resulted in some waste concerned with solving the problem. Furthermore, the author sometimes would also wait for his supervisor’s response or a meeting which also caused some waste to occur. However, as was noticed by [IPF+ 11] Kanban does not offer explicit tools of improving this aspect of the process. Another waste that was observed especially in later stages of the project was associated with extra processes. The ‘‘background reading” column was not being used in later stages of the project which generated waste. Process Optimisation After the changes that were mentioned before have been applied to the board, version 2 could be seen in figure 4.6. In this version of the board the ‘‘Feedback” and ‘‘Amendments” section were referred to as ‘‘the last mile”. These two sections are indispensable for the approval process and are the final stages that a given story needs to go through in order to be marked as completed. As was mentioned before, after removing the ‘‘background reading” section from the board, the WIP


59

limit of the entire process decreased by 2, which was expected to result in shorter lead times. Moreover, the ‘‘feedback” section WIP was increased to 4, since the author was told that his supervisor was able to read more drafts and would not be overwhelmed by it. Usually when a story is completed it is placed in the ‘‘Done” column of the project, but since in this case the situation is different the decision was made to incorporate and keep the ‘‘feedback” column as an internal part of the entire process. This is an important aspect to be considered, namely, whether the supervisor was acting as a customer or as an internal member of a team. This was briefly discussed in section 4.2.1. From this project’s perspective the supervisor is acting both as a team member and customer. She is a customer because she is responsible for marking the project and it needs to match her expectations and standards. Furthermore, weekly consultations and feedback are consistent with the role of the customer in a process of project’s acceptance process. She acts also as a team member because she is checking the quality of the project and provides a useful feedback and advice on its functioning. Furthermore, the amount of information that the board contained was increased by the inclusion of colours corresponding to different sections of the board. The decision was also to add story points to each story, which corresponded to the estimated number of pages that the page would contain. This was conducted in order to further increase the amount of information provided by the system.

Figure 4.6: Project Alpha, Kanban board version 2


4.3

60

Project Alpha - Stage 2

The main purpose of this project was to test whether a continuation of a software development process which was started before and whose performance was evaluated with the methodology described before, showed an increase in its throughput. After the first part of the Alpha experiment, the second part consisted of writing the main body of text for this dissertation. Following that its execution will be evaluated and results generalised to the area of software engineering. It should be noted that in the context of real Agile/Lean software projects, developers start with a vague project plan which can then be further developed in parallel with changing circumstances. After all, this corresponds to one of the Lean principles which was mentioned before, namely ‘‘Decide as late as possible”. Provided with adequate knowledge about the project and its latest developments, developers are able to avoid producing unnecessary features and generating waste.

4.3.1

Empirical Data

The experiment commenced on the 7 July 2011 with 5 stories in its ‘‘backlog” which were ‘‘Implementation” divided into 2 parts, ‘‘First archival case study” and a section about ‘‘Minimum Marketable Features (MMFs)” (figure 4.7). Following the analysis of nine aspects of project work the author decided to include numbers which are estimates of number of pages that each story is to contain. In further stages there will also be colours added to different post-its representing various stages of the experiment. This will be done in order to increase the visibility of the Kanban board. During states B.1, B.2 and B.3 the system behaved as expected. At states number 5 and 8 extra stories were added to the system’s backlog (figure 4.8. As can be seen these stories have different colours which corresponded to different sections of the dissertation paper. After that ‘‘testing 1/3” story was immediately moved onto ‘in progress” section of the board together with ‘‘productivity tools 1/3”. As can be seen implementation and ‘‘first evaluation case study were in the ‘‘feedback” section of the board waiting for their approval. Figure 4.9 shows the ‘‘in progress” column being filled with stories that are waiting to be moved to the subsequent stage. It also shows that the ‘‘Feedback” section which is filled with stories that are waiting to be approved by the supervisor. These column was expected to become empty after the meeting with the supervisor


61

Figure 4.7: Project Alpha - Stage 2, State 1 from 10.07.2011 which was to take place in two days. After the meeting the flow was resumed and stories were able to start moving again across the board. As can be seen in figure B.6 the project was progressing steadily toward the end. The figure mentioned shows the ‘‘In progress” column which has reached its full WIP capacity. There were also two extra features waiting for approval in the ‘‘Feedback” section. Figure 4.10 shows that there is a correspondence of using the Kanban system for managing the process of writing dissertation and that of software development. In the ‘‘in progress” section of the board there is a ‘‘second archival study” story which is blocking the board. This was because of the inability of the author to find such a study, despite the initial plan to do so. The scarcity of such case studies in the research literature was also observed by [IPF+ 11] There are two possible reasons for this. The first one might be due to the fact that software projects of this type are not generally well documented because nobody did an analysis like this one before and it would serve no real purpose in the day to day business of a small software firm. The second possible reason could be because of the firm’s reluctance to publish such data which is considered to be their proprietary knowledge. It might be an attempt which is aimed at not sharing their internal practices with potential competitors. Because the author was unable to find this information, a decision was made to remove it from the board completely, which


62

Figure 4.8: Project Alpha - Stage 2, State 5 from 24.07.2011 as a result unblocked the process. Another change to the board was to add the section discussing the purpose of using cumulative flow diagrams and reasons behind using these for the project. Figure 4.11 shows the ‘‘backlog”, ‘‘amendments” and ‘‘done” columns being empty. This means that the system is working properly and its resources are fully utilised. Furthermore, there are no stories suspended between stages which is a good indicator of a consistent, uninterrupted flow. The next stage (4.12 shows one new story which was added to the board, the author decided to add the description of the ‘‘project Gamma” which was to be conducted by a group of students from the University of Manchester in developing their software project. However, the idea was finally abandoned by their project supervisor because of the methodology being deemed unsuitable for their purpose (see section 5.1). Also stories about Kanban productivity tools were moved onto the ‘‘backlog” section and the section about CFD was placed in the amendments section of the board. In this section the author decided to move the ‘‘first archival study” story from the ‘‘done” section of the board back to the ‘‘amends” section.


63

Figure 4.9: Project Alpha - Stage 2, State 8 from 08.08.2011 This practice is not prescribed. However, as noted by [Bro10a] in real life such a scenario is sometimes inevitable especially when there are certain developments in the project that need to be included into one of its features. In the case of the ‘‘first archival study” the author was provided with some new data from the author of the case study which needed to be added to the respective chapter. State B.7 of the board shows this section sent to the project supervisor. Obviously the section at this point was 80% complete as there were still 2 figures to be added to its contents. These were to include ‘‘Evaluation” and ‘‘Conclusion” sections of the dissertation which had to be written at the end of the implementation process. The author decided to send an almost completed version of the story and add the remaining 2 figures after the final two chapters have been completed. In author’s opinion this was the most appropriate course of action since almost all the data and evaluation of the projects was done and there was a need to finalise summarise the entire project. Figure B.8 shows that four features that were present in the previous state were directly pulled onto the ‘‘Done” section of the board. This happened because none of the stories required amendments. However, after the full project has been


64

Figure 4.10: Project Alpha - Stage 1, State 10 from 18.08.2011 submitted to the supervisor there were a few spelling mistakes which were not noticed before. This shows how waste can still be present in the project despite its short feedback and continuous communication and constant proofreading by the project’s supervisor and the author himself.

4.3.2

Project Evaluation

Project’s Workflow Analysis Figure 4.13 shows that there was an improvement in the system’s Lead time. This resulted from the greater motivation to finish the project which in turn resulted from the visual nature of Kanban supported by an increase in knowledge about the final shape of the document. As can be seen lead time on the 8 August was 16 days and decreased down to 10 days in 12 days. This resulted in change in throughput from approximately 0.4 story/day to 0.6 story/day which was a 33% increase in productivity. Therefore, it can be said that 2 pages/day were on average developed throughout the process. The diagram also shows a big increase in a number of stories in the ‘‘backlog section” of the board from 18 July to 28


65

Figure 4.11: Project Alpha - Stage 1, State 11 from 20.08.2011 July which resulted in an increase in a number of finished stories in the ‘‘done” section from 8 August. The increase can be clearly seen in figure 4.8 which was also described earlier. If we compare two diagrams next to each other we can see that the flow of the second stage especially of the‘‘In progress” and ‘‘feedback” sections of the board is equally if not more regular. This clearly shows that the improvements made to the earlier version of the board improved the process making it more efficient and unvarying. There are no major bottlenecks and the project was developed systematically and consistently. However, the ‘‘amendments” section looks discontinuous which means that this stage in the process was not constantly used. This sporadic use of the process’ stage might mean that this section is unnecessary in the future projects. Nine Aspects of Project Work In terms of nine aspects of project work, the subsequent analysis showed that the system has been improved after performing the initial analysis was conducted. Therefore, the NAPW analysis of project work for stage 2 of the Alpha project


66

Figure 4.12: Project Alpha - Stage 1, State 12 from 24.08.2011 project remains unchanged and identical to stage 1 4.1. The visualisation was improved after the need to see how different stories relate to each other was expressed by the supervisor. Also the structure of the board changed by removing the redundant columns which added little to the process. With practice the author managed to improve the ‘‘embrace the method” aspect as it became a more intuitive tool to use. Understanding the whole was also supported by creating a high level table of contents for the project after which each of the individuals stories was expanded with additional subchapters. The Feedback together with Approval process did not change either as every week the meeting would take place after which the feedback was provided. Selecting work assignments also remained unchanged and was supported by the system, the author would pick a ticket which in his and his supervisor’s opinion had the highest priority at a given time.


67

Figure 4.13: Project Alpha - Stage 2 - Cumulative Flow Diagram Waste Analysis The findings in this are remain consistent with those of [IKA10]. Even with respect to a project of such scale there are still certain types of waste that proved difficult to eliminate from the process 4.3. However, there are still a few improvements that were observed which were made after the analysis of the stage 1 of the project. For instance, partially done work was minimised which resulted in less task switching and greater efficiency, especially in the last part of the project where changing tasks cab result in loss of time and concentration. In terms of extra

Type of waste Partially done work Extra processes Extra features Task switching Waiting Motion Defects

Observation somewhat observed somewhat observed not observed somewhat observed somewhat observed not observed somewhat observed

Table 4.3: Summary of waste observed in project Alpha - stage 2


68

Figure 4.14: Comparison of two CFDs from stages 1 and 2 of project Alpha processes and extra features, these elements, there were some chapters which were not planned to be added at first. However, in this type of project where there is a lot of unpredictability and uncertainty involved, the choice to include the features that were not included in the plan was rational. These were not observed in stage 1 of project Alpha because of the smaller amount of uncertainty which was involved in its development. Moreover, the amendments section of the board seemed to be rarely used. It might have been because of the decrease in the story’s quality, or the section’s redundancy similar to that of the ‘‘background reading” section in stage 1 of the project. Waiting was a type of waste which was not possible to eliminate because of the supervisor’s feedback which was given back every 7 days. There were also a few defects which were not observed before in particular in the ‘‘testing” testing of the document and ‘‘productivity tools” which resulted from missing links by latex compiler. Also some of the images were too small to be legible in the printed version of the document. These minor defects needed to be corrected before the document was to be printed which also resulted in waste. It seems that there is nothing that can be further changed to improve the process and the Kanban board which was used for this stage of the process seems to be optimal. The only aspect of the process that might need reconsideration in the future is the ‘‘amendments” section which might prove to be completely redundant in the later application of the system’s board.


4.4

69

Project Beta

As mentioned before the main aim of this project was to develop an actual application using the method tested before on the writing process. The application in question is called PeopleTalk and is capable of creating a list of languages and people who speak a subset of the first list. The program facilitates the creation and management of these three lists. It stores those two lists in an external mySQL database. The data structure represented in by the UML diagram can be seen in figure 4.15. Here we can see three classes; the language class and person class are both aggregated as parts of PeopleAndLanguage class in a separate array. On the other hand in the database they can be represented as tables and language and person are no longer represented as objects but as references to their respective tables.

Figure 4.15: UML Data Structure Diagram For PeopleTalk application Figure 4.16 shows the main menu and the first window of the application. As can be seen the user can choose between three options; creating a list of languages, people or a mixture of both.


70

Figure 4.16: Project Beta, PeopleTalk, Main Window

4.4.1

Initial Setup

Separation of features When it comes to the size of each feature, the most appropriate approach seems to be to divide the project according to its respective stages and so called ‘‘managers” which are responsible for the management of each lists. Each of these features will be approximately of the same size. Moreover, following the suggestion of [Chr10] in section 2.6 if one was to imagine a hypothetical email to a potential customer outlining what features the program has, he or she would most probably be inclined to include the features in question without subdividing them even further. Therefore, the project was divided into three stages main and two additional features of the program which were suggested in the program specification, these are: • • • • •

stage1: the language manager stage2: the people manager stage3: the language/people manager feature: display the people who can communicate directly feature: display people who can communicate via one interpreter


71

Kanban board With respect to the configuration of the Kanban board the author decided to split the board into six phases as shown in figure 4.17. The ‘‘Backlog”, ‘‘Design” which WIP limit was set to 1 because it seems natural to design and test one item at the time by a single developer. With respect to the ‘‘In progress” section, the author decided to set its WIP limit to 2 in order to provide himself with more flexibility in the development phase. For instance, there is a relatively large amount of manual code typing in each of the stages. Therefore, should the author experience some difficulty with one of the stages, he can then resort to utilising some additional sources of help by, for instance contacting one of his classmates who have more experience in the subject. While waiting for their reply or performing some other tasks he would then have the chance to develop the other feature which will allow him to use the time efficiently while waiting for the assistance from the external source.

Figure 4.17: Project Beta - Initial Setup Figure 4.17 was created using one of the tool called AgileZen [Cor10]. This tool will be reviewed and tested in subsequent chapters that discuss productivity tools related to Lean software project management. The reason for choosing an internet-based Kanban tool is mainly for testing purposes. This tool seems also to be amongst the most popular tools available on the internet for managing Lean-oriented projects.


4.4.2

72

Empirical Data

The PeopleTalk application started being developed on 23 July 2011. As mentioned before the project was divided into three main stories which were spread across 10 classes. The classes and other low level components were not added into the Kanban board since they consisted on average of 200 lines code. Due to this fact they were considered too small and peripheral for the purpose. They were mainly employed in creating objects, connecting the application to the database, executing queries and other critical functions. The scope of this application was also consistent with the scope of this project as the entire application did not exceed 5000 lines of code and took one person (the author) approximately 150 working hours to complete.

Figure 4.18: Project Beta, State 2 from 26.07.2011 For managing the development of this project the author decided to the use the productivity tool called AgileZen [Cor10] which is reviewed in detain in section 6. Also, as mentioned before only the most important states of the Kanban board were chosen to be included in this section. The rest of them can be found in Appendix C. As can be seen in figure 4.18 the WIP limits of ‘‘Design” and ‘‘Testing” columns were set to 1 which allowed the author to focus his resources on either testing or designing in one of those columns. With regard to ‘‘In progress” section its WIP limits were set to 2 which as will be explained later proved to be particularly useful when a bottleneck was encountered. The figure also shows that there are two features waiting in the backlog to be pulled into the subsequent section while three of the most important sections are being either developed or tested.


73

Figure 4.19: Project B, State 3 from 28.07.2011 Three days later ‘‘Stage 2” was successfully completed and pulled into the ‘‘Complete” column. However, the bottleneck has occurred in ‘‘In progress” section of the board caused by the ‘‘Stage 2 - People Manager” feature. The two problems were concerned with connecting the application to the mySQL database and using dropdown menus. The problem was due to his inexperience with the JSF framework and the lack of sufficient domain knowledge. However, there are at least two sources of help available for the freelance developer. The first one is to find the information himself from the relevant literature. The second options is to acquire help from various newsgroups or boards from the internet. The author chose to consult one of his colleagues on the issue of dropdown menu implementation and acquire more help from the relevant literature about the other issue of database connectivity. Because of the WIP limit of ‘‘In progress” column set to 2 the author was able to keep working on ‘‘Stage 3” while waiting for the answer from one of his classmates and trying to solve the problem himself.

Figure 4.20: Project Beta, State 4 from 01.08.2011 As can be seen in figure 4.20 the bottleneck was finally eliminated and the story was marked green, which indicated its readiness to be pulled to the next section of the board. The answer to the database connectivity problem was more problematic as it involved reviewing and retesting the class in order to discover


74

the error. There were two errors present, one of them concerned with the incorrect SQL query and the other one with regard to the configuration of the database itself. The second problem concerning the dropdown menu and connecting it with the database was indirectly affected by the first problem. Because the database was not functioning correctly it was impossible to query it correctly which as a result affected the configuration of the array used by the JSF framework. After the process was eliminated it was possible to continue the development process. This example clearly illustrates how the process of learning can be accelerated by the Kanban method by focusing on one problem at a time, acquiring new domain knowledge from outside of the system and by using errors in the learning process.

4.4.3

Project Evaluation

Project’s Workflow Analysis The project was successfully implemented using the Kanban board although there are still a few enhancements and conclusions to be reported. For instance, as can be seen in figure 4.21 in the first phase of the project each column was holding its features for relatively the same amount of time. This consistency of workflow is very desirable in any Kanban board because it indicates a healthy dispersion of tasks across the board. However some of the features were in the ‘‘In progress” column for a prolonged period of time due to the learning process and problems that occurred during their development. Also the last two features which were relatively short should probably be grouped together in order to maintain the features’ size consistency. We can observe in figure 4.21 that the testing column is relatively discontinuous and short. The author suggests abandoning it altogether since all the small features of the program were tested simultaneously with their development. Also in many personal Kanbans, there is rarely a testing section present [Tho11]. Moreover, since there was no formal testing conducted as such, but only functional testing on a very small scale, such a column could be considered to be redundant. Also with improved learning and experience fewer errors that were present in the project. Nine Aspects of Project Work The documentation was minimal, this section and description of the project in the implementation part of this paper can be considered as documentation. As


75

Figure 4.21: Project Beta - Cumulative flow diagram mentioned before problem solving was yet again supported with by the system. Focusing on a specific task and on errors which occurred early in the process allowed the author to to find immediate solution to the problems encountered in the development. AgileZen strongly supported the visualisation aspect of the project. In this aspect there seemed to be nothing to be improved as AgileZen indicated which stories were currently worked on, where there was a violation of WIP limits and which stories were ready to be pulled to the subsequent section or blocked. Understanding the whole was somewhat facilitated by the excellent project specification document and drawing diagrams of how the project would look like. Communication between the author, his supervisor and other people helping with the project development was also supported by the system. In the case of Embracing the method, the system proved to be intuitive and easy to use. The method was fully understood and its mechanics were used accordingly. Feedback was not observed to take place between the author and his supervisor. This is because the project was evaluated by a different lecturer and was to small for incremental evaluation. Although, in theory the system supports this aspect of project work, its implementation proved to be impossible due to the very small granularity of the project’s individual components. The interdependency of each of the other remaining features was an important factor in not submitting them separately, because preparing them as customer demos would result in generating waste of ‘‘extra processes”. Therefore, the approval process was influenced by it as the project was to be submitted to the person responsible for marking it


Aspect of work Documentation Problem solving Visualization Understanding the whole Communication Embracing the method Feedback Approval process Selecting work assignments

76

Expected influences of Kanban Supported Supported Supported Somewhat supported Supported Supported Somewhat supported Somewhat supported Supported

Table 4.4: Summary of NAOPW present in project Beta in its full form. This was also because of its size which in most projects its full form would correspond to most project’s single element. The approval process was straightforward and intuitive. The application met its functional and nonfunctional requirements which were outlined in its specification. However, it was partly supported because it was impractical to approve each of its individual stages separately. Selecting work assignments was also straightforward since the project needed to be developed in a particular order with its language manager, people manager and then the manager combining them together with extra features at the end. Waste Analysis With regard to waste analysis the findings are consistent with the findings of [IKA10] which claims that Kanban does not entirely prevent elimination of waste. The author observed that even in the project of such small scale the waste was observed. Below there is a formal analysis of the seven types of waste that were present in the project as suggested by [PP03]. Partially done work This kind of waste was not observed since the project was of such a small scale and its specification was clear. Extra processes There were no extra processes and no non-value-adding activities observed. Extra features Not observed.

CHAPTER 4. SYSTEM TESTING Type of waste Partially done work Extra processes Extra features Task switching Waiting Motion Defects

77 Observation Not observed Not observed Not observed Somewhat observed Observed Somewhat observed Observed

Table 4.5: Summary of waste observed in project Beta Task switching The tasks switching which resulted when Stage 2 of the project was blocked, the author started working on a different task. Also there sometimes was a task switching connected to working on another feature or testing it when the other was still unfinished. Waiting Waiting for technical assistance associated with the remoteness. Motion Lack of immediate access to other developers creates the need to compose messages and use other forms of communication which are sometimes less effective than face to face communication. Defects A minor defect was discovered after the first stage was completed, which would have taken less time if it had been discovered in the beginning. As can be seen the project’s waste analysis did not show any major waste present in a personal Kanban. This is because of the nature of the project and its size and by the fact that there was no client associated with the project which would change the requirements frequently. There was also no development team assigned to the project, and this factor usually contributes to the accumulation of other types of waste [IKA10] i.e. partially done work, extra processes, waiting, motion. The specification was prepared in a very clear and coherent manner witch prevented most of the waste from occurring. Possible Process’ Improvements As mentioned before because of the project’s size and low complexity there are not many improvements that could be made to improve its functionality. The waste analysis shows that ‘‘task switching” should be avoided and the developer needs to focus on one task at a time. However, task switching might prove useful,


78

especially when there is a blocker and the developer needs to switch to a different task while waiting for reply or doing some additional research into its cause. However, with respect to ‘‘motion” there is not much that could be done in order to eliminate it completely, since immediate access to other developers might be problematic in the case of a one person Kanban. What could be suggested is the allocation of shared space where individual developers would have access to each other and could therefore help each other where needed. What could be improved based on the CFD is the removal of the ‘‘testing” phase from the process. Its existence in the context of such small project was redundant since each module was tested at the same time as it was being developed. Also, there was no need for any test cases or other more sophisticated testing mechanisms. The CFD also showed that merging certain features together into one story could improve the process’ flow by facilitating the consistency of the stories’ size. Chapter Summary This chapter outlined the practical implementation and preliminary evaluation of the project’s methodology. It was concerned with using Kanban for three projects in the context of which the Kanban method was practically used, evaluated and progressively improved. After all the projects finished the author evaluated and analysed each of them using three different methodologies. These were: waste analysis, nine aspects of project work and analysis of projects’ cumulative flow diagrams. After that the suggestions for improvements were made and the process modified accordingly. The evaluation chapter will analyse the usefulness of this approach and the Kanban’s suitability in the context of similar type of projects.

Chapter 5 Other Case Studies After the practical implementation of the project’s methodology conducted by the author himself, the experimental data needs to be complemented with other case studies. This data will be used to perform a comparative analysis of the Kanban system used in the context of different software projects. These will be studies of a size which is relevant to this experiment’s scope conducted by other developers. As was mentioned before the relevant data is difficult to obtain because of the experiment’s scope and other companies’ reluctance to share their internal operational data. However, there are still a couple of studies from the University of Manchester that are of right size and complexity for the purpose of this analysis.

5.1

Project Gamma

The main objective of the project which is referred to by the author as project ‘‘Gamma” was to develop the project called Personal Learning Environment (PLE). The main participants in the experiment were MSc students from the School of Computer Science at the University of Manchester. There were in total seven students participating in the project and their programming experience was on average two years. All the students were also familiar with the Agile software process model and some of them had some industrial experience.

79

CHAPTER 5. OTHER CASE STUDIES

5.1.1

80

Explanatory Interview

Despite the initial decision to use Kanban for the project, its supervisor who shall be referred as ‘‘Project Gamma’s Supervisor (PGS)” finally did not choose to use it. Below the reader will find an excerpt from the interview which took place on 04 July 2011 explaining the reasons for not implementing the methodology. The questions are abbreviated as Q1 for Question no. 1, Q2 for Question no. 2 etc. Q1: Why did you choose not to use Kanban for your project? ‘‘We chose to use Scrum because the team was familiar with it and there were too many variables involved in moving to Kanban. Specifically I did not want the team working with the new technology at the same time trying a new methodology” Q2: Was the size of the project in any way involved in the decision? ‘‘If you vary three things in a given project out of base technology, methodology and application area then you are going to run into problems and I did not want to vary too many things” Q3: Would you still consider using Kanban for any of your future projects? ‘‘Sure, I prefer the idea of Kanban because it allows more fine-grained product manager control. I like Scrum projects which have very short sprint1 lengths, which is the kind of job that I do. This means that you need to see things and give feedback on it quite quickly, so Kanban has got the advantage that you do not even have the sprint that you have to worry about, you can pull stuff into the pipeline and choose very dynamically what you want to do” Q4: You have shown me the ‘‘in progress” column (figure 5.1) which your team is using in addition to the methodology that you are using. Why did you decide to make use of this part of the of the Methodology? ‘‘The main reason was because we are doing a half-Scrum, half-Kanban arrangement where in this particular arrangement we are pulling stuff in when we finish with the items in the sprint backlog.” 1

A term for an iteration in the Scrum methodology which tends to last from one week to one month.


81

Figure 5.1: Team’s partial implementation of the Kanban system Q5: Why did you decide to put constraints on the column? ‘‘About putting constraints, it’s not for the reason I have just outlined. Putting a constraint there is to force team members to swarm2 onto tasks, because we had some problems with certain user stories which lasted a lot longer than we expected.” Q6: Does it mean that you want to encourage collaboration? ‘‘We just do not want a programming pair to get too hung up on a user story which takes a long time because it tends to be a depressing experience. User stories which make it into sprints are generally 1, 2 or 3 story points, so if something takes longer than 2 days we know 2

A term from agile software development describing an action of gathering a number of people in an attempt to solve a problem through collaborative work.


82

that we misestimated it and it was depressing. Therefore, it is better to get the whole team to swarm onto the user story and get it out of the way as fast as possible in terms of a lapse time obviously we put as much actual programming time into it.” Q7: How long does it take you to do an average story? ‘‘We expect all our user stories to be finished in less than 2 days. We expect them to be finished in 14 hours of pair programming time which is 48 hours real programming time.” Q8: Is this the first iteration you did with Kanban? ‘‘Yes it is the first one. As I said before it is a combination of Scrum and Kanban and despite my first decision to use Kanban I decided to keep things constant because of the project’s complexity and size.”

5.1.2

Discussion

With respect to [Q1] which addressed the complexity and unpredictability of the project, it should be noted that as was mentioned earlier because of the Kanban’s flexibility it is particularly suitable for dynamic high risk projects where there is a large number of variables. However, it might take take some time for a given team to get accustomed and efficient at using Kanban [Kni10]. The team had a lot of practice with Scrum before the start of the project and had none with Kanban. The team tried to combine Scrum and Kanban in order to incorporate it into their project. Probably without even realising it the team managed to implement a fully working Kanban board. It was a very simple one with constraints set to one of the columns the ‘‘backlog” column to the left and ‘‘done” column to the right (figure 5.1). As can be seen the main reason for its implementation was to lower the level of abstraction of the big project, thus, it can be classified as a project in its own right. By doing so it allowed the team to concentrate on a given feature which before would have been impossible or very difficult to develop. This enabled cooperation and facilitated team cooperation and learning [Q5]. This example proves that Scrum is not as flexible as Kanban for a process with a lot of uncertainty and change.


83

With that said, the method can be considered to be partially tested after which PGS said that the methodology is particularly useful for ‘‘fine-grained product manager control” (Q3). Furthermore, the interviewee expressed his interest in using the methodology in the future because of its suitability for very short sprint lengths where there is a quick feedback loop. This aspect together with its dynamic nature is according to PGS a big advantage of Kanban [Q3]. The degree of abstraction to which the Kanban system can be used is a recurring theme of this experiment. Yet again, this experiment showed how dividing a larger project into smaller constituents can be used in order to encourage greater cooperation and problem solving.


5.2

84

Project Delta

This case study was conducted by a former student from the University of Manchester who thanks to the author’s supervisor was willing to provide his findings regarding the use of the Kanban system in managing his project. The student was conducting his industrial placement together with his supervisor who suggested using the method and was closely involved in its development. The project was conducted in cooperation with Integrated Geochemical Interpretation Ltd (IGI Ltd) which is a petroleum geochemical consultancy company operating worldwide. IGI provides services for the gas and petroleum industry in the areas of exploration and production. Its main product is called p:IGI which is an interpretational software oriented on geochemical databases. The software integrates and analyses the databases, establishing prospects in terms of the amount timing and composition of the hydrocarbon charge [Ltd10]. The program’s main interface can be seen in figure 5.2.

Figure 5.2: Project Delta - Interface The people involved in the project’s development were an undergraduate computer science student from the University of Manchester together with his supervisor. They were responsible for developing two components whose function was drawing graphs and maps. The Grapher and Mapper components both use the Renderer part of the program in order to interact with one another. An example of a graph prototype can be seen in figure 5.3. These two components were a part of a larger program developed by the parent company. As a result, the group project project was a subset of the parent program which was in turn further subdivided into smaller constituents. Kanban was suggested by the student’s project supervisor as an innovative way of managing their project. The team of two people was self-organised and needed some visual way of controlling and managing the project. The system was expected to provide regular feedback on the


85

project’s progress and its prospective problems. Furthermore, it was supposed to be easy in use and implementation. To the author’s best knowledge this criterion could have not been satisfied by the Scrum methodology because of its complexity and formal nature and the need to plan iterations prior to development. Kanban allows for even greater flexibility for architectural changes [Kni10] which together with its simplistic nature made it suitable for the project.

Figure 5.3: Project Delta - Graph Prototype

5.2.1

Implementation

As can be seen in figure 5.4 the Kanban board was split into three main sections including ‘‘Design”, ‘‘Implement” and ‘‘Review”. The top part of the board with orange notes was used by the student and the bottom half by his supervisor. They also decided to implement so called ‘‘queue lanes”. Their purpose was to create what was previously referred to as ‘‘buffer zone” which would hold completed tasks before moving them onto the next phase of the process. This solution seem to be very common amongst Kanban practitioners as they allow them to communicate which items are ready to be pulled by the subsequent section. There were also different colours of post-its used by the supervisor that were used to communicate each of the components he was working on. The board was reviewed daily, in the form of stand-up meetings which lasted approximately 5 minutes. Some of the features’ complexity was so high that it needed to be further subdivided into smaller tasks. Wanting to accurately predict how long each item should stay on the board, the team used a velocity measurement: each tasks was assigned its estimated velocity which is the time a task should remain on the board before completion. Then each person was assigned a target velocity which he aimed to


86

meet at the end of each period. This was used as a measurement of a person’s performance since the team did not measure cycle time and the features were of different sizes.

Figure 5.4: Project Delta - Kanban board used in the project

5.2.2

User’s Evaluation

The student involved in the project expressed his satisfaction using the system. He said that it was particularly useful for managing time and task in projects of scale similar to the one he was working on. He then added that it can be used both on big and small projects depending upon project’s level of abstraction.


87

According to the user it provided the team with a feeling of achievement and motivation to finish each task in time. The transparency that resulted provided the team with the better understanding of the issues that occurred in the process of developing the system which in turn allowed for more effective cooperation. It was also an effective way for the customer to track the project’s progress. This was again due to the visual nature of Kanban which let everybody immediately check the board and quickly assess the project’s progress. Nevertheless, there are a couple of aspects that in the student’s opinion could be improved, for instance, the issue which was mentioned before concerning the standard-sized features. As the Kanban board encourages progress by moving forward between phases it is particularly important to split them evenly. This aspect is consistent with the author’s findings which can be found in the section 2.6 discussing minimum marketable features. Some of the stories that the team was developing were improperly divided resulting in overerestimation of the development time required. This resulted in some of the features staying on the board for longer than the average cycle time. In the student’s opinion it would have been more effective to split the stories even further by increasing the level of the project’s abstraction. This also illustrates what the author mentioned before which is the significance behind the proper estimation of time and effort needed for development of project’s components. As mentioned before this problem was tackled using velocity measurement, which aimed at making the performance of team members consistent with each other. Adopting the concept from the Agile school of software development seems to have been a good solution for estimating the target average throughput of the system.

Chapter 6 Kanban Productivity Tools There is a wide range of Kanban oriented productivity tools available on the internet. The author selected three of the most popular ones which are listed in [Raj]. These are: Kanbanery [Pol], AgileZen [Cor10] and Kanban Pad [Gro]. In this chapter each of these tools will be reviewed and compared against its competitors. Their review and description should help the reader to choose the most suitable candidate for managing the development his or her small software project.

6.1

AgileZen

AgileZen is a tool initially developed by Nate and Niki Kohari and later acquired by Rally Software [Sof02]. According to its authors AgileZen is a ‘‘simple, flexible, and cost-effective way to manage work. With an easy-to-use web interface it helps to stay organised, focused and on target” [Cor10]. Unfortunately, the free of charge version of the application does not support multiple projects, collaborators, file storage, IM notifications or SSL encryption. The free version is limited to one project and and no collaborators. However, as the results will show its core functionality can be fully tested and evaluated using the free plan. When a user first opens an account he or she can create a board with a specific project template or choose from the list of existing ones. This window offers also an option to change the pricing plan, create a new project or delete an existing one. It also provides information about the collaborators and attachments associated with the project. As can be seen in figure 6.1 after the project has been created the user can modify the Kanban board in the process section of the application. 88

CHAPTER 6. KANBAN PRODUCTIVITY TOOLS

89

It can be accomplished by adding a phase or deleting existing ones. It is also possible to modify the WIP limits of each of the existing phases. The user can add as many phases as he or she wants. In addition to that it is possible to provide each of them with a suitable description about its purpose in the workflow.

Figure 6.1: AgileZen - Process Overview Window [Cor10] After the board has been created stories can be easily created and added to the board by clicking a drop-down menu called ‘‘Add stories”. After this the user is asked to write the story’s title after which he can add its estimated size, priority, deadline, colour and corresponding tags. When the story is on the board it can be sent to the bottom of the column which would indicate its low priority or to the top it. It can be marked as ready to pull for a person responsible for moving the stories on the board. There is also an option to add additional information in the form of attachments i.e. spreadsheets, documents, images and comments which are meant to help other team members of the team to develop the story. Each story can be later modified by adding attachments, changing its colour, removing or renaming it and performing other actions. As was mentioned before attachments can be added or removed. Figure 6.2 shows the ‘‘Board” section of the application which displays the full Kanban board with stories, phases and other useful visual information. As can be seen each story has a tag, colour and a person who created it. There is also information for other members of a team which tells them whether a story is ‘‘blocked”


90

Figure 6.2: AgileZen - Board Section [Cor10] indicated by a red outline and usually a corresponding comment, or ‘‘ready to pull” shown by a green outline. The WIP limits for each phase are displayed in parantheses and if the limit is reached its indicated by changing the change in headline’s colour to red as shown by the figure mentioned. Furthermore, when the limit is exceeded the column’s background colour changes to red indicating that the explicit process rules have been violated. Thanks to these features the board provides a large amount of visual information to its users enabling their better cooperation. One of the most useful features of AgileZen is its performance section which was used for the analysis and improvement of both projects Alpha and Beta in sections 4.2 and 4.4. The optimisation process was conducted using a cumulative flow diagram which an example of can be seen in figure 4.21 in section 4.4 and is described in detail in chapter 3.2.1.

6.2

Kanbanery

Another tool available for the Kanban developers is called Kanbanery developed by the Polish developer Lunar Polska [Pol]. Its functionality is almost identical to that of AgileZen but there are a few differences in its interface which will be explained in later sections. When the user first registers with the application he or she is invited to create a new workspace. This will allow us to access our board


91

through the separate domain which will be generated as a link with the workspace name included that the user has chosen for it. The workspace can later be filled with multiple ‘‘project boards”. It is one of the differences between these two applicatons since AgileZen only supports multiple Kanban boards and does not contain workspaces. This board in author’s opinion has a very intuitive interface which provides its users with useful hints and advice on various types of projects and how Kanbanery can be used to support their development. Depending on which option the user chooses, the system will generates a particular type of Kanban board.

Figure 6.3: Kanbanery - Simple Software Project’s Board [Pol] For instance, if one chooses the basic option the program will generate the simple board with ‘‘To do”, ‘‘Doing” and ‘‘Done” columns. On the other hand, after choosing ‘‘simple software project” board the program will generate a board of this type (see figure 6.3) with ‘‘Coding”, ‘‘Testing” and ‘‘Approval” columns which are inherently used by software developers.

Figure 6.4: Kanbanery - Program’s Interface [Pol] Figure 6.4 shows the program’s interface which supports attachments that can be added to each task. It also allows its users to create subtasks which might be useful in subdividing a given task. Furthermore, Individual stories can be


92

accessed from the outside via a separate URL link that is generated for each task separately. This will allow for quick access to a feature of interest from outside of the system. The tool also provides a support similar to AgileZen for creating flowchart diagrams. There is also a ‘‘ready-to-pull” option identical to that of AgileZen available to indicate that a feature is ready to be moved onto the next phase.

6.3

KanbanPad

With its very simple interface this tool is the simplest of all three tools. It is being developed by the group of developers called thehybridgroup [Gro]. Their main business idea behind the tool was to create ‘‘The happiest project management tool on Earth!” which users can start to use in less than 10 seconds. The only action that needs to be done before the tool can be used is the registration process. When the first page is loaded the users is asked to insert his or her email address and confirm the registration. Then the list of projects and organisations is displayed and the user is invited to either select one from the list or create a new one.

Figure 6.5: KanbanPad - Interface [Gro] After the project has been created the user can freely modify the Kanban board, add new tasks and interact with the board. There is a subtle difference between this tool and the others. Following the creation of a new story the user has to click a small ‘‘play” symbol after which the story is moved into the ‘‘In-progress” section of a given column. As can be seen in figure 6.5 this section


Feature AgileZen Number of projects supported 1 by a free version Number of collaborators sup0 ported by a free version File storage in a free version No Flowchart diagram Yes Email notification Yes List of changes (history) Yes

93

Kanbanery 1

KanbanPad Unlimited

2

Unlimited

1GB Yes Yes Yes

No No Yes No

Table 6.1: Features available in different Kanban productivity tools is placed at the bottom of each column. Also stories can be assigned to different users and notes can included. Stories can also be marked as urgent, however there is no option of adding their size or deadline.

6.4

Discussion and Recommendations

The most appropriate tool for a particular software project should be chosen with several considerations in mind. These involve the number of participants, project’s size, tool’s features required and available budget. There is no simple answer to this question since all the features tested are very similar to each other and offer comparable functionality. However, there are a few recommendations for their prospective users which the author based on his experience can offer. As was demonstrated in section 4.4 AgileZen was successfully used for managing project Beta which was a part of the dissertation phase of this project. Its simple and intuitive interface make it particularly user-friendly and easy to learn. It has a set of collaborative tools which make it suitable for teams of two or more developers. However, the author would strongly recommend the use of KanbanPad for early practitioners of Kanban. KanbanPad is available for its users completely free of charge. Therefore with the support of multiple projects, and if necessary multiple users it should be seriously considered by start-up firms and development teams who are not in possession of large starting capital. There is also no need for complicated configuration of the system. The user can simply register, create a project board, use it and modify it at any time. The developer can save time and avoid generating waste by using this simple, yet powerful tool. However, the KanbanPad does not


94

support dynamic cumulative flow diagrams, which can make it more difficult to assess the project’s progress and optimise flow. This lack of advanced analytical tools can prove to be problematic for some advanced users or projects that might require such analysis. As was mentioned before Kanbanery happens to be an almost identical tool to AgileZen. It is particularly useful for projects with multiple team members who need to rapidly and effectively exchange visual and textual information about their project’s progress. In author’s opinion the application’s interface is the most visually appealing supporting its usability and learnability. Kanbanery is generally considered to be advantageous in projects developed by two people (table 6.1) because of its support for two collaborators similar to the case study mentioned in section 5.2. In its free version it also provides its users with 1GB free storage space for various attachments associated with the project. KanbanPad is considered the simplest tool of the three seems to be suitable to use by a single developer as well as a group of more than two people with limited budget. Each of these programs can be successfully used by small software teams. Also in author’s opinion the application can be a real alternative to a traditional physical board especially for teams who find themselves unable to conduct regular stand-up meetings. Chapter Summary In this chapter was concerned with the testing of three Kanban oriented productivity tools. These were later evaluated and compared against each other. As was shown each of these has its own advantages and disadvantages as compared to its competitors. On the basis of their suitability in different contexts the author made recommendations as to which one is the most suitable for a particular software project. These recommendations were based on the number of people involved in the product development, its size and the features provided by the tool for its successful execution.

Chapter 7 Project Evaluation Following the implementation and testing section of the dissertation it is time for a chapter devoted to a critical analysis of the research problem of this project. The author described and tested the methodology using the incremental improvement process known as Kaizen on three different projects. There was also another project which yielded a negative result and another archival case study which was reviewed based on the experience of its author. Therefore, this chapter will discuss the advantages and disadvantages of the methodology tested with respect to its application to small software projects.

7.1

Suitability for Small Software Projects

The existence of many Kanban productivity tools and consulting agencies who sell their solutions on the internet makes most of the information that is available about Kanban biased and unscientific. The advertising and marketing side of promoting Kanban as a tool of choice for many companies needs to be separated from its actual use by real developers who use it as a tool of choice for their real life projects. Thus, this chapter will aim to objectively evaluate the project’s methodology by comparing the empirical data which was described in previous sections.

7.1.1

Projects’ Scope

In order to analyse the Kanban suitability for small software projects one needs to refer to the project’s scope which was defined before the project started. As

95

CHAPTER 7. PROJECT EVALUATION

96

was mentioned in section 1.3 the scope that this experiment was concerned with were programs involving 1 to 5 people with less than 5000 lines of code and time investment of less than 1000 hours. However, all three practical projects which were implemented as a part of this dissertation on average did not exceed 400 working hours each. Moreover, they did not exceed the limit of 5000 lines of code nor 5 people involved in the project. Both stages of project Alpha with project Beta were developed by the author himself and were consistent with the experiment’s scope. Project Delta was developed by the former student and can also be classified as ‘‘small” since it was an extension of a bigger application. Project Gamma was also being developed by 6 students from the University of Manchester who similarly to the project Delta were working on a part of a bigger application which was developed by the rest of the team. Furthermore, with respect to project’s scope, all the projects and case studies tend to agree with each other that there is a certain level of abstraction that a particular software project will incorporate as a main way of separating its features. For example, when the ‘‘Evaluation” chapter which is being read right now was posted on the Kanban board it did not include its individual subcomponents. However, these can be added if needed and posted on a separate Kanban board for further development. Another examples are from projects Gamma and Delta both of which were concerned with the development of modules which were part of a bigger upper level application. Also, despite Kanban encouraging its developers to divide their programs into what is referred to as Minimum Marketable Features which were discussed at length in section 2.6 various developers tend to use different strategies for separating their problems. For instance, some developers prefer to use ‘‘story points” which are extensively used in Agile methodology. Others like [Bro10a] prefer to divide them evenly even with the cost of sacrificing its marketability. There is also another group who adhere to the original definition of marketability even if the features are of different sizes [Chr10]. In the author’s case it made little or no difference to include story points into his stories as all the programs’ stories were of similar size. Also project Beta was split according to the method proposed by [Bro10a] of separating features according to their size rather than market value. However, in the program of this size splitting the program into marketable parts that can be approved and sold to the customer can prove difficult to execute. Therefore, in the author’s opinion


97

with respect to software projects of this scope the marketability of a particular story should be ignored and its size and function within a bigger application should be given priority. The author would also recommend the practitioners of Kanban make a rational and calculated decision in each case. It is undoubtedly important to split each of the features evenly, but at the same time it should satisfy the customer’s expectations and be an integral part of the software package which the purchaser is able to conceptualise in business terms. With respect to a project’s size, the application of Kanban should be analysed from two standpoints. The first one is concerned with its use by a single developer, working independently on a software project. The second one will evaluate and comment on the methodology used by a small software development team of 5 or less people.

7.1.2

Personal Kanban

Some argue that a simple list of priorities might suffice for projects of such small scale, while others like [Bro10a] argue that Kanban helps developers by identifying key aspects of their process that might have a negative impact on their performance. Although, there is a range of alternatives that might prove more suitable for a particular software project for instance Personal Software Process or Pomodoro Technique, the author used Kanban for the implementation of his projects. Personal Kanban has been advocated for years mostly by the website called [Ben11]. The author’s findings show that there is an array of advantages that come from using the method even for projects of such small scale. For instance, by implementing just-in-time and the theory of constraints the author was able to focus on a small number of tasks at a given time. This had a profound effect on the development process, which resulted in more concentrated effort and elimination of waste. By focusing on a particular set of features which are relevant to the project’s success the developer can quickly identify the most relevant value-adding activities which contribute to the project’s success. Moreover, with respect to improved learning, a Kanban board does not support swarming, learning and communication to such an extend as a group Kanban does, however there are still benefits to be gained from using it to solve current problems. It also has a psychological and motivational effect on a person by providing pressure and visual stimuli which facilitate the development process.


98

Kanban is a visual system which helps to track the project’s progress. This fact contributes a lot to its success in managing complex projects with multiple tasks. Despite the methodology being suited for projects of such small sizes, it can produce waste for projects of very small scale. Generally it is not advised to implement Kanban for projects of half the size described in this project’s scope, and for ones that have been divided into less than 3 stories. In this case the movement of stories across the board will prove to produce more waste than gains for the developer, thus can be replaced by using a simple to-do list.

7.1.3

Group Kanban

As shown by the data, using Kanban in the context of a group project with more than one participant can have a profound effect on its performance. It was reflected in many studies. For example, in both project Delta and Gamma the system was used to reinforce nine aspects of project work e.g. problem solving which is the effect of putting constraints on work which enables the project’s developers to stay focused on one task and swarm on it. The approval process and feedback loop can become much shorter than in an Agile oriented process. It also motivates a group to become self-organised through visualisation and transparency of work. The users of Kanban in these case studies together with the author himself expressed their enthusiasm while using the method. Its simplicity and visual nature provided its users with much needed transparency which resulted in some useful insights being made about their projects progression. The experimental data from the range of projects tested shows that as the project gets smaller, the communication and cooperation tends to increase. It seems that the communication and regular meetings in front of the board tend to increase people’s commitment in the project and strengthen shared understanding of the project’s complexity. As was mentioned before both project Delta and Gamma noticed how importantly the level of abstraction used by both projects influenced their operational behaviour. The experiment showed that if a feature is too big and too complex its presence on the board tends to create frustration, this was observed in both projects Delta and Gamma. The experiments also showed that the level of abstraction can be easily adjusted by its developers by dividing the features into smaller parts. When it comes to project Beta it showed that the when features are too small they tend to be developed more quickly and can be easily identified on the CFD.


Cumulative Flow Diagram 9 Aspects of Project Work Waste Analysis

Personal Kanban partially applicable partially applicable applicable

99 Group Kanban applicable applicable applicable

Table 7.1: Applicability of a research model to different Kanban projects

7.2

Analysis of the Project Methodology

The methodology that was used to undertake this experiment and the way it was conducted needs to be reviewed if it is to be used in similar experiments in the future. The research methodology which was applied to evaluate and systematically improve each of the projects’ processes was synthesized from the latest findings in the area of lean software development. Its applicability to the improvement of projects of such small nature Table 7.1 shows the applicability of the research framework to a software project of a specific size. As can be seen in the table when with respect to a group of 5 or less people all the methods can be successfully used to analyse the project’s performance as showed by [IPF+ 11, IKA10, Hel09]. However, from the author’s point of view these advanced analytical models are not fully applicable for small scale software projects. For instance, a cumulative flow diagram is useful in identifying which stages of the process are redundant and where bottlenecks can be expected and eliminated. However, its creation requires additional time and energy which in projects of this scale are usually scarce. The same applies to the nine aspects of project work which can be partially useful in analysing the process and self-analysing its performance and aspects that might need consideration and improvement. The data showed that the visual nature of the Kanban system which supports the just-in-time concept usually helps to intuitively embrace the method and utilise its advantages. By contrast to this, analysing waste which is the most important principle of both lean manufacturing and software development can be successfully used in identifying waste which tends to always be present in the majority of software projects. This together with the CFD helps to eliminate redundant processes which add no value to the project and create no value for the customer. The experiment and its findings are to a large extent subjective. Testing a tool as diverse and versatile as the Kanban system which is a concept which can be fully shaped and changed by its practitioners is not an easy matter. Objectivity


100

in this kind of research is hard to find since the experiment was trying to evaluate the usefulness and appropriateness of a particular software development method in a variety of contexts and by a wide range of individuals. On the other hand, the author tried to analyse the problem from a wide range of perspectives and test his data with a range of methods. To conclude in author’s opinion using a complex analysis of the board as a part of the Kaizen process does not correspond to a substantial gain in productivity. Nevertheless some aspects of it can be successfully used if the process is visibly inefficient and might require some intervention. The Kanban system which is based on the theory of constraints provides its developers with an implicit and effective way of reducing waste and moving the project forward. The author believes that the use of writing process as an example of a software development process can be generalised into the area of computer science. Also, the project data is consistent with the findings of [HRW00] who states that choosing students as subjects of an experiment is scientifically valid since their performance is no different of that of programmers working in industry. In the author’s opinion the patterns showed in the experimental data together with the users’ and author’s experiences with the methodology can be inferred to a range of small industrial projects which can benefit from using the system.

7.3

Review of the Project Plan

The initial plan which was outlined in the project’s description was to review case studies from the literature and implement three nes needs to be separated from its actual use by real developers who use it as a tool of choice for their real life projects. Thus, this chapter will aim to objectively evaluate tw ones. The first one of a small company, Assessment21; for another small operation of the author’s choice; and for this project itself. The working data from the Assessment21 projects was mostly non-existent or difficult to obtain. However, it was replaced by the project Delta which proved to be a suitable alternative for this type of case study. Despite the initial difficulties to collect useful data from other case studies, the author managed to collect useful data from different sources.


101

The plan was to conduct a comprehensive analysis of a software development team which was to use Kanban for their MSc project. This analysis was to consist of direct unobtrusive observation and thematic interviews similar to the studies conducted in a Software Factory which is a research project conducted by the University of Helsinki [Abr10, IPF+ 11]. The plan to observe and use the Kanban system in the group project later changed, but the author still managed to collect data from the partial implementation of the system. Also, there was a practical implementation of the project which consisted of 3 case studies, one of which was the continuation of the previous one. As was mentioned before each of the projects was consistent with the scope prescribed by the research methodology which was outlined in chapter 3. The small operation of the author’s own choice was implemented using project Beta for developing a small software application. The project yielded useful experimental data which was later analysed and evaluated. To conclude, the implementation side of the experiment was successfully undertaken its data in the form of three Kanban boards delivered. These were later complemented by the data from two case studies which were analysed and evaluated. The conclusion that can be drawn is that the author of such a large project should be prepared with a backup plan for an eventuality of being presented with a negative result from one or more of his or her case studies. Another advice to be given is to harvest as much data as possible from a study, even if the project ends up with a negative result. Chapter Summary This chapter described the evaluation of the project’s methodology which was the main part of this experiment. First the project’s scope was discussed and the application of Kanban to different software projects was considered by its use by a group of and a single developer. This was followed by an analysis of the project plan and possible improvements that could be made in order to make experiments of similar type more accurate provided there was less time constraint and more resources provided.

Chapter 8 Conclusion and Future Work 8.1

Project Summary

The purpose of this paper was to examine whether Toyota’s project management system which was lately adapted into the area of software development can be successfully used in the management of small software projects. The first task was the detailed analysis of current trends in the software industry of the system itself. The author managed to undertake a comprehensive analysis of the Kanban system and traced it back to its origins in the automotive industry. This helps in the understanding of its main objectives and what was the main motivation behind its application to the area of software engineering. The next task was to develop a research methodology from a variety of sources which would serve as the project’s main analytical framework. The framework was mainly developed on the basis of the latest developments in the area which can be attributed to the software factory project form the University of Helsinki [Abr10] which in part based on the work of Mary Poppendiecks [PP03]. Following this the taks was to schedule the project and think of the best way of testing its practical phase taking bearing in mind its time scale and objectives. After that the practical part of the experiment was started which consisted of two connected projects testing the possible improvement of two consecutive small software projects. The other experiment was an actual web application which was successfully developed and evaluated using the research framework. Together with is development the author managed to test one of the Kanban productivity tools called AgileZen [Cor10], In addition to these case studies the experiment analysed two other archival case studies which used Kanban in their project management 102

CHAPTER 8. CONCLUSION AND FUTURE WORK

103

process. The paper also tested and evaluated three of the most popular Kanban oriented productivity tools available on the internet and made recommendations for their application to a particular size and type of software project. After all of these stages the previous chapter was written which evaluated the work done and methodology used in its implementation. The experimentation data showed the degree to which the Kanban system can be used to facilitate the development of small software projects. It also provided the rationale behind using it in the context of software projects with various amount of developers involved. Moreover, it showed how the project’s abstraction can affect the development process and provided different examples of approaching this issue. Furthermore, the chapter showed in which types of projects the improvement process called Kaizen can be feasibly used. Although not all of the objectives of this experiment were achieved, the work developed a useful framework for testing future software development projects which might be used by potential practitioners of the Kanban system. Further research in the area using the research model which was used in conducting this experiment is encouraged.

8.2

Future Work

Although the author believes that the project undertaken provided the reader with a wide range of case studies which support the experiment’s findings, it can be argued that more comprehensive experiments would yield more conclusive data. More time and adequate resources for funding a control group and undertaking a more comprehensive study would produce more conclusive data. For instance, performing such an experiment in the Software Factory [Abr10] which is a well equipped computer laboratory constructed for such experiments could result in collection of more accurate and objective data from a wide array of perspectives.

Appendix A Project Alpha - Stage 1

Figure A.1: Project Alpha - Stage 1, State 1 from 01.04.2011

104

APPENDIX A. PROJECT ALPHA - STAGE 1



105




106




107

Appendix B Project Alpha - Stage 2

Figure B.1: Project Alpha - Stage 2, State 2 from 11.07.2011

108

APPENDIX B. PROJECT ALPHA - STAGE 2



109




110




111



112

Appendix C Project Beta

Figure C.1: Project Beta, State 5 from 01.08.2011

Figure C.2: Project Beta, State 6 from 04.08.2011

113

Bibliography [Abr10] Pekka Abrahamsson. Unique infrastructure investment: Introducing the software factory concept. Software Factory Magazine, (1):2--3, 2010. [And03] David J. Anderson. The kanban story: Standard-sized features. http: //agilemanagement.net/, 2003. Accessed 22/08/2011. [Ben01] Jim Benson. Manifesto for agile software development. agilemanifesto.org/, 2001. Accessed 30/08/2011.

http://

[Ben11] Jim Benson. Personal kanban - visualise. http://www.personalkanban. com/pk/, 2011. Accessed 30/08/2011. [Bro10a] Pawel Brodzinski. The kanban story:. http://blog.brodzinski.com, May 2010. Accessed 02/05/2011. [Bro10b] Pawel Brodzinski. The kanban story: Measuring lead time. http: //blog.brodzinski.com/2010/05/kanban-measuring-lead-time. html, May 2010. Accessed 23/04/2011. [Bro10c] Pawel Brodzinski. The kanban story: Standard-sized features. http:// blog.brodzinski.com/2011/05/kanban-standard-sized-features. html, May 2010. Accessed 04/07/2011. [CB97]

Susan G. Cohen and Diane E. Bailey. What makes teams work: Group effectiveness research from the shop floor to the executive suite. Journal of Management, 23(3):239 --290, June 1997.

[Cha05] Robert Charette. Why software fails. http://spectrum.ieee.org/ computing/software/why-software-fails/5, April 2005. Accessed 21/04/2011.

114

BIBLIOGRAPHY

115

[Chr10] Chrisincambo. Introduction to minimum marketable features. http: //www.upstarthq.com/, April 2010. Accessed 04/07/2011. [Coh04] Mike Cohn. User stories applied: for agile software development. Addison-Wesley, March 2004. [Cor10] Rally Software Development Corporation. Agilezen. http://agilezen. com/, 2010. Accessed 12/08/2011. [Dav10] Anderson David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010, April 2010. [DB01]

Chris Cowdery Don Bradley. Small business: Causes of bankruptcy. http://www.sbaer.uca.edu/research/asbe/2004_ fall/16.pdf, 2001. Accessed 03/05/2011.

[DC03]

Mark Denne and Jane Cleland-Huang. Software by Numbers: Low-Risk, High-Return Development. Prentice Hall PTR, October 2003.

[Dem00] W.E. Deming. The new economics: for industry, government, education. MIT Press, 2000. [EV10]

J. Laurenz Eveleens and Chris Verhoef. The rise and fall of the chaos report figures. IEEE Software, 27:30--36, 2010.

[Fow01] Martin Fowler. Refactoring home page. http://www.refactoring. com/, 2001. Accessed 07/09/2011. [GOL98] E.M. GOLDRATT. Essays on the Theory of Constraints. North River Press, 1998. [Gro]

The Hybrid Group. Kanbanpad. http://kanbanpad.com/. Accessed 12/08/2011.

[Gro95] Standish Group. The Chaos Report. The Standish Group, 1995. [Hel09]

Aslak Hellesy. Bekk open. http://open.bekk.no/, 2009. Accessed 19/08/2011.

[Hen10] Karhatsu Henri. Building a self-organizing software development team: Multiple case study. Masters thesis, University of Helsinki, Helsinki, May 2010.

BIBLIOGRAPHY

116

[HRW00] Martin H¨ost, Bj¨orn Regnell, and Claes Wohlin. Using students as subjects a comparative study ofstudents and professionals in lead-time impact assessment. Empirical Softw. Engg., 5:201--214, November 2000. [IKA10] Marko Ikonen, Petri Kettunen, and Pekka Abrahamsson. Exploring the sources of waste in kanban software development projects. In Software Engineering and Advanced Applications, Euromicro Conference, volume 0, pages 376--381, Los Alamitos, CA, USA, 2010. IEEE Computer Society. [Iko10]

Marko Ikonen. Leadership in kanban software development projects: A quasi-controlled experiment. In Pekka Abrahamsson and Nilay Oza, editors, Lean Enterprise Software and Systems, volume 65, pages 85--98. Springer Berlin Heidelberg, Berlin, Heidelberg, 2010.

[IPF+ 11] M. Ikonen, E. Pirinen, F. Fagerholm, P. Kettunen, and P. Abrahamsson. On the impact of kanban on software project work: An empirical case study investigation. In Engineering of Complex Computer Systems (ICECCS), 2011 16th IEEE International Conference on, pages 305 --314, apr 2011. [Kau88] J. Kaufman. Technical writing and computer programming. Professional Communication, IEEE Transactions on, 31(4):171 --174, dec 1988. [Kni10] Henrik Kniberg. Kanban and Scrum - making the most of both. Lulu.com, 2010. [Kot96] John P. Kotter. Leading Change. Harvard Business Press, January 1996. [Ltd10] Integrated Geochemical Interpretation Ltd. Integrated geochemical interpretation ltd (igi ltd). http://www.igiltd.com/, February 2010. Accessed 21/07/2011. [McC04] Steve McConnell. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, June 2004. Gartner says world[MT10] Tom McCall and Ben Tudor. wide IT services revenue declined 5.3 percent in 2009. http://www.gartner.com/it/page.jsp?id=1363713, May 2010.

BIBLIOGRAPHY

117

[Ohn88] Taiichi Ohno. Toyota production system: beyond large-scale production. Productivity Press, 1988. [Pin09]

Daniel Pink. Daniel pink on the surprising science of motivation. http: //youtu.be/rrkrvAUbU9Y, August 2009. Accessed 01/05/2011.

[Pol]

Lunar Logic Polska. Kanbanery. http://kanbanery.com/. Accessed 12/08/2011.

[PP03]

Mary Poppendieck and Tom Poppendieck. Lean software development: an agile toolkit. Addison-Wesley, 2003.

[Raj]

Sudheer Raju. Top 15 kanban tools in an agile world. http://www. toolsjournal.com/tools-world/item/142-kanban-tools. Accessed 11/08/2011.

[Rey08] John C Reynolds. Some thoughts on teaching programming and programming languages. ACM SIGPLAN Notices, 43:108110, November 2008. ACM ID: 1480852. [RM00] M. L Russ and J. D McGregor. A software development process for small projects. Software, IEEE, 17(5):96--101, October 2000. [Roo10] Stefan Roock. Lead time and cycle time. http://stefanroock. wordpress.com/, April 2010. Accessed 02/05/2011. [Roy98] Walker Royce. Software project management : a unified framework. Addison-Wesley, Reading Mass. [u.a.], 1998. [RR02]

Noelie Rodrguez and Alan Ryave. Systematic self-observation. SAGE, January 2002.

[SB01]

Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001.

[SG05]

Andrew Stellman and Jennifer Greene. Applied software project management. O’Reilly Media, Inc., November 2005.

[Sho04] James Shore. Phased releases. http://jamesshore.com/, January 2004. Accessed 12/07/2011.

BIBLIOGRAPHY

118

[Sof02]

Rally Software. Rally software. http://rallydev.com/, 2002. Accessed 16/08/2011.

[SS05]

Catherine Soanes and Angus Stevenson. Oxford Dictionary of English (Dictionary). Oxford University Press, August 2005.

[Tea11] NetObjectives Team. Netobjectives: Glossary. http://www. netobjectives.com/glossary/, 2011. Accessed 06/07/2011. [Tho11] Laurel Thoennes. To-do or Kanban? that is the question. http://www.qualitydigest.com/inside/six-sigma-column/ do-or-kanban-question.html, April 2011. Accessed 11/08/2011. [Yer11] Yuval Yeret. Explaining cumulative flow diagrams. agilesparks.com/, 2011. Accessed 22/08/2011.

http://

[Yin03] Robert K. Yin. Case Study Research: Design and Methods, Third Edition, Applied Social Research Methods Series, Vol 5. Sage Publications, Inc, 3rd edition, December 2003.