See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/262882654

Business Process Reengineering Through Lean Thinking: A Case Study

Article · April 2014

DOI: 10.1080/19488289.2013.879681

CITATIONS READS

8 1,201

3 authors, including:

Gopalakrishnan Narayanamurthy
University of Liverpool Management School, Liverpool, United Kingdom
49 PUBLICATIONS   153 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Gopalakrishnan Narayanamurthy on 26 August 2015.

The user has requested enhancement of the downloaded file.

Business Process Re-engineering through Lean Thinking – A Case Study

†
Anand Gurumurthy

Assistant Professor

Quantitative Methods & Operations Management (QM & OM) Area

Indian Institute of Management Kozhikode (IIMK)

IIMK Campus, Kunnamangalam, Kozhikode, Kerala – 673570, India.

E-mail: anandg@iimk.ac.in

Phone: +91-495-2809435, Fax: +91-495-2803010

Arpitha Chandrashekar

Product Manager

Simplilearn Solutions Private Limited

Manoj Arcade, #53/1, 24th Main, 2nd Sector, HSR Layout,

Bangalore, Karnataka – 560102, India.

E-mail: arpitha.c@simplilearn.com

Phone: +91-9916924364

Gopalakrishnan Narayanamurthy

Fellow Program in Management

Quantitative Methods & Operations Management (QM & OM) Area

Indian Institute of Management Kozhikode (IIMK)

IIMK Campus, Kunnamangalam, Kozhikode, Kerala – 673570, India.

E-mail: gopaln06fpm@iimk.ac.in

Phone: +918943687765

1
 Business Process Re-engineering through Lean Thinking – A Indian Software Industry Case

Study

Abstract

Contemporary organizations dealing with software development are under immense pressure to

deliver their software products quickly within the prescribed time frame with the highest quality and

lowest cost as the knowledge work involves more dynamicity, invisibility and uniqueness.. To remain

competitive organizations are trying out the principles and concepts of Lean Thinking (LT), which

were highly successful in the manufacturing sector, to improve the Software Development Process

(SDP). This led to the development of a new paradigm called Lean Software Development (LSD). A

literature review revealed that application of Value Stream Mapping (VSM) – a key tool in the

armoury of LT is sparsely applied in the software sector, while the application of VSM especially to

re-engineer the business process of a software organization is not yet reported. The objective of this

study is not only to demonstrate the application of VSM, but also to reinforce various theoretical

concepts of LT apart from demonstrating the utilization of different lean tools to re-engineer the

business process of case organisation. Hence this paper demonstrates an real time application of VSM

for carrying out a complete Business Process Re-engineering (BPR) of a firm that provides software

supply chain solutions to logistics providers. Inferences obtained can be reinforced and made

extensive by performing the same study in other similar companies.

Keywords: Business Process Re-engineering (BPR), LSD case study, Enterprise Transformation,

Indian software industry, Lean Software Development (LSD), Lean thinking, Third Party Logistics

(3PL) service provider, Toyota Production System (TPS), Value Stream Mapping (VSM).

2
 Business Process Re-engineering through Lean Thinking – A Indian Software Industry Case

Study

1 Introduction

The market for software is fast paced with frequently changing customer needs and burgeoning

technological developments. Organizations in software development and support are under immense

pressure to deliver their outputs within the prescribed time frame with the highest quality and lowest

cost. Poppendieck and Poppendieck (2010) vouched that “in order to stay competitive, companies

should react to the changing needs in a rapid manner. Failing to do so often result in a higher risk of

market lock-out, reduced probability of market dominance, and it is less likely that the developed

software product/service conforms to the needs of the market”. Hence, software organizations are

attempting to reengineer their Software Development Processes (SDP) by implementing or/and by

improving the conventional Software Development Life Cycle (SDLC) models (such as Waterfall

Model, Incremental Model, Spiral Model, etc.) or by adopting hybrid models such as Extreme

Programming (XP), Scrum, Feature Driven Development (FDD), etc., which were recently brought

under the umbrella of “Agile Software Development (ASD)” - a new paradigm that emerged after the

declaration of Agile Manifesto in 2001 (Wang et al., 2012). Mishra and Mishra (2011) analyzed the

application of agile development methodologies and management approach in developing a complex

software project related to Supply Chain Management (SCM). They also demonstrated how to

overcome risks and barriers in each development phase of such complex inventive software projects

apart from providing a set of guidelines regarding how the agile methodologies can be adopted,

combined and used in these kinds of complex software projects. On the other hand, there are another

set of software organisations, which are trying out to explore the possibility of introducing the

principles and concepts of Lean Thinking (LT) proposed by Womack et al. (2003) to improve the

SDP, as it has the capability to yield significant reduction in cost and variability, while improving the

3
delivery, quality level and flexibility. Hence, a new paradigm called Lean Software Development

(LSD) has emerged. Raman (1998) who explored the feasibility of applying the principles of LT to

software development concluded that it is very much feasible and suggested various tools and

techniques such as reusability, rapid prototyping, object-oriented technologies, component-based

software development, concurrent engineering, quality function deployment, etc.

However, these two paradigms have created confusion among the practitioners. There are some who

say that both ASD and LSD are entwined. Recently, Wang et al. (2012) have proposed the concept of

"leagile software development", which attempts to combine the benefit of both lean and agile

methodologies. They examined 30 experience reports published in past agile software conferences

which dealt with the application of lean approaches in ASD. Based on this, they identified six types of

lean application and concluded that lean can be applied in agile processes in different manners for

different purposes. However, there are other practitioners who point out that both are fundamentally

different. Wang and Conboy (2011) explained that only the evolution processes of agile and LSD are

intertwined. They noted that there is a shift happening from agile methods to LSD in recent times.

Even Hibbs et al. (2009) noted that though LSD was originally viewed as just another agile method,

there is an increasing focus on lean and it is viewed as being a separate category in itself rather than

an instance of agile methods.

Irrespective of such conflicting deliberations, it is our belief that these paradigms (i.e., LSD or ASD)

are still under development and they are yet to reach a maturity to warrant the emergence of third

