Framework for Agile Methods Classi¯cation

Abstract

Agile methods are the response to turbulent software development environments and requirements de¯nitions di®ers in these methods from what is done in others. The purpose of this paper is to classify these former methods to measure their impact on requirement engineering processes. The approach used in this research has several purposes, the ¯rst one is to build a framework to classify and compare the methods. The second is to propose a component based approach to bring agility to other methods.

Keywords

• Agile methods
• Method engineering

Introduction

In the mid 90's people start creating new methods because industrial requirements and technologies are moving fast and customers were unable to de¯ne they needs in early stages of the projects [ 1, 2 ]. These new methods, called the agile methods are designed to respond to disruptive software environments where requirements are constantly changing.

Requirements in agile methods are quite di®erent from what is done in classical plan-driven methodologies. In the latter, requirements are elicited at the beginning of the project and suppose to remain the same all along the project[ 3 ], whereas in the former, requirements changed constantly. As long as the project is going on, the requirements de¯nition is detailed. They become more and more precise at each iteration and changes are integrated through the process. So as part of an agile process the requirements de¯nition is iterative and incremental.

The scope of this paper is to classify agile methods to compare them and evaluate their impact on requirement engineering processes. A framework is proposed in section 2 and applied to eight agile methods in section 3 for classify them. Finally an approach of agile methods reusable components will be proposed in section 4. 2.1 each one representing an aspect of the methodologies. Each view is characterized by a set of attributes.

As shown in Figure 1, the four views are the decomposition of an agile method. They capture why and when using agility. In other terms what are bene¯ts to objectives brought by the method agility and what's the favourable environment to its application. These aspects are correlated to what is the method agility and how this agility is expressed in practice. This means what are the parts of agility concept supported by method guidelines and rules to satisfy objectives mentioned below. Added to how these rules are derived in activities and products. 2.2

Usage View

This view captures why using the agile method. The attributes of the view aim to evaluate all the bene¯ts that the development team and the customer can gain by applying the method.

According to the quantitative approach used in [ 6 ], applying agile methods can increase a productivity, quality and satisfaction. The methods can provide guidelines to increase bene¯ts such as productivity gain, end user satisfaction and quality level respect attributes of the usage view.

Behind the agility concept some aspects can be identi¯ed as the integration of changes in the development process. So agile methods are providing rules and guidelines to ¯t turbulent environments and providing the respect of requirements and delivery dates in such environments. These three last aspects will be integrated in this view as attributes.

A study on the limitations of agile methods [ 7 ] points out that they provide a limited support to subcontracting, agile methods can bring some °exibility to outsourcing contracts. De¯ning contracts in two parts, a static one and a variable one creates this °exibility. So let's carry our interest if some agile rules can be favourable to o® shoring by integrating the favourable to o® shoring attribute in this view.

The attributes of the usage view are : Adapted to turbulent environments : BOOLEAN.

End user satisfaction : BOOLEAN.

Favourable to o® shoring : BOOLEAN.

Productivity gain : BOOLEAN.

Respect of a quality level : BOOLEAN.

Respect of delivering dates : BOOLEAN.

Respect of the requirements : BOOLEAN. 2.3

Capability to Agility View

The capability to agility view represents what is the part of agility in the method, how agile is the method. The attributes of this view will represent all aspects of the agility concept and their valuation will re°ect what are the aspects included in the method.

A software development method is composed by a life cycle, speci¯cs concepts about the development itself and the organization of the people around the method. Let's start with the ¯rst one, the life cycle. In software engineering various life cycle models exits, for example V model [ 8 ], waterfall model [ 9 ] or spiral model [ 10 ]. According to the chronology of agile methods apparition related in [ 11 ], most of these methods are directly derived from spiral model. This is explained by the two main characteristics of the spiral life cycle, an iterative and incremental behaviour. Such life cycle provide a development of the software increment by increment. So environmental and requirements changes can be integrated to every iteration of the process and the work plan would not be ¯xed, it will change through iterations. Another point of interest of this behaviour is the length of iterations. Shorter iterations will increase the number of meetings with the customer to de¯ne and detail their needs incrementally bringing reactivity to the method. From observations, six attributes can be identi¯ed : short iterations, reactivity, integration of the changes, changes of the functional requirements, changes of the non functional requirements, change of the work plan.

