Agile Methodologies Selection Toolbox

Agile Methodologies Selection Toolbox .

E. Mnkandla, Member, IEEE, .B. Dwolatzky, Member, IEEE

Abstract—Agile methodologies have been in the software development scene for more than five years and this has resulted in the proliferation of a number of approaches to this new way of developing software. The initial agile problems were mainly focused on the definition of what agile methodologies are all about and empirical evidence of their successful application. Today one of the most formidable challenges is selecting appropriate agile processes for a given project and the next problem that some practitioners are already faced with is agile certification. This paper presents a selection tool that picks the agile practices relevant to a given environment. The activities that relate to each practice are used to classify the practices into either technical or social. The authors believe that all practices can be classified into technical and social oriented activities. The technical practices are those that relate to design coding and testing and the social practices relate to people issues. The practices are analyzed to this detail in order to simplify the tailoring process. In this case the environment is then viewed from the perspective of technical and social issues and it becomes easier to identify possible things that could be done to tailor the agile practices. The tool is a simple application that can be used with other project planning tools on any PC. This is part of further work based on one of the authors’ PhD work. The additions include the development of a computer program to implement the tool. Index Terms—Agile methodologies, methodology selection, practice tuning.

agile

practices,

I. INTRODUCTION

T

HE choice of appropriate methodologies for given software development projects has always been a challenge. This paper presents a tool that can simplify the selection process of the most appropriate agile method for a given project. It starts by classifying projects in order to determine the suitability of using agile methodologies in a given project. The set of parameters used to classify software projects is based on a combination of existing project taxonomy techniques and results of surveys reported fully in [1]. The second stage of the framework selects the appropriate set of practices. There are two steps in this stage: in the first step agile methodologies are represented using a set of parameters (as defined in [1]) and against each parameter the

• E. Mnkandla is with the School of Information Technology, Monash University, Johannesburg, 1725, South Africa, phone. +27 11 950 4038, fax: +27 11 950 4033. Email: [email protected] • B. Dwolatzky is with the School of Electrical and Information Engineering, University of the Witwatersrand, Wits, 2050 Johannesburg, South Africa. E-mail: [email protected].

customer’s corresponding values and priorities are mapped. In step two of stage two, practices that can be implemented to meet the requirements (as expressed in terms of values and priorities) are selected from the methodologies. The set of parameters used for the methodology selection process is based on a combination of the methodology selection techniques found in [2, 3, and 4]. The third stage assumes that agile methodology practices have been selected and provides the details of how to tune them to the given project’s environment. The reason for developing a new model for this purpose is based on the realization from published literature [5] that many agile methodologies do not specify how tailoring to different environments can be done and are therefore based on what Abrahamsson et al [5] calls abstract principles. To correct the problem caused by abstract principles a computer-based tool has been developed some of the screen dumps are shown on figures 2 to 4. II.

BACKGROUND

Existing methodology selection and classification techniques described in the available literature are general and the choice of methodology elements though subjective gives the user a philosophical understanding of the methodologies, see; [3, 4, 6, 7, 8, 9, and 10] for such frameworks. The understanding gained from the use of such approaches could be useful for teaching and research on methodologies. However, most of these frameworks are just documents that provide guidelines in the selection process. The challenge is to automate the selection process so that the professionals simply enter some information about the project and get an indication of the most appropriate methodology for that project. III. A SELECTION TOOL FOR AGILE PROCESSES This section presents a full description of a tool for the selection of the most suitable agile methodology practices in a given project. The contributions of this tool to agile technologies are; 1) the provision of detailed knowledge about the profiling of agile practices, 2) provision of an automated tool for selection of agile practices. The philosophy of the framework is to view software development processes as phenomena that are made up of two groups of activities namely; social activities and technical activities. The departure point of the framework is then to consider customer values and priorities in a given project and tune the selected practices accordingly. So according to the generic principles of agile development the customer is at the

center of the development team hence this principle is not violated in this tool. The idea of a simplified twofold view of development activities –social and technical makes it easier for the development team to tune the selected practices into this dual perspective of the project environment. The following statements summarize these concepts: • All activities should be driven by what the customer values and prioritizes in a given project. • All practices should be classified into social practices, and technical practices. A. Architecture of the Tool The selection framework is represented by the schematic diagram shown in Figure 1. The methodology selection process itself is composed of three stages the first two of which are designed based on the concept of selection matrixes. The first phase of the tool confirms the relevance of agile development in a project and can be omitted if there is no need for the confirmation. The second phase’s major output is a set of agile practices from various agile methodologies. These practices serve as input to the third phase where they are classified into social and technical and then tuned to the given