paradigm (i.e., leagile) especially in the software sector. Dingsoyr et al. (2012) too noted that although

there is an unparalleled growth in the realm of ASD, much work has still to be undertaken to bring

coherence to the current discourse on agility. Supporting the statement of Dingsoyr, literature review

of papers related to LSD (presented in the next section) revealed that most of the existing works are

4
focused on describing the theoretical concepts of LSD, while some of them are case studies that

describe the implementation of certain tools and techniques related to LSD. Very few papers in that

exist in the realm of LSD, which demonstrates the application of Value Stream Mapping (VSM) – a

key tool in the armory of LT. Rother and Shook (1999) defined value stream as all the actions (both

value added (VA) and non-value added (NVA)) that are currently required to bring a product/service

through various process steps to the customer. They also defined VSM as a pencil and paper

visualization tool, that shows the flow of material and information as a product/service makes its way

through the stream. Generally, the implementation of lean in manufacturing starts with the application

of VSM, as evident from the tenets of LT proposed by Womack and Jones (2003). Furthermore, it

has emerged as the preferred way to implement LT, as it attempts to integrate different tools and

techniques (Lian and Van Landeghem, 2007). Hence in this paper, an attempt has been made to

identify how VSM can be utilized to efficiently reengineer business process with the application of

different tools and techniques of LT by demonstrating a case study of a software development

company in India that provides supply chain solutions to different logistics providers.

This paper is structured into five sections to convey the work carried out. Section 2 presents the

literature review of LSD in general apart from focusing on case studies describing the implementation

of LSD in particular and review also identifies the level of application of VSM in the software sector.

Section 3 provides an overview of the case organization. Section 4 deals with application of VSM for

the case organisation where description on current state value stream mapping and future state value

stream mapping is also provided. Finally, section 5 presents the conclusive inferences arrived based

on this study.

2 Literature Review

Mujtaba et al. (2010) defined LSD as “a contemporary approach to software engineering management

that includes a set of practical tools to improve process efficiency”. Poppendieck and Poppendieck

5
(2003) emphasized that organisations adapting LSD need to comply with the following seven

principles: eliminate waste, build quality/integrity in, amplify learning/create knowledge, defer

commitment, deliver fast, respect people/empower the team, and optimize the whole. They explained

that all these principles are derived from the principles of Toyota Production System (TPS), which

was developed by Taiichi Ohno while working at Toyota Motor Corporation (TMC) in the 1940s.

They noted that implementing TPS in TMC resulted in the following benefits: less direct labor,

reduced parts and work-in-process inventory and fewer defects. Furthermore, they have already

written in great detail about the theory and concepts of LSD such as wastes in software development,

associated tools and techniques of LT for software development, etc in their book. Based on the

understanding we can define the concept of LSD in simple terms as the application of the principles

and concepts of LT to improve the SDP.

2.1 A brief review of recent literature of lean software development

In this section, the reviewed literature has been classified according to the general theme of LT,

namely value and waste, LT tools and techniques and its specialized tools and techniques.

 Value and waste: Mandic et al. (2010) noted that the work of Poppendieck's on LSD takes a

view on software development from the lean angle. However, they commented that it blurs

the true nature of a SDP and hence provided an interpretation based on an opposite view - a

view on LT from the software development angle and thereby attempted to understand the

nature of flows in software development. In the process, they defined the generalized concept

of value creation points apart from proposing a system of three axioms to capture the specifics

of software development. Kundu et al. (2011) provided an insight into the various types of

wastes in IT service system from the perspective of lean management. They conducted a

study on 12 IT support service lines and identified different waste/non-value added activities

6
 in these services. Furthermore, they classified the identified wastes into 13 groups: defects,

re-invention, unnecessary motion, waiting, over processing, inventory, resource

inefficiencies, hand-offs, external quality enforcement, processing inefficiencies, lack of

system discipline, ineffective communication and recurring incident.

 Lean Practices in SDP: Curtis (2011) noted that the largest source of waste in application

development and maintenance which cause enormous rework is defects. He explained how

focusing on the Jidoka pillar of the TPS by means of automation can detect and eliminate

defects and rework. He concluded that by applying the waste-reducing principles of Jidoka to

development, maintenance, and the design of applications, IT can both cut costs and shorten

time-to-service. Petersen and Wohlin (2011) commented that having a continuous and smooth

flow in the SDP would help in quickly delivering the value to the customer. Hence, they

utilised cumulative flow diagrams to visualize the flow of LSD apart from defining novel

measures to achieve the following goals: (1) to increase throughput and reduce lead-time to

achieve high responsiveness to customers' needs and (2) to provide a tracking system that

shows the progress/status of SDP. They evaluated these measures using an industrial case

study and showed that the practitioners found the measures useful in seeing the progress of

development for complex products where many tasks are executed in parallel. Corona and

Pani (2012) noted that Kanban systems are used in LSD as an approach to scheduling work,

where the requirements are expressed in atomic features (also known as user stories, work

items, Minimum Marketable Features (MMF)) and are implemented incrementally as and

when required. However, they noted that there is no standard definition of Kanban system for

software development, and the specific practices of Kanban have not yet been rigorously

defined. Hence, using a survey apart from rigorous analysis of the available information, they

demonstrated how Kanban approach - in particular those related to the Kanban board

management is presented and used. On the other hand, Ikonen et al. (2010) highlighted that

7
 although there is a wide spread belief that application of agile/lean software methods

contribute to the trend of continuous improvement in the software industry, it needs to be

empirically validated. Hence, they presented a preliminary research model, whose results

suggested that Kanban can be an effective method in visualizing and organizing the current

work, but it does not prevent waste from creeping in, although the overall project outcome

may be successful.

 Specialized tools and techniques for LSD: Petersen and Wohlin (2010) proposed a novel

approach called Software Process Improvement through the Lean Measurement (SPI-LEAM)

Method, by bringing together the quality improvement paradigm and LSD practices. They

explained that this method allows assessing the performance of the development process and

taking continuous actions to arrive at leaner SDP over time. Mohan et al. (2010) explained

that similar to SDLC, which is generally used in software projects, SAP implementation

