Towards a common agile software development ... - ACM Digital Library

ACM SIGSOFT Software Engineering Notes

Page 1

July 2012 Volume 37 Number 4

Towards a common Agile Software Development Model (ASDM) André Janus André Janus – IT Consulting Karlsruhe Germany

ABSTRACT

[email protected] 2.1 Meta-Methodology: The Agile Manifesto

In this paper we use a formal approach to describe Agile Software Development Methodologies. We extract common attributes and properties out of Agile Methodologies to establish a common Agile Software Development Model (ASDM). To build our model we take a look at the Agile Manifesto as well as eXtreme Programing (XP) and Scrum, and also a project-specific Agile Methodology called I2. We describe the Agile Software Development Methodologies in terms of Sets, Relations and Equations to make similarities and differences visible. With this formal characterization we can compare the Methodologies to each other and extract the common attributes and properties as parts of the common Agile Software Development Model (ASDM). After establishing our model we assess the explanatory power and aspects of completeness of the model to identify weakness and improvement potential. The explanatory power means the ability to characterize a Methodology and compare different Methodologies to each other. Completeness issues are related to the model itself, to the model's instantiations (e. g. describing XP with the ASDM) and the completeness of (relevant) Practices. Using this approach we try to achieve better theoretical understanding and comparability for Agile Methodologies.

Categories and Subject Descriptors D.2 [Management]: Software Process Models

The Agile Manifesto [2] is not an Agile Software Development Methodology itself but the "spiritual" background for Agile Software Development, so we call it "Meta-Methodology". Or as [8] said with respect to the Agile Manifesto: "Agile is an Umbrella - Methodologies are Implementations". Every Agile Software Development Methodology refers to the Agile Manifesto and claims to follow its rules or – in terms of the Manifesto – its Values.

2.1.1 Values Commonly known are the Values of the Agile Manifesto described in [Table 1]. Individuals and Interaction over Processes and Tools Working Software over comprehensive Documentation Customer collaboration over contract negotiation Responding to change over following a plan Table 1. The Values of the Agile Manifesto The Values are often misunderstood as people think the Values on the left side are the only Values. But the terms on the right side are also "valuable" and not "worthless".

General Terms Agile, Development Process, Management, Measurement, Life-cycle

Keywords Agile Software Development, Software Engineering Methodologies, Software Measurement, Software Development Life-cycle

1. INTRODUCTION Roughly according to the formal description of Software Development i. e. Software Engineering in [1] we take a look at the Agile Manifesto, eXtreme Programming (XP), Scrum and a project-specific Methodology called I2 to extract (common) attributes and properties of Agile Software Development. We describe the found attributes and properties as Sets, Relations and Equations to identify the common ones as parts of an Agile Software Development Model (ASDM). Applying the Model to in-use Agile Methodologies should help characterizing and comparing them to each other. Until now comparison of Agile Methodologies is only done in an narrative and textual way, e. g. in [9], which is not exact and calls for improvement. A great challenge for that is the also narrative and textual form, how Agile Software Development and its Methodologies are described. We use the term "Methodology" instead of "Method", because "Method" often refers to single Practices of Agile Methodologies like e. g. Test-Driven-Development (TDD).

2. METHODOLOGIES In the following sections we take a closer look on the one hand at the Agile Manifesto and on the other hand at the Agile Methodologies XP, Scrum and I2. Both methodologies XP and Scrum are widely known and accepted, the last one called I2 is company-specific or rather a project-specific Methodology.

DOI: 10.1145/2237796.2237803

ValuesAgileManifesto = {individualsAndInteraction, processesAndTools, workingSoftware, comprehensiveDocumentation, customerCollaboration, contractNegotiation, respondingToChange,followingAPlan}

2.1.2 Relations So the Agile Manifesto defines Values and also Relations between these Values based on an ordinal scale: individualsAndInteraction > processesAndTools workingSoftware > comprehensiveDocumentation customerCollaboration > respondingToChange >

contractNegotiation

followingAPlan

2.1.3 Principles Often forgotten the Agile Manifesto defines not only Values (and Relations between them) but also has twelve principles as shown in [Table 2]. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development.

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 2

Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

July 2012 Volume 37 Number 4

