Enhanced Agile Software Development – Hybrid ... - IEEE Xplore

Second International Conference on Industrial and Information Systems, ICIIS 2007, 8 – 11 August 2007, Sri Lanka

Enhanced Agile Software Development – Hybrid Paradigm with LEAN Practice 1,2

G.I.U.S. Perera1, M.S.D. Fernando2 Department of Computer Science and Engineering, Faculty of Engineering, University of Moratuwa, Sri Lanka [email protected], [email protected] certain process model to be improved [4]. In this research we identified the KPAs in both agile and LEAN practices. Then we examined the overlapping areas in between these two process paradigms and focused on the other process areas for the improvements. In that one main objective we identified was that injecting Key Success Factors (KSF) of LEAN method will improve the agile practice of software development which can be easily utilized without putting much effort to normal agile practice in sustainable manner. The organization of this paper is as follows. In section II we will discuss the background literature in related with this study. In section III we discuss the identified problem in brief. Thereafter the section IV is included with the experiment methodology. Even though the results section (V) does not contain any numerical figures of the results it describes the importance of the selected result parameters to preserve the clarity of the paper. Section VI, the analysis section explains the analysis done based on the collected results from this study which strongly facilitates the conclusion of this study. Future works and conclusion sections are thereafter along with the acknowledgements. The references will compile the paper.

Abstract – In recent years the interest on improving software paradigms to meet the rapid changing environments has become a prime research area in Software Engineering. Agile software development emerged as a result of these studies. Agile practice is a customer oriented, light-weight software development paradigm, best suited for small size development teams in projects under vague and changing requirements. Parallel to this, LEAN manufacturing introduced a massive paradigm shift to production processes in different industries. Later, the LEAN software development, a derived process from LEAN manufacturing emerged. Despite its main focus on defect minimization, it was considered another facet of agile practice due to the flexibility offered by both. In this study we emphasize the key differences between the two practices and examine the possible improvements to the agile software development from LEAN principles that ultimately leads to a hybrid practice.

I

INTRODUCTION

The role of information technology and associated IT workforce is becoming more significant in organizations as information becomes one of the key resources for any activity. The development of the software and computing technologies has changed the world’s operations to a large scale. However, software applications are complex and intangible products which are difficult to manage. Hence Software Lifecycle management becomes one of the key research areas in software engineering. Due to the nature of the software, software researchers and practitioners are focused on improving the software processes which are used to develop software. The underline assumption is that there is a direct correlation between the quality of the process and the quality of the developed software [1]. A software process can be considered as a set of tools, methods, and practices we use to produce a software product [2]. These are the prime parameters that differentiate the process based software development from ad-hoc programming. Despite from the practicing process, an organization can have a certain levels defined in the Capability Maturity Model/ Capability Maturity Model Integration (CMM/CMMI) by the Software Engineering Institute (SEI)[3]. It focuses on Key Process Areas (KPA) which can be improved in any process practice. KPAs can vary slightly among process models, however they should address the critical segments of the practicing process. Identifying KPAs is one of main consideration when a

II

BACKGROUND

As described early, this study is to evaluate the successfulness of the enhanced agile software development by introducing LEAN practices. For that the most important task is to identify the improvable areas in agile practices, as well as the applicable techniques from the LEAN methods. To strengthen the study we referred large number of literature on agile process, LEAN practice and related areas. Following is a comprehensive synopsis of the literature we used for this study. A Agile Software Development “Agile Methods are a reaction to traditional ways of developing software and acknowledge the need for an alternative to documentation driven, heavyweight software development processes” [5]. In most of the traditional software processes, there are heaps of documents when the project finishes. Most of those are useless at later stages since the requirements were changed several times throughout the project. This was the critical factor for inventing the agile paradigm. By the nature of this paradigm it also provides some other benefits like, flexible

1-4244-1152-1/07/$25.00 ©2007 IEEE. 239

Second International Conference on Industrial and Information Systems, ICIIS 2007, 8 – 11 August 2007, Sri Lanka

project management, cost effective adaptability, increase communication and ultimately increased customer satisfaction. There are many principles behind the agile practice. Some of them are based on behavioral and managerial improvements to the software development [6]. Furthermore, the most obvious difference between plandriven life-cycle models and agile development is that agile models are less document oriented and place more emphasis on code development [7]. The development process is flexible and agile practitioners believe for different projects, different approaches and process models have to be used. Agile process welcomes frequent requirement changes even at late stages of the project. With frequent deliverables, agile process measures its progress through the norm of working software [8].

C LEAN Software Development In early 1990s software professionals tried to adopt the LEAN production principles to software development. However, the objectives were mainly targeted to defect minimization of the product. In this context LEAN Software Development identified the correspondent software wastes to the seven wastes defined in the LEAN manufacturing process. It is shown in the Table 1. [12] TABLE 1 Corresponding Software wastes to the manufacturing wastes identified in LEAN software development