projects use ASAP methodology. They said that defects found at support level will be very

expensive and even would cause serious technical issues and eventually effect business

decisions. Hence, to overcome this issue, they described a new problem–solution framework

by using Requirements Engineering (RE), Unified Modelling Language (UML) and LT

together in SAP Business Intelligence (BI) environment to handle issues occurring at the

maintenance levels. Bastarrica et al. (2011) noted that “software companies tend to define and

formalize their development processes in an effort to make them more predictable. They

emphasized that it may introduce unnecessary tasks and work products as part of the

formalized process, which may build up waste into the process”. Earlier, they developed a

tool for visual analysis of software processes called Analysis and VIsualization for Software

Process Assessment (AVISPA), which can identify a series of error patterns such as

conceptual errors in the process design, errors introduced during process specification, which

they claimed are frequent in practice (Alegría et al, 2011). They extended this AVISPA tool

8
 to also identify another type of waste other than the 7 wastes proposed by Poppendieck (2007)

– i.e., useless work products in software processes formally specified in Eclipse Process

Framework. They applied the extended tool in two quite diverse scenarios: the Scrum process

specification and the SDP of a medium size software company in Chile. Bastarrica et al.

(2011) found that in the former case, no waste (i.e., useless work products) has been found as

expected, while in the latter case, they identified and localized several waste elements.

Kuusela and Koivuluoma (2011) hinted that software intensive enterprise’s cloud

transformation should have LT woven in. Hence, they proposed a lean transformation

framework, which highlights the significance of learning, iterative execution and holistic

approach involving the whole enterprise in the transformation. They enumerated the first

experiences of their proposed framework using a case of large IT service company. Petersen

(2012) proposed four lean indicators aiming at detecting the waste in the software

maintenance process, namely the inflow of maintenance requests, the flow of maintenance

requests through the maintenance process with regard to continuous value creation and high

throughput, the analysis of lead-times, and the analysis of workload. They used a case study

of Ericsson AB to demonstrate the application of these indicators in the maintenance process.

2.2 Review of case studies in lean software development

Apart from the development of theoretical concepts, the implementation of LSD too has started

gaining importance among the practitioners. Middleton (2001) carried out a case study in an

organization that employs 7000 people and performed the "before" and "after" analysis by which he

confirmed that LSD can produce rapid quality and productivity gains. Poppendieck et al. (2006)

described the implementation procedure of LSD in their book. However, Middleton and Joyce (2011)

reported that the first recorded experiments with LSD were carried out by one of the author(s) in the

year 1993 itself. They also quoted Middleton et al. (2005) and noted that “Timberline Software in

9
Oregon in 2002 with 450 staff was the first recorded full industrial implementation of LSD. Cawley et

al. (2011) reported about a case study of a company called MedTech (a pseudonym), a large US

medical device company, which utilized the concepts of lean principles for developing software

during the design of Medical Devices that are governed by strict regulation and compliance. Widman

et al. (2010) explained that the developers in IMVU Inc. - a virtual worlds company, were able to

implement traditional tenets of lean (except ”creating pull” practice which was changed as to

"involve and empower employees") and thereby could identify and reduce common wastes in

software development process such as over-production, waiting, process, and defects. Middleton and

Joyce (2011) examined how the lean ideas behind the TPS can be applied to software project

management using a case study of a nine-person software development team employed by BBC

Worldwide based in London. They concluded that over the 12-month period, the performance of the

team was significantly improved with lead time to deliver software increased by 37%, consistency of

delivery rose by 47%, and defects reported by customers fell by 24%. They also noted the case

organization used various lean methods such as visual management, team-based problem solving,

smaller batch sizes, and statistical process control for improving the software development.

Rudolf and Paulisch (2010) described how lean approaches should be interpreted for the creation of

software-based systems. They presented a case study on how lean is applied in a project at a Siemens

business unit by addressing various issues relating to the portfolio and product management,

architecture, product lifecycle management processes apart from people and organization related

issues. Iberle (2010) highlighted that lean is able to handle situations which are difficult to handle

using the most commonly known agile methods, such as large, complex, and partially waterfall

systems, by applying methods derived from queuing theory and statistics. Furthermore, she also

demonstrated various lean methods with examples and results from actual projects in the HP Inkjet

and LaserJet businesses. Norrmalm (2011) used a case study approach to demonstrate the application

10
of LSD in a traditional SDP of a large manufacturing-oriented organization. The improvement areas

in terms of lead time and quality were identified using VSM and a framework of seven common

improvement areas in software development was designed. He also enumerated the four imminent

obstacles in adopting LSD, which were deep vertical but narrow horizontal expertise among

developers, organisational arrangement of teams, geographical arrangement of teams and inherent

conflict between the prescriptive activities currently followed and the adaptability of agile

methodologies.

Bocock and Martin (2011) used a case study of an open source project titled ‘Apollo’ to explore the

practicalities of how one high-performing open source team has adopted lean practices. They found

that the existing meritocratic decision-making culture of the team such as visibility of decisions,

visibility of work, visibility of people, team working, communication, etc., have greatly assisted the

team's application of Lean principles to their SDPs. Malladi et al. (2011) identified some of the best

practices in lean methodology as applicable to the IT service delivery and used a case study approach

to demonstrate the application of these practices by identifying those areas that inject waste into the

IT services and provide supporting recommendations to eliminate such non-value added work. Staats

et al. (2011) examined the applicability of lean production to knowledge work using a case study of

Wipro, an Indian software services firm. Based on the results of empirical analysis, they found that

lean software projects performed better than non-lean software projects for most performance

outcomes. Ikonen et al. (2011) studied how Kanban impacts on software project work by developing

a framework and empirically investigated the same in an experimental software R&D setting called

Software Factory using nine theoretically derived perspectives and concluded that kanban process

model provided considerable benefits in the form of motivation and control over the project activities.

11
2.2.1 Review of application of Value Stream Mapping in the Software Sector

A literature review of case studies revealed that only very few papers were available that dealt with

the application of VSM in the software sector. Mujtaba et al.(2006) dealt with application of VSM in