Project Representation Matrix

Methodology Selection Matrix

Select agile Practices

GAM Model, Tune the Practices

The set of parameters used to analyze a project are: Project Size, Risk, Timeframe, Complexity, Criticality, Scope,

Some of the parameters used to analyze each methodology are: Philosophy, Product, Usage base, Process, Output, Team Size, etc.

Choose the relevant practices from the selected group of methodologies

Profile the practices into technical and social and then tune the selected practices to the project environment

Fig. 1. The selection process starts by classifying the project followed by selection of the agile relevant method and in the last phase called the Generic Agile Methodologies (GAM) Model profiling the practices is done to simplify the tuning [1].

environment. Tables 1 and 2 show the selection matrixes. The detail details are explained in the next section. B. Design of the Tool The first stage deals with the classification of the software development projects and leads to the choice of the generic group of methodologies that would be suitable for the class of project. The underlying principle according to Glass and Vessey [11] and [12] is that in order to be able to determine the appropriate process or methodology for a project the project must be understand first, hence the need to classify the

project. To that effect the first stage of this tool presents a matrix that can be used to classify projects in order to determine the suitability of using agile methodologies for a given project. Project taxonomies have been done as reported TABLE I. METHODOLOGY SELECTION MATRIX [1]

Project Parameters Requirements Stability Project Size

Rating 0 to 5

Methodology Choice

Development Timeframe Project Complexity Project Risk

in [11 and 12] however, they used using different approaches and this approach is more relevant for this purpose. The tool asks the user to enter the values as shown in Table 1. The value and the parameters are explained in the following paragraphs. Requirements stability: 0 means very unstable requirements with a high risk of scope creep. The level of stability increases to a rating of 5 representing very stable requirements where scope creep is minimal. The smaller the rating the more relevant agility is to the project. Project size: 0 represents a project team with two to ten people and 5 represents more than hundred people. The relevance of agility decreases as the rating increases. Development timeframe: 0 represents a time from one week to two months. Any development timeframe beyond two years would have a rating of 5. The shorter the development timeframe the more relevant agility is to the project. Complexity: 0 represents those projects not characterized by heavy calculations under high change, high speed, and uncertainty. The complexity increases as the rating increases to 5, which would represent critical projects such as spacecraft or nuclear control software. Agile methodologies would be less applicable as the complexity increases [4, 13] Project risk: 0 represents high–risk projects and as the risk decreases the rating increases to 5, which would represent very low risk projects.

IV. TOOL VALIDATION

TABLE II. PROJECT TAXONOMY MATRIX [1]

Parameters Methodology Philosophy Methodology Process Methodology Techniques and Tools Methodology Scope Methodology Outputs Adoption and Experience Methodology Product Roles and Responsibilities Support for Distributed Teams

XP

Crystal

Scrum

The second stage applies the methodology representation approaches described in [2, 3, and 4] to classify agile methodologies in order to select a set of relevant agile practices. A selection matrix (developed by the author) is used for this purpose. Combining the three cited approaches in order to select the most relevant agile methodologies so that the appropriate agile practices are selected is new. The selection matrix is composed of one methodology for each column. The matrix is not exhaustive as some partial methodologies (for example Agile Testing (AT)) are not included. The reason is that it would be difficult to analyze such methodologies using the suggested set of methodology parameters. In this matrix each methodology element occupies a single row. Table 2 lists the agile methodologies and analyses each methodology according to the nine methodology parameters in order to determine the relevance of each parameter to the project at hand. This is done by mapping the parameters to the customer values and priorities and hence identifying the agile practices that could be done to meet the requirements of the project. Once the list of the most relevant practices is obtained the reality of tuning the practices sets-in as there could be some conflicts between what the customer values and practice. For example the customer could value that the teams work from different geographical areas (distributed development) probably due to outsourcing yet the conflicting practice could be pair programming or scrum meetings. The next solves these problems through tuning the practices. The third stage assumes that agile methodology practices have been selected and provides the details of how to tune them to the given project’s environment. The third stage consists of three phases: phase one identifies practices that relate to people issues, phase two identifies practices that relate to technical issues, and phase three outlines the practical tuning steps. Figures 2 to 4 show some of the screen dumps for the automated tool.