B LEAN practice LEAN practice was developed in Japanese automobile production companies. This is also known as Toyota Production System. Taiichi Ohno considered as the farter of this practice [9]. Once confined to the automotive industry, lean principles are becoming standard operating procedure in many industries today. Simple reason for that is when implemented with a good performance management system, lean principles have a proven track record of operational and strategic success, which ultimately translates into increased value to the end customer. Specify value, identify all the steps in the value stream, flow smoothly, pull value, and pursue perfection are the five principles in LEAN practice [10] Figure 1 shows these principles. Throughout the LEAN practice it targets to reduce the unnecessary overhead activities and outputs as well as wastes from the production line. With this prime norm LEAN method only activates necessary activities at the latest time they could be performed with minimal/zero defects. LEAN practice is composite with unique methodologies to perform the operational activities. Kanban (Pull) production system is one important method. In that method, throughout the production lines you can schedule the process efficiently, and activities flow using signaling to each others related to the workflow. In 1953 Toyota applied this logic in their main plant machine shop [11].

Manufacturing Waste

Software Waste

Overproduction

Extra Features

Inventory

Requirements

Extra Processing Steps

Extra steps

Motion

Finding Information

Defects

Defects not caught by Tests

Waiting

Waiting, Including Customers

Transportation

Handoffs

III

PROBLEM

Having discussed about the characteristics of the two processes, we are about to formulate the research problem for this study. The problem is based on obstacles of agile practice. There are many criticisms for agile software process even it address many problems with classical software processes. Heavy reliance on project team members with expert knowledge is the major issue with agile practice [13]. Another major concern with agile development is project management. This involves decision making, resource management, achieving progress, etc. For agile practices there isn’t any defined systematic project management approach. As the name suggests all the activities are agile and flexible hence have high vulnerability to become chaotic if not properly handled. In terms of scalability agile practices are usually applied to projects with smaller teams of ten or fewer people [14]. Another fact is that even though the agile process focuses and highlights the out come of the project to the best form, it does not provide necessary well defined activity framework to get that achieved. It enjoys a situational approach for the project progress, which in some point of view, becomes the main bottleneck for the optimization of the process practice. On the other hand if we consider the LEAN practices, it again cannot be taken as a complete process model for the software development. The main reason for that is, it only provide the behavioral approach for a project success. Specially, it focused on waste minimization and quality improvements [15]. which may not cover the entire software process with both technical parts and managerial parts.

Fig. 1 LEAN Principles for success

240

Second International Conference on Industrial and Information Systems, ICIIS 2007, 8 – 11 August 2007, Sri Lanka

IV

METHODOLOGY

above nor below to the required scopes. Also since we are considering only a time interval in the middle of the projects, entire project loads or work amount will not affect to the study. Another simple but worth to mention problem was the accuracy of the collected data. Truncation errors may affect to the data sample specially when considering human hours. However, since this is a comparison of two samples and those errors are common to both samples, the affect will nullify.

The research data collection is based on actual monitoring of the selected agile projects. In order to preserve the fairness between experiment samples as much as possible, we used the final year student project of the department of Computer Science and Engineering. Ten projects were selected to with four group members per each project. All of these projects were started from the same date and having same resource for their project works. Among the ten projects five were taken as the control sample where those projects are done using the normal agile practice. The other five projects were the experiment sample in which the enhanced agile practice with LEAN method is used as their process model.

V

RESULTS

One important obstacle that faced when deciding what types of measures to be taken was that identifying most suitable performance measures to track the project enhancements and the progress in this context. LEAN practices with production systems have their own performance parameters and their matrixes. However, since this is a study of evaluating certain improved software process activities, we had to focus on performance parameters and matrixes which are defined for the software lifecycle monitoring.

A Research Hypothesis Considered research hypothesis for this study is as follows. Null Hypothesis: Agile software process’s development phase cannot be improved using LEAN practice techniques. Alternative Hypothesis: Agile software process’s development can be improved using LEAN practice techniques. In order to evaluate this hypothesis we selected the statistical analysis of colleted data with reasonable amount of sample size.

A Measurement Parameters Table 2 shows selected parameters for the performance measures. These data are collecting for each week of the projects and per project basis. One important fact to mention here is that we divided the Lines Of Codes (LOC) parameter to three parts as New LOC, Changed LOC, and Removed LOC. If only total LOC is measured, changes to where the LOC comes from may go undetected. These changes may reflect significant differences in the effort and schedule required to complete the project [16].