Concerning the organization of people, agile methods tend to break contractual relations between customers and development teams [ 12 ]. This relation will be expressed in this view by the collaborative attribute. The organization aspect also concerns human relations into the development team. An agile team is a kind of holographic organization where each member has the knowledge of the whole system [ 3 ]. So if a member left the team no knowledge is lost. Furthermore people are in the central place of the method and some decisional power is delegated to development teams. These last two aspects are declined in the view by the people centred, human resources can change and knowledge sharing attributes.

Some speci¯c concepts of agility are included by the agile method in activities of software development itself. The major concept is light weight of the process. This concept is expressed in the agile manifesto [ 1 ] and the ¯rst name of agile methods was light weight methods. Globally, agile methods include less documentation and modeling tasks than plan-driven approaches. Two other concepts concern the code testing and refactoring. Testing is a strong practice of agility, tests grant you that the software you are developing corresponds to the customer requirements and that your code is not regressing by the introduction of errors in functionalities previously done. The non regression aspect goes hand in hand with the refactoring one which you are always re°ecting on simplifying and improving the quality of the code [ 2 ]. These three concepts will be declined in attributes in this view. Another one which is the change indicators attribute will also be added to this view and it represents if the method as some metrics for helping to introduce the changes through the process.

The attributes of the Capability to Agility View are : Change indicators : BOOLEAN.

Collaborative : BOOLEAN.

Functional requirements can change : BOOLEAN.

Human resources can change : BOOLEAN.

Integration of the changes : BOOLEAN.

Knowledge sharing : ENUM(low, high).

Light weighted : BOOLEAN.

Non functional requirement can change : BOOLEAN.

People centred : BOOLEAN.

Reactivity : ENUM(at the beginning of the project, each milestone, each iteration).

Refactoring politic : BOOLEAN.

Short iterations : BOOLEAN.

Testing politic : BOOLEAN.

Work plan can change : BOOLEAN. 2.4

Applicability View

The aim of this view is to show the impact of environmental aspects on the method. It represents when the environment is favourable to apply the agile method. This aspect will be described by attributes, each one corresponding to a characteristic of the environment.

Software development environments can be characterized by indicators. A previous research [ 13 ] has determined a metric measuring the ¯tness of a project environment with the agility concept to determine which software development method use. This metric is called the Agility Measurement Index (AMI). It will not be used itself in this framework but our interest will be on the environmental projects indicators constituting the AMI (duration, risks, novelty, e®ort and interaction dimensions). These indicators will be derived in attributes of this view to characterize an ideal project environment to apply the agile method.

The duration represents the deadline of the project and will be expressed by the project size attribute. The risks are the degree of criticality of the software, for example a software impacting or monitoring high economic issue for the customer is highly critical. This aspect will correspond to the project risks attribute. E®ort indicator of the AMI represents the number of person-hour provided in the project by the customer and the development team. I think this aspect is not pertinent in this form to characterize an environment because e®ort is the duration of the project combined with its team size. So the team size will be an attribute in this view and be more relevant to identify a favourable environment for applying the method. The AMI novelty indicator represents the ability for the project to integrate a novelty solution and will be deported in the integration degree of novelty attribute. The last indicator is the interaction dimensions and corresponds to degree of interactions between the customer and the development team. As seen previously the people organizational aspect is important in agile methods. To re°ect this, the interactions aspect of the AMI will be extended to the interactions between end users and development teams. It will also concern interactions and organisation between the development team members. These aspects will be derived into attributes. A last aspect will be added to the applicability view, the project complexity attribute.

The attributes of the Applicability View View are : Degree of interaction between the team members : ENUM(low, high). Degree of interaction with the customer : ENUM(low, high).

Degree of interaction with the end users : ENUM(low, high).

Degree of novelty integration : ENUM(low, high).

Project complexity : ENUM(low, high).

Project risks : ENUM(low, high).

Project size : ENUM(small, large).

Team organization : ENUM(self organization, hierarchical organization).

Team size : ENUM(small, large). 2.5

Process and Products View

The process and product view represents how is characterised the method and what are the products of activities of the method process. The attributes will characterised the agile method process by two dimensions and list the products of the process activities.