also not clear if all roles are defined or if this is just a set of necessary roles. That is why we choose to define the roles as a subset ("⊆"): rolesAgile Manifesto ⊆ {customer, businessPeople, teamdeveloper, sponsor, user}

teamdeveloper= {developer1, developer2,... developern}

2.1.5 Artifacts According to the Roles we also find Artifacts as described: artifacts(Values)Agile Manifesto ⊆ {software, documentation, contract, tools, plan} artifacts(Principles)Agile Manifesto ⊆ {software, requirements, architectures, designs}

As architecture and designs are more abstract Concepts as concrete Artifacts we subsume them under plan (ex ante view) and/or documentation (ex post view). Requirements are also an abstract Concept, but have a functional view to the software instead of the technical view of architecture or design. Therefore we differ between technical documentation and functional documentation. artifactsAgile Manifesto ⊆ {software, documentationtechnical, documentationfunctional, contract, tools}

with

Table 2. The Principles of the Agile Manifesto We merge these Principle phrases to twelve tight expressions as Principles reflecting the sentences above: PrinciplesAgile Manifesto = {customerSatisfactionAndValuableSoftware, changingRequirements, continousAndFrequentDeliveryOfSoftware, workingTogether, motivatedTeamAndGoodEnvironmentAndSupport, face2faceConversation, workingSoftwareAsMeasureOfProgress, sustainabelDevelopmentandConstantPace, technicalExcellenceAndGoodDesign, simplicity, selfOrganizingTeams, reflectionAndImprovement }

2.1.4 Roles We find Roles in the Values of the Agile Manifesto and in the Principles: roles(Values)Agile

Manifesto

⊆ {individuals, customer}

documentationtechnical ⊆ {architecture, design} documentationfunctional ⊆ {requirements}

It is also not clear if all Artifacts are defined or if this is just a set of necessary Artifacts. That is why we choose to define the Roles as a subset ("⊆").

2.1.6 Practices and Process The Manifesto just tells us that there is at least one defined Process, but there is no concrete Process defined. We also do not find concrete Practices. So we can derive: practices = ∅ process ≠ ∅

The Agile Manifesto describes Artifacts and Roles that are important for Software Development Methodologies but there are no concrete Practices (or a concrete Process). That is why the Agile Manifesto is not a Methodology itself. [Figure 1] shows the basic contents of the Agile Manifesto – the grey parts are not explicitly described, but derived by the analysis above.

roles(Principles)Agile Manifesto ⊆ {customer, businessPeople, developer, individuals, team, teamdeveloper, sponsor, user}

Assuming that "individuals" and "team" is not a Role but refers to all participating people, we have a Developer Team as part of the whole Team. It is not clear anyway, if the customer is part of the team. It is

DOI: 10.1145/2237796.2237803

Figure 1. Basic Contents of the Agile Manifesto

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 3

2.2 Methodology 1: eXtreme Programming (XP)

July 2012 Volume 37 Number 4 ●

Coding Standards: Coding Standards are formatting guidelines and other rules for writing code. They should be used by every Software Engineer to ease readability and understandability for other Software Engineers.

●

Simple Design: Similar to the Coding Standards the overall design and architecture should be as simple as possible for reasons of understandability and extensibility.

●

Planning Game: The Iterations are planned in the so-called Planning Game. In this meeting the customer explains the required new features to the Software Development Team, which estimates time and/or budget. They also define priorities. After the Planning Game the features for the next Iteration are selected and the Development team commits to implement them.

●

Retrospective: After every Iteration the Software Development team looks back to the last Iteration to identify problems and possibilities for improvements to be applied in the next Iteration.

●

Standup-Meeting(s): Standup-Meetings are short and informal meetings for quick and frequent exchange and distribution of information within the Software Development team.

eXtreme Programming [3] [4] is one of the first implemented and one of the best know Agile Methodologies. XP has a focus on Software Engineering issues.

2.2.1 Values and Principles Extreme Programming differs between Values and Principles. Here are the Values and Principles from XP in detail: ValuesXP = {simplicity, courage, communication, feedback, respect}

PrinciplesXP = {rapidFeedback, assumeSimplicity, incrementalChange, embraceChange, qualityWork}