B Experiment Method As mentioned in the problem section this study aimed to examine the success of applying LEAN practices to improve the agile method. For all selected projects we gave required level of competency on practicing agile process. We used hands on labs, knowledge sharing sessions to make all the 40 students at a reasonable and similar competency level for this experiment. Then we separated the five groups, who are practicing hybrid agile process, and deliver the required knowledge on LEAN practicing with the selected LEAN techniques to practice along with agile development.

TABLE 2 Project parameters and their results; collecting data Amount

C Experimental Limitations This research experiment is also suffered from one of the main concerns with agile process, the people factor. Altogether there are 40 software developers used for this experiment. Among these 40 participants, there can be slight different competencies from each other for performing the software lifecycle activities. However, we think that since their average exposure to the software development, technical knowledge and resources, this may be the best set of samples that one could find for this kind of experiment. If we select the sample from industry, it would have been a collection with higher variance value for people capabilities. Another problem we faced was that all these ten projects are for ten different domains. However the project scopes were examined by a panel of expert scholars at the beginning and ensured that none of the projects are neither

Work level

New LOC

X

X Human hours

Changed LOC

””

””

Removed LOC

””

””

Defects fixed

””

””

Expected work

----

””

Actual work

----

””

The number of defects fixed is important to understand the difference between the two paradigms in the context of quality enhancements to the developed applications. It is expected to have higher number of defect fixation rate for the hybrid method over the general agile practice during the first couple of time periods. Expected work and actual work levels are taken to identify the facilitating levels of the two examined process models for achieving the project objectives related to its schedule. All these performance attributes are measured as a count during the examined time period along with their respective work amount in human hours. This human hours measure is

241

Second International Conference on Industrial and Information Systems, ICIIS 2007, 8 – 11 August 2007, Sri Lanka

very important to identify the different work load portions with respect to selected parameters in the conventional agile and the improved hybrid agile model. VI

C Defects rate behavior Apart from the hypothesis testing, we also analyzed the defect fixing rate for the two samples through the examined time period. A defect was classified as an unexpected or erroneous behavior of a selected piece of module or component which has been already compiled successfully and committed to the project. With that respect, compilation errors of the code were not considered as defects.

ANALYSIS

Statistical techniques have been used to perform the hypothesis tests based on the collected data. First we have identified the relevant factors to be used to get the summation of the LOC value from new LOC, changed LOC and removed LOC values. This weighted sum was found in per group per week basis. Considering the human work hours spent on each category and the usefulness to the final code we have decided to have 3 weights as follows. w1 = 1 for New LOC, w2 = -0.5 for changed LOC, and w3 = -1 for removed LOC. With these weights we found the weighted sums of 50 values per group in the two groups referred hereafter as A- Normal Agile practiced group and B- Improved Agile practiced group.

Average Defects

5

3

Lean - Agile Normal Agile

2 1 0 1

2

3

4

5

6

7

8

9 10

Weeks

A Hypothesis Test – Using LOC As the statistical analysis we used ANOVA method to test the hypothesis using the LOC values. In that test, for Group A we found the mean µA = 399.9 and the standard deviation σA = 233.0. For the Group B we found the mean µB = 573.8 and the standard deviation σB = 305.6. From the average LOC values it is clear that improved agile practice capable of producing more LOC than the normal agile practice. With the ANOVA test we observed the p-value as 0.002 for the groups A and B. i.e. p < 0.05 and therefore we reject the Null hypothesis (H0) with 95% confidence level which implies that the Agile process development phase activities can be improved by applying LEAN practices.

Fig. 2 Average defects rates in the time period for the two samples

A significant defects rate pattern difference between the two samples was observed during the experiment time as shown in Fig.2. A higher rate for LEAN-Agile sample at the early stages of development was due to that their autonomous and value perfection norms with the development. On the other hand the normal Agile group did not found much defects at the early stages, since they did not pay much attention to the perfection of what they develop, while they doing it. At the later stages this situation swapped between the two samples and LEANAgile practice seems to have a stable minimal defect rate, where as the normal agile practice experienced a high and varying defects rate. A possible reason to that is unfixed hidden defects in components from early developments would cause emerging defects once they integrated each other. Importantly having lesser defects in later stages is very essential for the stability of the project and to be aligned with the project schedule. Also defects emerge in later stages are relatively expensive to fix. However the average defect rate per week for two samples were similar as µA = 2.2, and µB = 1.92. If we extended the study further then this would have change since the group A is getting further defects with their trend. Based on the available information we can conclude that applying LEAN principles help stabilize the Agile development phase especially in later stages of the phase.

B Hypothesis Test – Using work levels Again with considering the expected work level and the actual work level per week, we did the hypothesis test using the ANOVA method. For that we used a derivation from the data (1), to identify the divergence ratio to the expected work level which as in. ( Actual work level - Expected work level) Expected work level

