Content uploaded by Gopalakrishnan Narayanamurthy
Author content
All content in this area was uploaded by Gopalakrishnan Narayanamurthy on Aug 26, 2015
Content may be subject to copyright.
1
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
2
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).
3
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
4
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
5
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
6
(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
7
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
8
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
9
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
10
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
11
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.
12
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
13
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
14
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
15
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
16
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.
17
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
18
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.
19
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”.
20
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.
21
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.
22
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
23
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.
24
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
25
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.
26
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.
27
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.
28
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.
29
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.
30
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.
31
45. Womack, J.P. & Jones, D.T. (2003). Lean thinking: banish waste and create wealth in your
corporation, New York: Simon & Schuster.