2.2.2 Practices XP also has concrete Practices with focus on Programming but it has also on Management-related or Organizational-related Practices: ●

Pair-Programming: Pair Programming means two programmers sharing one computer, especially one keyboard. They both think about the requirements and decide how to write the code. One is writing the code while the other corrects him.

●

Collective Code-Ownership: Every Developer can change every piece of code. A Developer is allowed to change code and there are no restrictions in access and editability. And a developer has knowledge and ability to work on every piece of the code.

●

●

●

●

●

●

●

Continuous Integration: Changes to the code should be continuously and permanently be integrated into the code base and checked for integration problems. In practice mostly configuration and version management systems like CVS or SVN are used for integration into a code base. And CISystems like CruiseControl or Hudson are used for Compilation, Building and Deployment and for further integration checks and tests. Testing: Testing is essential for XP: Testing means Testing by the Developer, Test-Driven-Development, RegressionTests, but also Testing by the customer. On-site Customer: The customer should be easily reachable for the Software Development team to answer questions and help understand the requirements. Refactoring: Adding new features decreases the quality of code and design, because the code was optimized and designed for the existing features. Due to these code changes refactoring of the code is necessary to re-improve the quality of code and design. Refactorings are code changes which do not change the functionality but only the structure of the code. 40h-Week: The participating people should have an average working time around 40h per week. Permanent overtime has a negative influence on efficiency and quality of the work results. Small Releases: The Software should be delivered in small releases. Every release increases the functionality but every release has a limited set of new features. The Software grows iteratively and incrementally. The Development Process therefore consists of Iterations. Metaphor: All in the Software Development involved people should use a common language and common terms to describe the software's features. Therefore User Stories or Metaphors draw a picture of the Software and it's functionality.

DOI: 10.1145/2237796.2237803

PracticesXP= {pairProgramming, collectiveCodeOwnership, continousIntegration, testing, onsiteCustomer, refactoring, 40hWeek, smallReleases, metaphor, codingStandards, simpleDesign, planningGame, retrospective, standupMeetings}

2.2.3 Roles XP differs basic and supplementary Roles. The basic roles are necessary roles to a Software Project. The supplementary Roles may be assigned if needed. RolesXP= BasicRolesXP ∪ SupplementaryRolesXP

BasicRolesXP= {developer, customer}

SupplementaryRolesXP= {tester, coach, projectManager, consultant}

2.2.4 Artifacts The Artifacts can be derived from the Practices: ArtifactsXP= {sourceCode, releaseArtifacts, continousIntegrationInfrastructure, testingInfrastructure}

2.2.5 Process Also the Process can be derived from the Practices and Roles:

processI2 := {iteration1, iteration2, ...iterationn}

iterationn := {plan, design, program, refactor, integrate, test, release}

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 4

July 2012 Volume 37 Number 4

2.2.6 Relations

2.3.3 Practices and Process

In XP we have for example the following Relations (without achieving completeness), which show how the Practices meet the Principles:

Scrum has several Practices which form the Scrum Development Process. First of all there are the time boxes with a fixed length called Sprints. Each Sprint is planed in a Planning Meeting at the beginning, where the Product Owner explains the feature to be implemented to the team and the team estimates the effort and identifies the necessary tasks to implement a feature. Through the Daily Scrum, which is a every day meeting, where the team communicates shortly (in about 15 minutes) its progress or its impediments to each other and the Scrum Master. At the end of a Sprint the team shows the software and the new implemented features to the Product Owner in a meeting called Sprint Review. The Product Owner checks the implemented features and adjusts the features and priorities for the next Sprint with this information. Another meeting is the Retrospective, which is used to identify problems and possible improvements of the last Sprint. Retrospectives may be held after every Sprint, but at least several times throughout the project duration.

r(increm.Change) ∈ RXP : planningGame × standupMeeting → incrementalChange

r(rapidFeedback) ∈ RXP : continousIntegration × testing → rapidFeedback

r(qualityWork) ∈ RXP : simpleDesign × codingStandards → qualityWork

[Figure 2] shows the basic contents of XP – the grey parts are not explicitly described, but derived by the analysis above.

Here is the complete set of Practices of Scrum: practicesScrum= {planning meeting, dailyScrum, sprint, sprintReview, retrospective}