4

(1)

Similar to earlier case, we had two samples of data with 50 items per sample. With this test we found µA = 21.40%, σA = 8.82%, and µB =-16.21%, σB = 11.99%. According to the used formula, the higher mean value is better than the other since the deviation from expected work level is lesser. With the ANOVA test we got the pvalue as 0.016; i.e. p< 0.05 and therefore we reject the Null hypothesis (H0) with 95% confidence level based on achieving the expected work level per given time period. This implies that the Agile process development phase can be improved by applying LEAN practices.

VII

FUTURE WORKS

Despite from the identified information from this research, there are some possible future studies relevant to this research. This study has selected LEAN practice for applying its principles to improve the agile process. The experiment mainly focused on the application development phase of the project life cycle. There are other important life cycle phases in the agile software paradigm like Requirement Engineering, System Design, System

242

Second International Conference on Industrial and Information Systems, ICIIS 2007, 8 – 11 August 2007, Sri Lanka

Implementation, etc. which have to be examined for similar kind of improvements through the LEAN practice. Also there are some software projects which the Agile process is not the best paradigm to be used. However, with the application of LEAN techniques, it may be possible to use improved paradigm for such projects. This should be studied properly; yet another future research area relate to this study. VIII

[8]

[9]

[10]

CONCLUSION

[11]

In this research we tried to identify possible improvable parts in the agile software development process and how the LEAN development practice could be used to overcome those. Then we examined those possible improvements and analyzed the collected data. Statistically we have seen that our argument of LEAN principles can be used to improve the Agile paradigm, is correct. Moreover since the objective of this study was not to invent any new software development paradigm but to improve the agile method, it is justifiable to say that the new hybrid paradigm can use without putting much additional effort and cost to the normal agile practice based on our observations in this study. Importantly another vital factor of this research is that even though it deals with two similar software process models, the enhanced hybrid agile practice does not contain any redundant process activities, which may be visible with both agile practice and the LEAN practice. With all this regard we believe that, this study will create a significant paradigm shift to the Agile software development process.

[12]

[13]

[14]

[15]

[16]

ACKNOWLEDGMENT We would like to thank to the final year students of the Department of Computer Science and Engineering, University of Moratuwa, for their support to this research by allowing their projects to consider as the test samples. Also the University of Moratuwa, E-Learning project development team for their support to make this research a success. REFERENCES [1]

[2] [3]

[4] [5]

[6]

[7]

A. Fuggetta, Software process: a roadmap, Proceedings of the conference on The future of Software engineering, ICSE, Limerick, 2000, p.25-34, W. S. Humphrey, Managing the Software Process, SEI, Pearson Education, India, 2006, pp.03 Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process, Carnegie Mellon University, 1998, pp. 15 R. Fatina, Practical Software Process Improvement, Artech House, Boston, 2005, pp. 6 D. Cohen, M. Lindvall, P. Costa, A State of the Art Report: Agile Software Development, Data and Analysis Center for Software 775 Daedalian Dr. Rome, New York 13441- 4909, 2003, p 1 G.I.U.S. Perera, M.S.D. Fernando, Bridging the gap – Business and information systems: A roadmap, in proceedings of 4th ICBM conference, 2007, pp. 334-343 A. Dagnino, An evolutionary life-cycle model with agile practices for software development at ABB. Proceedings on 8th IEEE

243

Conference on Engineering of Complex Computer Systems (ICECCS’02),2002, pp. 215–223 K. Beck, et. al., Manifesto for agile software development, 2001, available at http://agilemanifesto.org/, [accessed on 07th December 2006] Wikipedia®, Taiichi Ohno, available at http://en.wikipedia.org/wiki/Taiichi_Ohno, [accessed on 03rd March 2007] J. P. Womack, D. T. Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation 1st Ed., Simon & Schuster, USA, 1996 T. Ohno, Toyota production system, Beyond large scale production, productivity press, 1988, pp. 25-29 M. Poppendieck, Principles of LEAN thinking, Onward - 17th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, Washington 2002, pp.78 M. Lindvall, V. Basili, B. Boehm, P. Costa, K. Dangle, F. Shull, R. Tesoriero, L. Williams, M. Zelkowitz, Empirical findings in agile methods, in proceedings of Extreme Programming and Agile methods,2002, pp. 197-207 F.P. Deek, J.A.M. McHugh, O.M. Eljabiri, Strategic Software Engineering an Interdisciplinary Approach, Auerbach Publications, FL, 2005, pp. 94 Poppendieck.LLC, Lean software development, available at http://www.poppendieck.com/overview.htm, [accessed on 12th October 2006] J. A. Rozum, Defining and understanding software measurement data, Software Engineering Institute, 1991