A previous research [ 12 ] has a part of its agile methods comparison done on their life cycle. The methodology process is composed of two dimensions. The ¯rst dimension is the software development activities covered by the agile method. The second one represents the method abstraction level of its guidelines and rules. These two dimensions will be captured by attributes of this view and we will also carry our interest on the products of the process activities as a third attribute for the process and products view.

The attributes of the Process and Products View are :

Abstraction level of the rules and guidelines : SET(ENUM(project management, process description, concrete rules and guidelines on activities and products)).

Activities covered by the agile method : SET(ENUM(launching of the project, requirements de¯nition, modeling, code, unit test, integration test, system test, acceptation test, quality control, system use)).

Products of the method activities : SET(ENUM(design models, commented source code, executable, unit tests, integration tests, system tests, acceptation tests, quality reports, user documentation)). 3

Application of the Framework

The framework presented previously will be applied to eight major agile methods in this part. Methods are: Adaptive Software Development (ASD) [ 14 ], Agile Modeling (AM) [ 15 ], Crystal Methodologies [ 16 ], Dynamic System Development Method (DSDM) [ 17 ], Extreme Programming (XP) [ 18 ], Feature Driven Development (FDD) [ 19 ], Pragmatic Programming (PP) [ 20 ] and Scrum [ 21 ]. Each method will be characterized by the framework view and attributes according to their descriptions. The rationale of the methods evalution is fully documented in [ 22 ]

Legend for the process and products view : - \Activities" attributes : launching of the project = l, requirements de¯nition = rd, modeling = m, code = c, unit test = ut, integration test = it, system test = st, acceptation test = at, quality control = qc, system use = su - \Abstraction level" attributes : project management = pm, process description = pd, concrete rules and guidelines on activities and products = crg - \Products" attributes : design models = dm, commented source code = csc, executable = exe, unit tests = ut, integration tests = it, system tests st, acceptation tests = at, quality reports = qr, user documentation = doc

From this Table 1 we can identify that some methods have particular characteristics in comparison of the others. For example DSDM is the only method integrating a launching of the project activity. When going deeper in analyse of this comparison, we can notice that some attributes are common to several agile methods. From these common characteristics, we can regroup the methods into relevant sets of methods.

The most numerous common attributes of agile methods allow to capture them into two main classes as represented in Figure 2. The ¯rst class is regrouping the AM, XP and PP methods. These methods are characterized by a light weighted process with short iterations. They are addressed to small projects and teams with low risks. They also provide a productivity gain when they are applied in these conditions. According to this set of common attributes, this class represents methods oriented on software development practices. These methods are composed of rules and guidelines on the development activity itself. They concentrate the e®orts on how increase integration of changes, correctness, quality and productivity of software.