The process of Scrum is derived from the practices as a sequence of Sprints: processScrum:= {sprint1, sprint2, ... sprintn}

Figure 2. Basic Contents of XP

2.3 Methodology 2: Scrum Scrum [5] is another widely known and accepted Agile Methodology with focus on Project Management issues. Like the other Agile Methodologies Scrum relies on the Agile Manifesto but brings its own set of Values.

2.3.1 Values

2.3.4 Artifacts Scrum uses several Artifacts for its Methodology: artifactsScrum= {productBacklog, releaseBacklogsprint1...x sprintBacklogsprint1...x, productIncrementsprint1..x, impedimentBacklog, burndownChart}

Scrum has no Principles like XP, but it has the following Values:

ValuesScrum = {commitment, focus, openness, respect, courage}

2.3.2 Roles Scrum has three Roles: The Product Owner sets the objective of the Software Product and defines the features of the software through User Stories. He also sets the priority of the features, i. e. the order in which the features should be implemented. The Scrum Master is another Role within Scrum to help the team (and the Product Owner) to be productive by removing impediments and solving problems. The Scrum Team as the third Role consists of 2 up to 7 developers. The team estimates the effort for the features and commits itself to implement them within a given time box, the Sprint. rolesScrum= {productOwner, scrumMaster, teamdeveloper}

The Product Backlog contains all features of the Software, the Release Backlog contains the features to be implemented during a Sprint therefore it is a subset of the Product backlog – and the Sprint Backlog contains the necessary tasks to implement the features of the Release Backlog: productBacklog = {feature1, feature2, ...featuren}

releaseBacklog = {feature1, feature2, ...featurem}

with n > m

=> releaseBacklog ⊆ productBacklog

Note that there may be more than one task, maybe even independent tasks, to implement a feature:

teamdeveloper= {developer1, developer2,... developern} with 2 < n < 7

The team is self-organized, which means that the Product Owner only gives the priority of the features, but the team decides how to implement them and which team member implements it. The Scrum Master takes care that the Teams stays self-organized and the Product Owner does not instruct them.

DOI: 10.1145/2237796.2237803

sprintBacklog = {task1, tasks2,… tasko} with o ≥ m

After a Sprint the implemented code results in a Product Increment, which can potentially be released. The number of Product Increments equals the number of Sprints:

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 5

product = productIncrement1 ∪ productIncrement2 ... ∪ productIncrementp

July 2012 Volume 37 Number 4

[Figure 4] shows the basic contents of Scrum – the grey parts are not explicitly described, but derived by the analysis above.

with p = #sprints

The Impediment Backlog contains the issues the Scrum Master has to deal with. He is responsible to remove the impediments and solve problems for the team: Figure 4. Basic Contents of Scrum impedimentBacklog = {impediment1, impediment2,… impedimentq}

The Burn-Down-Chart [Figure 3] is a helpful visualization to show the teams progress within a Sprint. The chart shows at the x-axis the days of the Sprint and on the y-axis the not-completed tasks, which naturally decrease during the Sprint. With the trend shown by the chart one can estimate if the tasks will be completed at the end of the Sprint or maybe even more tasks could be planned for the next Sprint.

2.4 Methodology 3: I2 The I2 methodology [6] is derived from XP and was adapted to projectspecific needs. I2 stands for "Industrialized Iteration". It was developed by T-Systems in 2001 and used in one pilot project. Over the last years I2 was continuously improved and is meanwhile used by several projects at T-Systems.

2.4.1 Values and Principles As I2 is based on XP it has the same Values and Principles: ValuesI2 = ValuesXP PrinciplesI2 = PrinciplesXP

2.4.2 Practices The practices differ as I2 uses a lot of the XP Practices, but also leaves some out and adds some own Practices: PracticesI2 = PracticesXP \ {pairProgramming, onsiteCustomer, metaphor, retrospective, standupMeetings} ∪ {reviews, statusMeeting, customerSurrogate}

Figure 3. Burn-Down-Chart