a case organization to identify waste-related problems in a software product customization process.

They conducted the study at the telecom company - Ericsson AB and collected the empirical data

using document analysis, interviews, etc. to construct the present state VSM. This map was then used

during the interviews with key stakeholders where they identified waste and proposed measures to

avoid them. Based on the solutions proposed, they demonstrated the construction of a future VSM.

Musat and Rodriguez (2010) explained how the LT tools and techniques such as VSM can be applied

in a Software Product Line Engineering (SPLE) and how it should be tailored for the software field.

They presented only a example of SPL definition process for mobile phones software and attempted

to improve the same through VSM. Gustavsson (2010) observed that the architecting process is

performed during the early phases of the embedded software development when uncertainty is very

high. He also said that the architecting process will not create immediate value to the end customer.

Hence to improve this situation, VSM has been adopted and evaluated to analyze and identify

improvements of the architecting process within embedded systems development. He presented the

practical experiences of using this adopted VSM by conducting interviews at two automotive

manufacturers and concluded that VSM is shown to be a valuable tool to identify waste and thereby

improve the architecting process.

2.3 Research gaps

From the above reviews, the following inferences can be drawn:

 A good number of research papers and few books are available, which dealt with the

theoretical aspects of applying LT to software development. Researchers have attempted to

12
 identify the wastes that happen in software development, suggested different tools to identify,

reduce/eliminate wastes such as AVISPA and proposed performance measurement and

monitoring systems such as SPI-LEAN.

 Other group of researchers were attempting to document the implementation aspect of LT in

software development through case studies. They enumerated the application of different

elements of LT such as Kanban, Statistical Process Control (SPC), visual management, team-

based problem solving, reusability, rapid prototyping, component-based software

development, etc. Furthermore, they also identified some of the barriers for implementation.

From the literature review inferences it is clear that none of the case study papers which

described the implementation aspects of lean dealt with the extensive application of VSM – a

key tool to start with the lean transformation. Although a few of them dealt with the

application of VSM, they had shortcomings which are addressed being in this paper. For

instance, in the case of Mujtaba et al. (2006), the VSMs were not constructed by utilizing the

proper symbols and icons as recommended by Rother and Shook (1997). Secondly, the VSM

was conducted at a telecom company, where software development was carried out as an

auxiliary function. Same is the case with the case study presented by Musat and Rodriguez

(2010). They presented a application of VSM by oversimplifying the development process

into mere 3 steps thereby imputing several approximations and not representing the real

scenario. In the case of Gustavsson (2010), VSM was used by adopting the same during the

early phases of the SDP – i.e., during the software architecting phase. However, the case was

carried out in an automobile company.

In this paper, an attempt has been made to overcome the above shortcoming by applying VSM in a

company, whose core activity is software development and maintenance. By extending the study,

revealed results can be generalized across the similar core software industries for which none of the

existing studies act as a surrogate. Lastly, in this paper, the application of VSM goes beyond waste

13
identification and elimination and describes how it was applied to re-engineer the business process of

the software company, which also affected the SDP followed in this firm.

3 An Overview of the Case Organization

To demonstrate the application of VSM for reengineering the process, a case study approach was

utilised, as it is considered to be more appropriate method to examine contemporary real-life

situations and provide the basis for the application of ideas. Middleton and Joyce (2011) too have

listed out the reasons for utilising case study approach and the same is valid for this situation too. The

details regarding the case organisations were collected by one of the authors, who had the opportunity

to do the summer internship for a period of 2 months, where she was given the task of improving the

business process (naturally the SDP) as part of her project. Data were collected by adopting different

methodologies and from various sources such as direct observation, group discussion, documented

records, email exchanges that happened between the teams in India and Country S, etc. For any

clarifications or explanations, she had the opportunity to discuss the same with the employees and

thereby collecting data informally. The details regarding the case organisation are given below.

However, to maintain the confidentiality requirements, the name of the company and the process

details have been masked.

Company A is a software company headquartered in India, which develops software product for the

niche market of logistics and Supply Chain Management (SCM). It provides software and internet

solutions for the Third Party Logistics (3PL) providers, Fourth Party Logistics (4PL) providers,

shipping industry and freight forwarders. As part of the expansion strategy, it acquired a growing

company abroad (country S), which was serving majority of the customers in their regions through its

legacy software product called “XS” built on AS400. Although, this product was used by its clients, it

14
is subjected to frequent change, enhancements and modifications depending on the user requirements

or changes that happen in the Governmental regulations in the country S. These developments were

carried out by the people in the Indian Development Centre (IDC) considering the outsourcing

potential, low cost and English speaking labour availability in India. Since, this company was

recently acquired, it was found that the current development process of the acquired company was not

meeting the standards of Company A, which is currently CMMI (Capability Maturity Model

Integrated) Level 5 certified. Furthermore, the Chief Executive Officer (CEO) was a young, dynamic

and a highly intellectual person and he was interested in improving the existing process with the

concepts of LT to respond faster to the change requests. A detailed description about the process

followed and problems at hand are described in the subsequent sections.

3.1 Current process for carrying out the enhancements and modifications of XS software product

The team coordinating and working for the software product XS consists of the following people:

Mrs. KT - the customs broker is the only person in the entire organization to have understood the

custom regulation of Country S in depth. She has an experience in this field for over 20 years. She

works from Country S along with Mr. DG and two others, who provide necessary input and feedback

to the team located in India as and when there is a change in Governmental regulation or customer

requirements. The team in India comprises of 20 developers solely working for developing and

maintaining XS. The existing process of performing the modifications and developing the

enhancements for XS is detailed below:

Whenever there is a change in the regulations of customs in Country S or if the clients request for

enhancements, modification, corrections of the software product functionality, then the need for

change is notified to the customer support. Mrs. KT will go through such changes and provide details

15
on the functional aspect required for this change to the techno-functional consultant. Techno-

functional consultants - Mr. MT in India or Mr. DG in Country S will receive the online information

from Mrs. KT. In case of any doubts, Mr. MT asks for clarification either from Mrs. KT or Mr. DG. If