The second class of method regroups the ASD, Crystal, DSDM and Scrum methods by having the same level of abstraction of their rules (project manA P T D T I I T P P P K R C H WN F L I T R P C S C P F T E R R R U n n e r r r n e h u o F R ig tn e e e o oh ap rod oav rub n e e e s iiirttseceecovvd ssrrceaoopnd iitrzeaoagoannm lftreeeeoogvyn irseeeabnmmm iitttreceoahnw iitttrsceoahnw isezam ijrtssecok lijttececooxypm ijtszeeco ilrseeaggohndw iittcayv iitrsceaogadnn rrssceceoaunm lrccaaaknhnp eccgaanhnR eccgaanhn itteegdhhw ifttreeooaghn iilittscogpn liiiftrtccogaopn lrteceeodnp illtreaaovb iitrrttseoan ilittaaogyb iiittcagyvnu ltreooabu® ilrteeovnnnu ifttrsssceaaud liftsecaaoqup frttseeecoqhp ilfrtseeecovdp ieeagvw a n ch n g

e c h a n g e a n g e s i sh m io t u in il o e n y ir g ty r n le em d

in t v a v g i e w le en te t s s rq ,ts ,e d c ,ts ,c ic a l u r i M ,ts ,tu scc p e

m ta ,t ,d ra H L L H L H H L H li F T F T T F T T F T T F F T F F T T T A ,ta ,it ,ex ,p ,q i,t ,m rch igh ow ow igh rega igh igh rega igh tseo lsea reu lsea reu reu lsea reu reu lsea reu reu lsea lsea reu lsea lsea reu reu reu SD n c r It ,dm lfeS oLw ighH oLw ighH laSm oLw oLw aSm igH trea lsaF ruT ruT lsaF ruT ruT ruT lsaF ruT ruT ruT ruT ruT lsaF ruT lsaF lsaF ruT lsaF AM , l h io e e e e e e e e e e e e e e e e e e e l l

n i,t ,ce ,m ts ,tcu lfeS oLw ighH oLw oLw aSm H H aL H lie aF ruT lsaF lsaF lsaF lsaF lsaF lsaF lsaF ruT ruT lsaF lsaF ruT lsaF lsaF lsaF ruT ruT sry , x p , ll igh igh reg igh tson lse e e e e e e e e e e e e e e e e e e ta C l e M e P r o i n n i n g n u r I ,ittu ,scce ,cdp ,itt ,dm lfeS ighH ighH oLw ighH laSm oLw oLw aSm igH rttea ruT ruT ruT lsaF ruT ruT ruT ruT ruT ruT ruT ruT ruT lsaF ruT lsaF lsaF ruT lsaF PX , x r , , l h io e e e e e e e e e e e e e e e e e e e s e g l l t , ts ,c n e p H j x d m u r i e ,e m , ,t ,d rea L L L L aL H H L L tc F F F F F T F F F F F T F F F F F T T F o ,t sc c it ,c d su i,t ,m ic , a

l e ,ex dm ,tu ,rd irea L H L L Sm L L Sm L Irte F F T F T T T T T F T T T F T F T F T P ts ,tu ,sc rcg i,t ,m rch ow igh ow ow lla ow ow lla ow itao lsea lsea reu lsea reu reu reu reu reu lsea reu reu reu lsea reu lsea reu lsea reu P I D t ra H H H H L H H L L re F F F F T F T T T T T F F T T T F T T S a a ts ,tu ,sc pm i,t ,m lfe ow ow ow ow lla igh igh reg ow tson lsea lsea lsea lsea reu reu reu reu lsea lsea lsea reu lsea reu reu lsea lsea reu reu rum it ,c ts ,c , agement). These methods also distinguish from the others by their respect of requirements and delivering dates. Another common point to them is that they adapted to large and complex project. From this common set of attributes it emerges the class of project management oriented methods. These methods are oriented on the management of the project life cycle to ¯t large projects.

One method, FDD di®erentiates from the others by owning characteristics of the two classes. FDD is a hybrid method inheriting the development practices from the ¯rst class and some project management guidelines from the second. This is captured in Figure 2 by an hybrid class which inherits characteristics of the two other main classes.

All agile methods are regrouped into these three classes :

Software Development Practices Oriented Methods : Agile Modeling, Extreme Programming, Pragmatic Programming.

Project Management Oriented Methods : Adaptive Software Development, Crystal Methodologies, Dynamic System Development Method, Scrum.

Hybrid Methods : Feature Driven Development.

Some other minor classes, shown in Table 2 below, can be captured by the same means. They re°ect common particular aspects of agile methods. For example if we carry our interest on the quality in agile methods. We can ¯nd a quality control class composed by FDD and ASD. This subclass represents that the process contains activities for controlling quality of the software to guaranty a quality level of it. In the same way we can identify two other subclasses, the knowledge management and the high reactivity subclasses. The ¯rst one concerns high interactions with customers and the team members. Knowledge management is also identi¯ed by self organisation of the teams providing a high sharing of the knowledge. These factors impact humans resources, when a member leave the team the other member have already integrated his knowledge. In practice the knowledge management can be found in some guidelines, for example the pair programming in Extreme Programming providing the share of knowledge on the whole system between the team members. The last subclass represents the speed of integration of changes in the process. This is characterised by a high reactivity with a meeting between the customer and the team every iteration. This high degree of interaction with the customer and the team re°ect the ¯tness of the method to turbulent environments when the customer's requirement are frequently changing.

Quality Knowledge High

Control Management Reactivity

X X

This Table 2 captures the minor classes and shows which methods are regrouped in these classes.

This work leads to classify agile methods and provides a support to choose the right method according to the project context. The second topic of the paper is to analyse agile methods for extracting best practices which can be reused in plan-driven methodologies. Section 4 deals with this topic and explains how the framework is used to extract agile method components. 4