2.3.5 Observations As mentioned the Product Owner decides on the order of feature implementation. Therefore we can derive the priority of an item from the Release Backlog has a higher priority than an item left on the Product Backlog (assuming implemented features or features moved to the Release Backlog are removed or marked in the Product Backlog): priority(featurereleaseBacklog > priority(featureproductBacklog)

As the product size grows after completion of every Sprint, we can derive the size of different Product Increments: size(productIncrementx) > size(productIncrementy)

with x > y

2.3.6 Relations In Scrum we have for example the following Relations (without achieving completeness), which show how Process is defined: The Sprint is derived from the Practices and the Process itself consists of a sequence of Sprints. r(process) ∈ RScrum : planningMeeting × dailyStandUp × sprintReview × retrospective → sprint

r(process) ∈ RScrum : sprint1 × sprint2 × ... × sprintn → process

DOI: 10.1145/2237796.2237803

= {collectiveCodeOwnership, continuousIntegration, testing, refactoring, 40hWeek, smallReleases, codingStandards, simpleDesign, planningGame} ∪ {reviews, statusMeeting, customerSurrogate}

= {collectiveCodeOwnership, continuousIntegration, testing, refactoring, 40hWeek, smallReleases, codingStandards, simpleDesign, planningGame, reviews, statusMeeting, customerSurrogate}

2.4.3 Roles I2 has a set of Roles different to XP. Developer of course is a common Role, but note that I2 has no Customer (Role): RolesI2= {developer, businessAnalyst, developmentManager, projectManager, tester, testManager}

2.4.4 Artifacts The Artifacts of I2 can be derived from the Practices:

ArtifactsI2= {sourceCode, releaseArtifacts, continousIntegrationInfrastructure, testingInfrastructure}

2.4.5 Process The Process of I2 is equal to the XP Process: processI2 := {iteration1, iteration2,... iterationn}

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 6

July 2012 Volume 37 Number 4

iterationn := {plan, design, program, refactor, integrate, test, release}

2.4.6 Substitutes As I2 has many differences to XP, these two methodologies have more in common as obvious. For the left out Practices of XP the I2 methodology has Practices to compensate the missing effect of the XP Practices: We call them Substitutes. Instead of Pair Programming, which means that two developers implement a whole feature as team, in I2 one developer implements a feature and explains his code to another developer, the reviewer. The reviewer should know the new code after the review and should find mistakes during the review, which the other developer corrects immediately after the review. pairProgramming → reviews

For the On-site Customer I2 has the Customer Surrogate, a Role mainly assigned to the business analysts, who not only makes decisions in behalf of the customer but also consults the customer and forms concrete business processes and software features out of the customers vision about what the software should do for him. onsiteCustomer → customerSurrogate = businessAnalyst

Instead of Standup-Meetings and Retrospectives I2 has the Status Meeting. The Status Meeting takes place every week: In the middle of the iteration and at the end of the iteration (before the Planning Game). The team members state what their actual work is and what problems they face (like in the Standup-Meeting) and the team looks back to the last iteration i. e. the first half of the actual iteration to find out about possible optimizations (like in the Retrospective) retrospective, standupMeetings → statusMeeting

Only the Metaphor has no Substitute in I2, but also in the revisited XP it was removed [4], and I2 took into account what other XP practitioners also did. metaphor → ∅

2.4.7 Relations In I2 we have for example the following Relations (without achieving completeness), which show how the Substitutes and Practices meet the Principles: r(rapidFeedback) ∈ RI2 : statusMeeting × customerSurrogate → rapidFeedback

r(qualityWork) ∈ RI2 : reviews × codingStandards → qualityWork

[Figure 5] shows the basic contents of I2 – the gray parts are not explicitly described, but derived by the analysis above.

Figure 5. Basic Contents of I2

3. AGILE SOFTWARE DEVELOPMENT MODEL (ASDM) After looking at the Agile Manifesto and the Agile Methodologies XP, Scrum and I2 we try to extract common attributes and properties of Agile Methodologies to establish a common Agile Software Development Model (ASDM). Until now the common understanding of Agile Software Development is that "Being Agile means following the Agile Manifesto" or as said in [7]: "A software process is considered agile when it conforms to these values and principles". This statement is simple and true, but hardly verifiable and calls for a model that helps to formalize, describe and check Agile Methodologies against that Statement.

3.1 A common model for Agile Software Development Methodologies For a comprehensive description of an Agile Software Development Model (ASDM) we take the analysis above to define what elements and what relations between these elements characterize an Agile Software Development Methodology. So our first statement is that the model consists of two sets, which is a set of the Elements and a set of the Relations: ASDM = (MASDM, RASDM)

3.2 Elements of a common ASDM As Elements MASDM we combined Values and Principles because these are both abstract guidelines. The Agile Manifesto and eXtreme Programming (XP) have both Values and Principles, but Scrum does only have Values. I2 as a derivative of XP has both too. Concrete Practices, which exactly tell what to do, are missing in the Agile Manifesto. This is the reason why the Agile Manifesto itself is not an Agile Methodology. Methodologies like eXtreme Programming (XP), Scrum or I2 have Practices, which are necessary to form a Methodology. Another necessary element are Roles: Roles tell who has to do something i. e. who is responsible for what. Even the Agile Manifesto has Roles and so have the Methodologies XP, Scrum and I2. These Elements must explicitly be defined, but others can be derived from the Values, Principles, Roles and Practices: These are the Artifacts and the Process. These parts define concrete steps, the order of the single steps and what should be the outcome of a step within the Software Development. MASDM = MASDM(defined) ∪ MASDM(derived)

with

MASDM(defined) ⊆ {values ∪ principles, roles, practices} MASDM(derived) ⊆ {artifacts, process}

DOI: 10.1145/2237796.2237803

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 7

The derived ones can also be explicitly defined, but do not have to. So the following is also possible: MASDM(derived) = ∅

3.3 Relations of a common ASDM The relations fulfill two functions: At first to establish a process and derive the artifacts, if they are not explicitly defined. At second they show how the practices fulfill the Values and Principles of the Methodology. But generally the relations RASDM can describe any relation between the elements of the first set. The process e. g. can be defined by Practices and Roles of the Software Development Methodology: r(process) ∈ RASDM : practice × role → process

A principle can be met through a combination of practices: r(principle) ∈ RASDM : practice1 × practice2 → principle

These relations are just examples of many possible relations that are part of an Agile Software Development Methodology. The relations show how the parts of an Agile Methodology work together, how they influence each other and define the special character of an Agile Software Methodology. [Figure 6] shows the basic content of the ASDM – the grey parts are derived, the white parts defined.

July 2012 Volume 37 Number 4

not have Principles at all. So it is reasonable to combine Values and Principles as abstract rules. For a deeper understanding one can also establish the relations between the Practices, which shows how the Practices meet the Values and Principles and also show in which way the Process is established by the Practices. Via the assignment to the elements above and via establishing the relations between the elements the Methodologies are characterized in a formal manner.

4.1.2 Comparison Overall we can now easily compare the Agile Methodologies as we look at each element and their relations. For example we can compare the Process of XP and Scrum: As Iterations and Sprint both are Time-boxes the Processes of Scrum and XP are equal in that way. Having a closer look at the Time-boxes we surely see the differences, how the Time-boxes are filled with Activities i. e. Practices. Another example are the different Roles of XP and I2: Even though I2 is based on XP the I2 Methodology relinquishes the XP Roles Coach and Consultant, replaces the Customer by Business Analysts and adds Development Manager and Test Manager.

4.2 Completeness 4.2.1 Completeness of the Model As seen within the evaluation of the Agile Manifesto with our model, all elements should exist i.e. described by the Methodology. The Agile Manifesto does have Practices and does not describe a Process. Therefore we conclude that it is not "complete" in terms of an Agile Software Development Methodology, which should cover all defined elements of the ADSM.

4.2.2 Completeness of a Model Instantiation

Figure 6. Basic Content of the ASDM

4. CONCLUSION After extracting our general model from the Agile Manifesto, eXtreme Programming (XP), Scrum and the I2 Methodology we can conclude how much explanatory power our model has and what we can reason from it in terms of completeness. And we suggest what future work can be done to improve and extend the model.

4.1 Explanatory Power Now we take a closer look at the explanatory power our model has to the aspects of characterization and comparison.

As we assign all properties of an Agile Methodology to our model and it's categories we get an instantiation of our model for the elected Methodology. But the instantiation is not complete as we do not establish all relations. In this paper we show relations by way of example and without archieving completeness. A necessary, but not sufficient criterion for the completeness of the relations is that all Practices must be part of an relation that fulfills the Values (or Principles): ∀ PracticesMethodology ∈ RASDM : practice1 × practice2 ... × practicen→ valueOrPrinciple

And that all Values and Principles must be covered: ∀ ValuesOrPrinciplesMethodology ∈ RASDM

4.1.1 Characterization By matching the properties of Agile Software Development Methodologies to the elements Values and Principles, Practices, Roles, Artifacts and Process of our model, we got a helpful separation to analyze the methodologies step by step. In most cases the categories like for example Roles we quite distinguish and it was easy to assign the Methodologies' properties to these category. And so it was with Practices, which could be read out directly from the Methodologies description. A little bit more difficult was the assignment of properties to the Category Process and Artifacts, but in case of the Methodologies XP, Scrum and I2 it was possible to derive them out of the Practices. Not difficult, but also not always clear was the assignment of the Values and Principles as the Methodologies seem to use them with different meanings. For Example Simplicity is a Principle of the Agile Manifesto, but a Value in XP. And Scrum does

DOI: 10.1145/2237796.2237803

However, even if we do not have the complete set of relations, the set of categories gives an adequate description of the Methodology. By a deeper analysis of the single Methodologies we find Methodologyspecific formalizations like the observations on priority and size in Scrum or the substitutes in I2.

4.2.3 Completeness of Practices Another point is the completeness of Practices, which means that all relevant aspects of Software Engineering should be covered by an Agile Methodology. XP for example explicitly mentions "programming", which is the key activity with Software Engineering. But Scrum does not mention that. That is why Scrum often is considered as a general Project Management Methodology although it comes from Software Engineering. XP in

http://doi.acm.org/10.1145/2237796.2237803

ACM SIGSOFT Software Engineering Notes

Page 8

opposite to that often is criticized for it's lack of project management Practices. Our model should take this into account by asking for necessary Engineering and Project Management Practices:

∀ necessaryEngineeringPractices ∃ PracticeMethodology ∈P with P = Set of Engineering Practices of Methodology

July 2012 Volume 37 Number 4

5. REFERENCES [1] Chidkamber & Kemere, A Metric Suite for Object-Oriented Programming, MIT Sloan School of Management, 1993 [2] R.Dumke, A.Schmietendorf, H. Zuse, Formal Descriptions of Software Measurement and Evaluation – A Short Overview and Evaluation, University of Magdeburg 2005, http://www-ivs.cs.unimagdeburg.de/sw-eng/agruppe/forschung/paper/FormalM.pdf [3] Manifesto for Agile Software Development, K. Beck et al., 1999, http://www.agilemanifesto.org/

∀ necessaryManagementPractices ∃ PracticeMethodology ∈P with P = Set of Management Practices of Methodology

4.3 Future Work The task for the Future Work is to fine-tune the model e. g. the differentiation or combination of Values and Principles. Maybe it is possible to derive a small set of "Agile Core Concepts" instead of the numerous and abstract Values and Principles. Another task is to find all relations of the examined Methodologies to get a complete description of them. The Completeness can be checked according to the criteria mentioned above. And also necessary Practices for Engineering and Management should be identified.

[4] K. Beck, 1999, Extreme Programming explained: Embrace Change, 1st Edition, Addison-Wesley Professional [5] K. Beck, C. Andres, 2004, Extreme Programming explained: Embrace Change, 2nd Edition, Addison-Wesley Professional [6] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Pearson International Edition, Pearson Education, 2002 [7] M. Leutner et. al., Industrialized Iteration (I2), T-Systems Systems Integration - Internal Documents, 2001-2011 [8] S. Ambler, Quality in an Agile World, September 2005 issue of Software Quality Professional (http://www.asq.org) [9] J. Sutherland, Agile Principles and Values, MSDN Library (http://msdn.microsoft.com/en-us/library/dd997578.aspx) [10] P. Abrahamsson et al., New Directions on Agile Methods: A Comparative Analysis , Proceedings of the International Conference on Software Engineering, 2003

DOI: 10.1145/2237796.2237803

http://doi.acm.org/10.1145/2237796.2237803