there is no doubt, the Task Definition Document (TDD) is drafted, which will be verified by Mrs.

KT/Mr. DG at Country S and Mr. RO - the techno-functional head of customer support for XS team

in India. Depending on the availability, priority and severity of the issue, the TDD will be raised by

either the techno-functional consultants in country S or Mr. RO in India. These are the only two

people who are authorized to raise the TDD. After raising the TDD, the problem statement along with

possible solution is mailed to the customer for approval. This step is to check if this proposed

solution would resolve their current problem and thereby meet their needs. If the customers think it

will possibly solve their problem they will approve. If not, they will suggest a detailed problem

statement with necessary clarifications. In this case, the previous process of verifying and raising

TDD (with version changes) repeats. If the problem requires solution which involves cost for

enhancements or customization of new operation in to the software, the particular customer request

will be billed and this needs approval from the Account Manager (AM). If there is no cost factor

involved, it moves to the next stage. Subsequently, it is assigned to the Product Development Team

(PDT) in India for coding, who refers to technical codes and functional description provided by

functional consultant. During this step, there are a lot of repeated clarifications on customs related

information even before the actual product development phase starts. After such clarifications, the

software code is developed to meet such functional requirements and change. After the completion of

coding or development, testing is performed in 2 steps:

o Unit testing by programmers specific to their coding to find logical or programming errors, which

will be subsequently corrected by the PDT.

o Testing (both positive and negative testing) by Quality Assurance (QA) team to perform checking

from customers perspective apart from the routine functionality check.

16
Based on severity and priority of work, Mr. RO the techno-functional head of customer support for

XS team in India, Mr. MT or the development head performs the code review and functionality

alignment check. Repeated clarifications happen during this phase too especially if it is “customs”

related. If the verification is passed, then the final review is done by Mrs. KT or Mr. DG. In case they

find any fault or rework to be done, then the entire process starting from product development needs

to be repeated. (The current process for this XS product shows around 20% of cases are having this

issue, which in reality meant that a significant amount of time, resource and man-hours are wasted).

After the review verification is completed, the Program Temporary Fix (PTF) - a fix placed in client’s

system in production system/development environment is prepared. Once it performs satisfactorily,

the PTF is released to the customer on a monthly basis as per the agreement or immediately if it is an

emergency issue. The entire process is projected as a flow chart in figure 1 and figure 2 tabulates the

human resources involved in XS development with their designations and country.

“Take in Figure 1”

“Take in Figure 2”

Although a verbal description of the entire process was obtained, other details regarding the time

taken, delay and other process parameters were not captured. Hence, the entire process of

development was mapped using VSM as it has the capability to uncover and quantify different wastes.

4 Application of Value Stream Mapping for the Case Organisation

A brief review of papers related to VSM revealed that it has been widely applied in manufacturing

(Anand and Kodali, 2011). Although VSM has applications in service sector, it is applied in limited

fields such as education, health care, etc. Fisher et al. (2011) applied VSM to academic advising of

undergraduate students in a large department of a major university. Paciarotti et al. (2011) focused on

17
the application of VSM to reorganize the work placement service in one of Italy’s major third sector

organizations. Lummus et al. (2006) utilised VSM in a small medical clinic that helped in

significantly lowering patient wait time and increase in patient throughput. One of the reasons for

such diverse applications of VSM is that it has many advantages:

 It provides a bird’s eyeview of the entire process – from start to the end

 It facilitates looking at the process from the perspective of an outsider while identifying key

problem areas in the process steps in the form of NVA activities such as delays, unnecessary

rework due to errors, poor information flow, etc. and helps in identifying the wastes as well as

the areas of improvement.

 It also captures various data such as processing time, waiting time, setup time, defect rate, etc.

which provides adequate information about the process performance

However, not many applications of VSM were found in the software sector except that of Mujahid et

al. (2010), Musat and Rodriguez (2010), Gustavsson (2010). Furthermore, to develop a VSM,

specialized symbols, notations and icons are to be used. Details regarding the notations and icons are

available in Rother and Shook (1999) and Poppendieck and Poppendieck (2003). None of the above-

mentioned papers utilised them. It should also be remembered that VSM was primarily a

manufacturing tool to map the material and information flow. However, in the case of software

industry, the information flow is predominant. Similarly, the software development also possesses

those unique characteristics (such as no inventory, invisibility, dynamicity, immeasurable,

ambiguous, role of customers, etc.) that are typical of any service business. Hence VSM need to be

adapted suitably while applying for the software. Generally, VSM is done in two steps which are

discussed in following two subsections. The first step is to draw the current state map, which is a

snapshot of how things are being done now, and the second step is to draw the future state map that

shows how things ought to be done.

18
4.1 Current state value stream mapping

The current state VSM as shown in Figure 3 was constructed for the case organization for the process

described in Section 3.1. It shows the entire process along with its sequence apart from depicting

other details such as Processing Time (PT), Delay Time (DT), number of people involved, etc.

“Take in Figure 3”

4.1.1 Problems observed from the current state value stream mapping

From Figure 3, potential problem areas in the development process were identified, which are briefly

discussed below:

 Dependency: Increasing dependency on Mrs. KT due to lack of custom’s knowledge among

Indian work force. This results in frequent exchange of information that flows back and forth,

which naturally increases the time for response due to the time difference between Country S and

India. It also results in significant delay for carrying out subsequent activities.

 Unclear and Overlapping Responsibilities: Furthermore 4 different people are made responsible

for 4 different functions: custom, import, export, accounts. All this, will result in wastes called

“unclear requirements” and “multiple handoffs”, due to which the requirements specified by the

clients and the domain experts in India and Country S are not clear to the developers.

 Information Asymmetry: Repeated clarification about the action to be taken due to doubts in

understanding of customs details, techno-functional issue in every step from writing, reviewing,

raising and approval of TDD, code reviewing by people in Country S, QA testing. This issue also

contributes to the waste of “handoffs”.

19
 Bugs and errors: Many re-works and iterations due to quality issue, mistakes, inaccuracies &

incomplete work consumes additional resource, time & efforts. This issue is naturally due to the

