Business Process Re-engineering through Lean Thinking A Case Study. Anand Gurumurthy. Assistant Professor

Business Process Re-engineering through Lean Thinking – A Case Study † Anand Gurumurthy Assistant Professor Quantitative Methods & Operations Manag...
Author: Giles Young
2 downloads 2 Views 403KB Size
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: [email protected] 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: [email protected] 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: [email protected] 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, teambased 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. Technofunctional 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 abovementioned 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 reverification 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.187204. 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. Approaches.

(2010). Experience Report: Product Creation through Lean

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

Suggest Documents