Extracting Agile method Components from the framework

The purpose of this section is to identify best practices of agile methods which can be reused in plan-driven methods. Such components can be used to improve the agility of a method. We exploit the framework proposed in section 2 to indentify such components. The four aspects what, how, when, and why is unsefull to indentify relevant best practices. what and how asects allow to capture the best practices. Their relevance is provided by the analysis by the when and why aspects. This approach has been applied for agiles characteristics common to most of the methods and those speci¯cs to few methods. This leads to identify eight components.

If we carry our attention on DSDM for example, two components can be captured. The ¯rst one concerns the \launching of the project" activity expressed by a feasibility and a business study. This component is captured in the framework by the presence of launching of project activity in the method life cycle. It aims to estimate if the project is feasible for the requirements and the dates announced. It can be applied in large and complex project environments. The second component concerns the \management of the end users" by integrating the system users in the development process, giving them some decisional power on the requirements for the system features. It also included the validation of the deliverables and the formation of end users to the new system. This component is captured in the framework through the presence of activities for the system in use in the life cycle, the production of user documentation, high level of interactions with end users and the aim to satisfy users of the system. This last attribute re°ects the aim of this component to increase the satisfaction of the users of system and reduce their aversion to novelty. From another method like ASD, we can extract a \quality" component concerning the activities of quality controlling and the integration of non functional requirements changes in the process. This component is isolated from the quality level respect, integration of the non functional requirement, activities and products of quality control framework attributes. The aim is to provide a quality level for developed software along with an increase of the productivity. This quality gain can by applied in complex and risky projects with large development team and for controlling the development of the novelties.

Now let's carry our interests on the aspects issued from the agility concept that can be captured into components to bring agility to other methods. On the aspect of agility concerning the code we can identify two components. The ¯rst one is the \tests" and concern test politics, testing activities and products. This component can be applied in every project and aims to produce a productivity gain. The second component is \refactoring" by reviewing the code constantly to simplify and improve it. This is destined to small projects with low complexity and risk to gain productivity. In a more general consideration \knowledge management" can be captured into a component to satisfy the same objectives in projects with small teams and a high level of interaction into them. This component is materialised by the sharing of the knowledge on the system between the teams members. Concerning the framework, this component is issued from the following attributes : high interactions between the team members, self organisation for the teams, high amount of knowledge sharing and human resources can change.

Launching of

the Project

Management of the End Users

Quality

Tests

Refactoring

Knowledge

Management

Agile Life

Cycle

Change

Indicator

What

People centred and Reactivity

Changes in

NFR Test politic Refactoring

politic People centred and knowledge sharing

From a requirement engineering point of view two relevant components can be captured. One about the \agile life cycle" and another on a \change indicator". An agile life cycle is iterative and incremental and an agile requirement de¯nition follows this principle. The customer de¯nes his needs in a high level of abstraction at the beginning of the project. Every iteration, requirements de¯nition will be detailed at a meeting between the customer and the development team. Only the needed features implemented in the current iteration will be de¯ned in detail. This prevents from the changes on initial requirements and integrates customers feedback in the de¯nition. From the framework, attributes characterising an optimum agile cycle are short iterations and adapted to turbulent environment. Such component applies in projects where a high cooperation with the customer is possible and aims to integrate changes in requirements happening in turbulent environments.

Change indicators can be used in development process to control and manage the changes. In this component we will carry our interest on project velocity used in XP. It's a metric allowing customer and development teams to re¯ne their time to code estimations on features to develop in the current iteration. The project velocity is the factor between estimations in ideals programming days and real time it takes to develop. It's calculated from the sum of estimations for the previous iteration divided by the sum of the real time it takes to implement. So it considers also current team productivity to re¯ne the estimations. This component aims to improve the respect of delivering dates by helping customer and development teams to make betters estimations on implementations of requirements and applies in every kind of agile project.

The list of identi¯ed components is not exhaustive.

Table 4 shows a summarization of components characteristics according to aspects expressed in the framework views. 5

Conclusion