presence of “bugs and errors”, which is a serious problem, as it may affect the customer

satisfaction.

 Quality-Cost trade-off: Too many unnecessary steps – bug fixing, re-work, re-testing, 2-3 times

reviewing (once by Indian XS-Customer support team & once by the team in Country S). This

problem naturally leads to the waste called “extra efforts” and the customer will not be paying for

these extra efforts carried out by the team.

 Shifts: One of the common problems is that shift of people from one project to another – due to

sudden requirement of workforce for emergency project/ enhancement/ issue solving. Primarily,

it leads to a waste called “handoffs”, which involve “knowledge transfer” related to codes and

documentation to the new developer. Secondly, it also leads to another waste called “relearning”,

as the new developer need to learn again what the earlier developer has coded and thereby the

time is wasted.

 Multiple Decision Makers: Another common issue in the organisation is the use of multiple

sources from where the assignment is obtained. In addition, it is sent to multiple people through

email for everyone’s approval, resulting in waiting and thereby delays in the work.

 Lack of standardization of repetitive task: No standard template is followed while receiving

customer complaints /enhancement support in stage one which leads to extra steps like re-

verification and waiting time to get approval from customer to proceed with the development

work. This is currently resulting in a waste called “partially done work”. Although the customer

complaints/requirements are obtained, it is not created in a detailed manner leading to lot of

confusion among the developers thereby resulting in other types of wastes.

20
Thus, analyzing these issues, it can be found that several wastes proposed by Poppendieck (2007)

exists in the current process. These wastes are causing significant lead time for development apart

from wastage of resources, time and money. A cursory analysis of the current state VSM reveal that

the total lead time is about 54120 minutes out of which only just 2280 minutes is spent on the value

addition process. Thus, the process cycle efficiency, which is the ratio of value added time to the total

lead time, is as low as 4.21%.

4.2 Future state value stream mapping

To overcome the above issues, the project leader, functional heads and some of the team members,

along with one of the authors’ brainstormed and suggested the following solutions:

4.2.1 Potential solutions proposed

 Gap reduction between customers and developing team: Reduce the number of sources - from

where the issue/enhancement is raised. This can be accomplished by providing authorized access

to the tickets raised by the customer support team and the responses of Mrs. KT/Mr.DG or other

functional consultants to the team leader. Based on the expertise, he/she will assign each of these

issues/enhancements to individual team members. Thus, a simple process improvement can be

carried out in the current way of working.

 Knowledge Transfer to all involved: Increase awareness and knowledge regarding customs

regulations in Country S among the Indian workforce by arranging them to participate in

seminars/webinars, certification courses, etc. This helps in motivating the people and also

provides them the opportunity to learn new things. Apart from this, it also helps in creating a

flexible workforce – a necessity for implementing LT.

 Andon/Jidoka: Develop “proceed until halted” method by keeping Mrs. KT/Mr. DG in the loop

through carbon copying of emails and if any abnormality arises, it can be halted as advised by her.

21
 This solution is similar to the concept of “Andon/Jidoka”, where the development process is made

to flow without hindrances. However, if any defects or issues arises, then it is stopped, which is

similar to stopping the production line, when abnormalities happen.

 Standardized learning tools for repetitive tasks: Establish online reference and knowledge

management system. As mentioned in the 1st solution, this would facilitate an opportunity for the

people to learn by themselves apart from avoiding repeated clarification. This is similar to a lean

element called “creating standard operating procedures (SOPs), one point lessons, etc.”, which

provides a good knowledge about the existing process to the workers.

 Update the customs knowledge and functional aspects of XS to all technical people through

necessary internal training, which is also similar to the lean element of improving people’s

capability through training and education. It is considered to be one of the pre-requisites for LT.

 Job Enlargement: Develop in-house expertise in customs related knowledge by choosing a

technical expert, who has a thorough knowledge of functional process so that the dependency on

Mrs. KT can be reduced. This is related to a concept called “job enlargement” - one of the

fundamental aspects of LT. This would also result in reduction in delay time (Waiting time of

response can be reduced by half) – This refers to lead time reduction activity.

 Buffer workforce and excess capacity: Preventing changes of the work force for emergency

projects by having buffer workforce. This concept resembles “having multiple small machines”

and “having excess capacity”. These elements help in adjusting the capacity to change in

demands. This can also be equated to the concept of “focused factory”, where dedicated resources

are used for producing one particular products/product family. In a similar way, the buffer

employees in the form of excess capacity are exclusively used for development of Product XS in

case of emergency or priorities cases. It should be noted here that these “buffer employees” are

not hired. Rather due to improvement in the process, some of them among the existing team of 20

22
 might become free, who can be utilised for this purpose. During the idle time, these employees

can also be used to develop and streamline the internal support process (such as attendance of

house keeping, management of energy consumption, etc.), of the organisation.

It should be clearly understood here that these are the potential solutions identified for the case

organization to eliminate various wastes irrespective of their feasibility to implement. Furthermore,

the solutions provided are not exact elements of LT, but are conceptually similar. However,

considering these potential solutions, a future state map is developed for the case organization. Figure

4 shows the future state map for the development process of XS.

“Take in Figure 4”

From Fig 2, it can be inferred that the process can be significantly re-engineered and improved based

on the proposed solutions, which can eliminate/reduce most of those wastes identified in Section

4.1.1. An estimate of reduction in delay within the process, customer waiting time, defects are made

pragmatically based on the discussion with process improvement team and the business heads by

assuming that all the potential solutions would be implemented. It can be found that although the PT

seems to increase from 2280 minutes in current state map to 2762 minutes in future state map, the

wastes in the form of rework, delay, handoffs, etc. have been significantly reduced. It is estimated

that lead time can be significantly reduced from 54120 minutes to mere 7802 minutes. This can lead

to process efficiency cycle of 35.40%, which is a significant improvement when compared to the

process cycle efficiency of 4.21% for the current state VSM. Thus, this future state map has attempted

to provide a detailed roadmap for improving the business process. Apart from this, it provides a snap

shot of how the process might look in future and also suggest how much the performance can be

improved. Thus, it provides motivation for the organization to achieve such an improved