Full validation of the tool is still to be done for the automated version. However the text version of the tool was validated by giving it to a software developer organization that used it in some of their past projects and found interesting results [1]. To respond to each phase of the tool the following questions were asked: • Using past or present software development project data list the most important requirements and priorities and values. This was focused on getting an understanding of customer values and priorities for the project. • In stage one of the tool (framework process diagram and matrix tables presented) use your information to determine the suitability of agile development in the project. The aim was to determine the relevance of using agile development in this project. The user’s response was that this stage of the tool was quite useful in decision making, but felt that additional factors such as commercial constraints could be included. • Did the use of the project taxonomy matrix improve your understanding of the project with regard to process issues? The aim was to evaluate the contribution of the tool to the understanding and use of agile methodologies. • In stage two of the tool, assume that the previous stage indicated applicability of agile development. Apply the methodology selection matrix and select the set of practices that are relevant to your project. Did the use of the methodology selection matrix improve your understanding of the set of activities expected in your project? The aim of this question is to evaluate the framework’s contribution to knowledge. The user found the selection stage to be helpful in making explicit the relevance of an approach in a particular context. • Go to stage three of the framework and classify the practices into social and technical. Consider what needs to be changed in each practice in order for it to be practically usable in your project environment. In applying this stage the user found the idea of profiling the practices quite informative in terms of how each practice can be used in a given environment. • Given the opportunity would you use this framework in planning your next software development project? The answer to this was yes. • Would you recommend the use of this framework to other IT professionals? Again the answer to this was yes. • Comment on any notable limitations of the framework. Some of the recommendations resulting from the last question were: 1. Presentation of the framework and ease of use could

2. 3.

be improved Consider more fine grain determinants of project description Make the practices themselves the target of choice (rather than methodology) V. CONCLUSION

The paper summarized a computer-based tool for the selection of the most appropriate agile methodology practices in a given project. The tool is aimed at the initial stages of project planning where the relevance of the type methodology and the kind of practices that could be applicable to the project would be discussed. The use of such a tool would simplify the methodology selection process. There are possibilities of extending the tool for use with methodologies that may not be agile. REFERENCES [1] Mnkandla, E., A Selection Framework For Agile Methodology Practices: A Family of Methodologies Approach, PhD Thesis, University of the Witwatersrand, Johannesburg, South Africa, 2006. [2] Avison, D.E. and Fitzgerald, G., Information Systems Development: Methodologies Techniques and Tools. McGraw–Hill, 1995. [3] Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J, Agile Software Development Methods: Review and Analysis, VVT Publications, No. 478, 2002, pp. 7–94. [4] Boehm, B. and Turner, R., Balancing Agility and Discipline: A guide for the perplexed, Addison–Wesley, USA, first edition, Appendix A, 2004, pp. 165–194. [5] Abrahamsson, P., Warsta, J., Siponen, M.T., and Ronkainen, J. New Directions on Agile Methods: A Comparative Analysis, Proceedings of the 25th International Conference on Software Engineering (ICSE’03), 2003. [6] Avison, D.E. and Wood–Harper, A.T., Multiview, An exploration in information systems development, Blackwell Scientific Publications, Oxford, 1990. [7] Fitzgerald, B., Formalized Systems Development Methodologies: a critical perspective, Information Systems Journal, Vol. 6, 1996, pp.3–23. [8] Iivari, J., Hirschheim, R. and Klein, H.K., Beyond Methodologies: Keeping up with Information Systems Development Approaches through Dynamic Classification, IEEE, Proceedings of the 32nd Hawaii International Conference on System Sciences, 1999. [9] Osterweil, L.J. and Song, X., Toward Objective Systematic Design– method Comparisons, IEEE Proceedings of IWSSD–8, 1996, pp. 170– 171. [10] Song, X. and Osterweil, L.J., Comparing Design Methodologies Through Process Modeling, IEEE Software, 1992, pp. 29–44. [11] Glass, R.L. and Vessey, I., Contemporary Application Domain Taxonomies, IEEE Software, 1995, pp. 63–76. [12] Sol, H.G., A Feature Analysis of Information Systems Design Methodologies: Methodological considerations, Proceedings of the IFIP WG8.1 Working Conference on Feature Analysis of Information Systems Design Methodologies. In Olle, T.W., Sol, H.G., and Tully, C.J., (eds.). Information Systems Design Methodologies: A Feature Analysis. Amsterdam, Elsevier, 1983, pp. 1–7. [13] Highsmith, J., Agile Software Development Ecosystems, Addison– Wesley, 2002, pp. 1–50.

VI.

APPENDIX A SCREEN DUMPS OF THE TOOLBOX

Fig. 2. Screen dump of the main menu for the agile methodology toolbox

Fig. 3. Entering the values in these textboxes will give an indication of the relevance a\of agile development to the project.

Fig. 4. Selecting the practices.