The paper describes a framework for agile methods used in two di®erent topics: { Classify agile methods to support the method selection. { Improve agility of plan-driven methods by proposing agile components.

The ¯rst step was to de¯ne a framework to describe agile methods. Ones applied to agile methods, a classi¯cation has been done by regrouping methods common attributes. From this, several methods components have been captured to be reused into other methods.

The agile method components can be used in a component based method engineering aproach to improve agility of existing methods. In fact, they can be used to adapt methods to turbulent environments or to upgrade agile methods with bringing news aspects for a particular kind of projects. This work is a preliminary work to the de¯nition of a method engineering approach aiming at increasing the agility of methods.

References

1. Beck , K. , Beedle , M., van Bennekum , A. , Cockburn , A. , Cunningham , W. , Fowler , M. , Grenning , J. , Highsmith , J. , Hunt , A. , Je®ries, R., Kern , J. , Marick , B. , Martin , R.C. , Mellor , S. , Schwaber , K. , Sutherland , J. , Thom , D. : Manifesto for agile software development . Website ( 2001 ) http://agilemanifesto.org/.

2. Lindvall , M. , Basili , V. , Boehm , B. , Costa , P. , Dangle , K. , Shull , F. , Tesoriero , R. , Williams , L. , Zelkowitz , M. : Empirical ¯ndings in agile methods . In: Agile Universe . ( 2002 ) 197 { 207

3. Nerur , S. , Balijepally , V. : Theoretical re°ections on agile development methodologies . Communications of the ACM 50 ( 3 ) ( 2007 ) 79 { 83

4. Rolland , C. : A comprehensive view of process engineering . In Pernici, B. , Thanos , C., eds. : 10th International Conference on Advanced Information System Engineering , CAISE'98 , Springer-Verlag ( 1998 )

5. Rolland , C. , Achour , C.B. , Cauvet , C. , Ralyt , J. , Sutcli®e, A. , Maiden , N. , Jarke , M. , Haumer , P. , Pohl , K. , Dubois , E. , Heymans , P.: A proposal for a scenario classi¯cation framework . Requirement Engineering ( 1998 ) 11 { 26

6. Parsons , D. , Ryu , H. , Lal , R.: The impact of methods and techniques on outcomes from agile software development projects . International Federation for Information Processing 30 ( 2007 ) 11 { 26

7. Turk , D. , France, R. , Rumpe , B. : Limitations of agile software processes . In: International Conference on eXtreme Programming and Agile Processes in Software Engineering . ( 2002 )

8. Rook , P. : Controlling software projects . Software Engineering Journal 1 ( 1 ) ( 1996 ) 7 { 16

9. Royce , W.W.: Managing the development of large software systems . ( 1987 )

10. Boehm , B.W.: A spiral model of software development and enhancement . IEEE Computer 21(5) ( 1988 ) 61 { 72

11. Abrahamssona , P. , Warstab , J. , Siponenb , M.T. , Ronkainena , J.: New directions on agile methods: A comparative analysis . In: International Conference on Software Engineering . ( 2003 )

12. Abrahamsson , P. , Salo , O. , Ronkainen , J. , Warsta , J.: Agile software development methods : Review and analysis . VTT Publication ( 2002 )

13. Datta , S. : Agility measurement index - a metric for the crossroads of software development methodologies . ACM ( 2006 ) 271 { 273

14. Highsmith , J.A. : Adaptive Software Development : A Collaborative Approach to Managing Complex Systems . Dorcet House Publishing ( 2000 )

15. Ambler , S.W. : Agile modeling . Website ( 2006 ) http://www.agilemodeling.com.

16. Cockburn , A. : Agile Software Development . ( 2001 )

17. Consortium , D. : Dsdm version 4 .2. Website ( 2007 ) http://www.dsdm.org/ version4/2/public/default.asp.

18. Wells , D. : Extreme programming . Website ( 2006 ) http://www. extremeprogramming.org.

19. Palmer , S.R. , Felsing , J.M.: A Practical Guide to Feature-Driven Development . ( 2002 )

20. Hunt , A. , Thomas , D. : Pragmatic Programmer, The: From Journeyman to Master. ( 1999 )

21. Schwaber , K. : Agile Project Management With Scrum . ( 2004 )

22. Iacovelli , A. : Introduction de l'agilit¶e dans les m¶ethodes . Master thesis , University Paris 1 Panth¶eon Sorbonne ( 2007 )