performance.

23
5 Conclusions

This study started with the claim that the new paradigm LSD has emerged and it is growing for its

huge potential to generate competitive advantage for firms. However, a literature review on LSD

revealed that very few papers have demonstrated the use of VSM with special reference to service

industry. Hence, in this paper, an application of VSM, especially for re-engineering the business

process of a software development company in India was presented. Development of current state

VSM resulted in finding out the problems in the organization, which were co-related to different

wastes identified by the proponents of LSD. The team was involved in identifying possible counter

measures to resolve those issues. With the help of the same, a future state VSM was drawn, which

suggested that the case organization can benefit significantly with an overall improvement in the

performance measures. Also, it provided the general roadmap with nature of steps to be takenby the

service organization to implement lean concepts. Currently, the managers have established the time

lines for implementing various solutions recommended by the team apart from implementing some

“kaizen blitzes” that would fetch immediately results. They have started to provide training on

customs regulations of Country S to the team members and have identified suitable people for

certification programs too. It is believed that the case organization is on the right track and in the due

course of time; the firm will achieve significant improvement in performance. However, it should be

remembered clearly that VSM is not a one time activity. Once the organisation has achieved the

performance reported in future state map, it needs to identify other improvement opportunities and

keep working towards the same for continuous improvement. Based on the results and the lessons

learnt, they can even attempt to re-engineer the other business processes or SDPs of other products.

One of the shortcomings of the current paper is that the entire implementation process was not

documented, as the case organisation has just started with the lean implementation and it is under

progress. Nevertheless, it is believed that this piece of work will provide the practitioners an

24
opportunity to understand the importance of VSM as a key tool in LSD. Furthermore, this research

can be extended by documenting the entire implementation efforts, difficulties faced, apart from

reporting the benefits obtained in the case organisation by comparing the “before lean” and “after

lean” scenarios or by comparing the actual performance with respect to the projected performance

listed in the future state map. Also when the conducted study is extended to other similar companies,

development of a generalized procedure for LSD can be identified as this study is specific to the

environment of the case organization selected.

Acknowledgements

One of the authors’ would like to thank the CEO of Company A for giving the permission to make use

of the data and company details in support of this study.

References

1. Alegría, J.A.H., Bastarrica, M.C. & Bergel, A. (2011). Analyzing software process models with

AVISPA. Proceedings of the ICSSP’2011. Available via:

http://www.bergel.eu/download/papers/Berg11a-icssp11.pdf. Accessed on 20 July 2011.

2. Anand, G. & Kodali R. (2011). Design of lean manufacturing systems using value stream

mapping with simulation - A case study. Journal of Manufacturing Technology and Management,

22(4), 444-473.

3. Bastarrica, M.C., Alegría, J.A.H. & Bergel, A. (2011). Toward lean development in formally

specified software processes. Proceedings of the 18th EuroSPI’11. Available via:

http://www.bergel.eu/download/papers/Berg11eLeanProcess.pdf. Accessed on 20 July 2011.

25
4. Bocock, L. and Martin, A. (2011). There’s something about lean: A case study. Proceedings of

the 2011 Agile Conference, 8–12 August, Salt Lake City, Utah, pp.10-19.

5. Cawley, O., Richardson, I. & Wang, X. (2011). Medical device software development - A

perspective from a lean manufacturing plant. In O'Connor, R.V., Rout, T., McCaffery, F. &

Dorling, A. (eds), Software process improvement and capability determination (84-96). Berlin:

Springer.

6. Corona, E. & Pani, FE. (2012). An investigation of approaches to set up a kanban board, and of

tools to manage it. In Niola, V., Kadoch, M. & Zemliak, A. (eds.) Recent researches in

communications, signals and information technology (53-58). Wisconsin, USA: World Scientific

and Engineering Academy and Society (WSEAS).

7. Curtis, B. (2011). Cutting IT costs by applying lean principles. White paper, available via:

http://www.castsoftware.com/castresources/materials/wp/leanapplicationmanagement.pdf

8. Dingsøyr, T, Nerur, S. Balijepally, V. & Moe, N.B. (2012). A decade of agile methodologies:

Towards explaining agile software development. Journal Systems and Software, 85(6), 1213–

1221.

9. Fisher, W.W., Barman, S. & Killingsworth, P.L. (2011). Value stream mapping for improving

academic advising, International Journal of Information and Operations Management Education,

4(1), 45-59.

10. Gustavsson, H. (2010). Improving the system architecting process through the use of Lean tools.

Proceedings of the Portland international centre for management and engineering technology

(PICMET) conference on technology management for global economic growth, 18-22 July,

Phuket, Thailand, pp.1-7.

11. Hibbs, C., Jewett, S. & Sullivan, M. (2009). The art of lean software development: a practical and

incremental approach, O’Reilly Media, Inc., California, USA.

26
12. Iberle, K. (2010). Lean system integration at Hewlett-Packard. Proceedings of the 28th annual

pacific northwest software quality conference, 18–19 October, Portland, Oregon, USA, pp.187-

204.

13. Ikonen, M., Kettunen, P., Oza, N. & Abrahamsson, P. (2010). Exploring the sources of waste in

kanban software development projects. Proceedings of the 36th EUROMICRO Conference on

Software Engineering and Advanced Applications (SEAA 2010), 1–3 September, Lille, France,

pp.376-384.

14. Ikonen, M., Pirinen, E. Fagerholm, F., et al. (2011). On the impact of kanban on software project

work: An empirical case study investigation. Proceedings of the 16th IEEE ICECCS

doi:10.1109/ICECCS.2011.37.

15. Kundu, G.K., Manohar, B.M. & Bairi, J. (2011). IT support service: identification and

categorisation of waste, International Journal of Value Chain Management, 5(1), 68-91.

16. Kuusela, R. & Koivuluoma, M. (2011). Lean transformation framework for software intensive

companies: responding to challenges created by the cloud. Proceedings of the 37th EUROMICRO

conference on software engineering and advanced applications (SEAA 2011), 30 August - 2

September, Oulu, Finland, pp.378-382.

17. Lian, Y.-H. & Van Landeghem, H. (2007). Analysing the effects of Lean manufacturing using a

value stream mapping-based simulation generator, International Journal of Production Research,

45(13), 3037-3058.

18. Lummus, R.R., Vokurka, R.J. & Rodeghiero, B. (2006). Improving quality through value stream

mapping: A case study of a physician's clinic. Total Quality Management & Business Excellence.

17(8), 1063-1075.

27
19. Malladi, S., Dominic, P.D.D. & Kamil, A. (2011). Lean principles in IT services: a case study on

implementation and best practices, International Journal of Business Information Systems, 8(3),

247-268.

20. Mandic, V., Oivo, M., Rodriguez, P., Kuvaja, P., Kaikkonen, H. & Turhan, B. (2010). What is

flowing in lean software development? In Abrahamsson, P. & Oza, N. (eds), Proceedings of the

1st International Conference on Lean Enterprise Software and Systems (LESS 2010), 17-20

October, Helsinki, Finland, pp.72-84.

21. Middleton, P. (2001). Lean software development: two case studies. Software Quality Journal, 9,

241–252.

22. Middleton, P. Flaxel, A. & Cookson, A. (2005). Lean software management case study:

Timberline Inc. In Baumeister, H., Marchesi, M. & Holcombe, M. (eds), Extreme programming

and agile processes in software engineering, 1st edn. Springer, Berlin: Springer.

23. Middleton, P. & Joyce, D. (2011). Lean software management: BBC Worldwide case study. IEEE

Transactions on Engineering Management, doi: 10.1109/TEM.2010.2081675.

24. Mishra, D. & Mishra, A. (2011). Complex software project development: Agile methods

adoption, Journal of Software Maintenance and Evolution: Research and Practice, 23(8), 549–

564.

25. Mohan, K.K., Harun, R.S., Srividya, A. & Verma, A.K. (2010). Quality framework for reliability

improvement in SAP netweaver business intelligence environment through lean software

development–a practical perspective, International Journal of Systems Assurance Engineering

And Management, 1(4), 316-323.

26. Mujtaba, S., Feldt, R. & Petersen, K. (2010). Waste and lead time reduction in a software product

customization process with value stream maps. Proceedings of the 21st ASWEC, doi:

10.1109/ASWEC.2010.37.

28
27. Musat, D. & Rodríguez, P. (2010). Value stream mapping integration in software product lines.

Proceedings of the 11th International Conference on Product Focused Software Development and

Process Improvement (PROFES 2010), 21-23 June, Limerick, Ireland, pp.110-111.

28. Norrmalm, T. (2011). Achieving lean software development: implementation of agile and lean

practices in a manufacturing-oriented organization, Thesis, available via:

http://www.utn.uu.se/sts/cms/filarea/1102_Thomas%20Norrmalm.pdf.

29. Ohno, T. (1988) The Toyota production system: Beyond large scale manufacturing, New York:

Productivity Press.

30. Paciarotti, C., Ciatteo, V. & Giacchetta, G. (2011). Value stream mapping implementation in the

third sector. Operations Management Research, doi: 10.1007/s12063-011-0052-8.

31. Petersen, K. (2012). A palette of lean indicators to detect waste in software maintenance: A case

study. In Aalst, W. Mylopoulos, J. Rosemann, M. Shaw, M.J. & Szyperski, C. (eds), Agile

processes in software engineering and extreme programming (108-122). Berlin: Springer.

32. Petersen, K. & Wohlin, C. (2010). Software process improvement through the lean measurement

(SPI-LEAM) method. Journal of Systems and Software 83(7), 1275-1287.

33. Petersen, K. & Wohlin, C. (2011). Measuring the flow in lean software development, Journal of

Software: Practice and Experience, 41(9), 975–996.

34. Poppendieck, M. (2007). Lean software development. Companion to the Proc. of the 29th ICSE,

doi:10.1109/ICSECOMPANION.2007.46.

35. Poppendieck, M. & Poppendieck, T. (2003). Lean software development: An agile toolkit,

Boston: Addison-Wesley.

36. Poppendieck, M. & Poppendieck, T. (2010). Leading lean software development: Results are not

the point, New Jersey: Addison-Wesley.

29
37. Poppendieck, M., Poppendieck, T. & Sutherland, J. (2006). Implementing lean software

development: From concept to cash, USA: Addison-Wesley Professional.

38. Raman, S. (1998). Lean software development: Is it feasible? Proceedings of the 17th IEEE Digit

Avionics System Conference, doi: 10.1109/DASC.1998.741480.

39. Rother, M. & Shook, J. (1999). Learning to see. Lean Enterprise Institute Inc., Massachusetts.

40. Rudolf, H. & Paulisch, F. (2010). Experience Report: Product Creation through Lean

Approaches. In Abrahamsson, P. and Oza, N. (eds), Proceedings of the 1st International

Conference on Lean Enterprise Software and Systems (LESS 2010), 17-20 October, Helsinki,

Finland, pp.104-110.

41. Staats, B.R., Brunner, D.J. & Upton, D.M. (2011). Lean principles, learning, and knowledge

work: Evidence from a software services provider. Journal of Operations Management, 29(5),

376-390.

42. Wang, X. & Conboy, K. (2011). Comparing apples with oranges? The perspectives of a lean

online community on the differences between agile and lean. Proceedings of the thirty second

international conference on information systems (ICIS 2011), 4-7 December, Shanghai, China,

available via:

http://ulir.ul.ie/bitstream/handle/10344/2138/2011_Wang%2c%20X.pdf?sequence=1.

43. Wang, X., Conboy, K. & Cawley, O. (2012). “Leagile” software development: An experience

report analysis of the application of lean approaches in agile software development, Journal of

Systems and Software, 85(6), 1287–1299.

44. Widman, J. Hua, S.Y. & Ross, S.C. (2010). Applying lean principles in software development

process – a case study. Issues in Information Systems, 9(1), 635-639.

30
 45. Womack, J.P. & Jones, D.T. (2003). Lean thinking: banish waste and create wealth in your

corporation, New York: Simon & Schuster.

31

View publication stats