Analyzing Agile Maturity Models: A SPICE Perspective | Essays (high school) Software Engineering

Agile maturity model: analysing agile maturity characteristics from

the SPICE perspective

Tomas Schweigert

,†

, Detlef Vohwinkel

, Morten Korsaa

, Risto Nevalainen

and Miklos Biro

SQS, Cologne, Germany

Delta, Copenhagen, Denmark

FiSMA (Finnish Software Measurement Association), Helsinki, Finland

Software Competence Center Hagenberg GmbH, Hagenberg, Austria

ABSTRACT

The paper discusses structure, quality and content of the currently available agile maturity models. It

presents two approaches on how to deal with such models. As a ﬁrst step of the analysis, the paper contains

a compilation of maturity level naming used by these agile maturity models because the variety of level

naming is a sign of the variety of understanding and of deﬁnition of agile maturity.

While many papers deal with agile from an inside perspective, this paper is written from the perspective

of Software Process Improvement (SPI) and Capability Determination, the European Certiﬁcation and

Qualiﬁcation Association PI Manager Certiﬁcation Scheme and also the SPI Manifesto.

The paper does not explicitly present its own agile maturity model.

The analysisapproaches presented in the papershow that the currently available agile maturitymodels are not

ﬁt for industrial use. The synthesis of an acceptable model seems to be feasible as the analysedmodels address

Received 24 July 2013; Accepted 24 July 2013

KEY WORDS: agile; agilematurity; SPI manifesto;agile manifesto; SPICE; CMMI; SEMAT;ISO/IEC 15504;

EuroSPI; ECQA

1. APPROACH AND METHOD

The following key questions were the starting points for analysing the agile maturity issue:

1. Is an agile maturity model something of relevance?

2. Does a common accepted agile maturity model exist?

3. How would such a model map to Capability Maturity Model Integration (CMMI)?

4. Does this model ﬁt to common accepted standards as stated in ISO/IEC 15504 Part 2?

5. How would such a model map to ISO/IEC 15504 Part 5:2012?

6. If such a model could be found, would it more be like a stairway or more like a spider web?

For the ﬁrst question, a survey was performed. Considering that agile maturity is of high interest, the

results were published in 2012 [1].

To answer the second and third questions, an internet search was undertaken, and its results were

sampled including 40 sources dealing with agile maturity. As completeness criterion, somewhat as a

jackknife algorithm was used, assuming that starting with a Google search and following the links

in the found documents as well as checking given references, no more sources will be found when a

*Correspondence to: Tomas Schweigert, SQS, Cologne, Germany.

†

E-mail: [email protected]

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS

J. Softw. Evol. and Proc. 2013

Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/smr.1617

Partial preview of the text

Download Analyzing Agile Maturity Models: A SPICE Perspective and more Essays (high school) Software Engineering in PDF only on Docsity!

Agile maturity model: analysing agile maturity characteristics from

the SPICE perspective

Tomas Schweigert

,†

, Detlef Vohwinkel

, Morten Korsaa

, Risto Nevalainen

and Miklos Biro

(^1) SQS, Cologne, Germany (^2) Delta, Copenhagen, Denmark (^3) FiSMA (Finnish Software Measurement Association), Helsinki, Finland (^4) Software Competence Center Hagenberg GmbH, Hagenberg, Austria

ABSTRACT

The paper discusses structure, quality and content of the currently available agile maturity models. It

presents two approaches on how to deal with such models. As a first step of the analysis, the paper contains

a compilation of maturity level naming used by these agile maturity models because the variety of level

naming is a sign of the variety of understanding and of definition of agile maturity.

While many papers deal with agile from an inside perspective, this paper is written from the perspective

of Software Process Improvement (SPI) and Capability Determination, the European Certification and

Qualification Association PI Manager Certification Scheme and also the SPI Manifesto.

The paper does not explicitly present its own agile maturity model.

The analysis approaches presented in the paper show that the currently available agile maturity models are not

fit for industrial use. The synthesis of an acceptable model seems to be feasible as the analysed models address

typical organisational processes including life cycle management. Copyright © 2013 John Wiley & Sons, Ltd.

Received 24 July 2013; Accepted 24 July 2013

KEY WORDS: agile; agile maturity; SPI manifesto; agile manifesto; SPICE; CMMI; SEMAT; ISO/IEC 15504;

EuroSPI; ECQA

1. APPROACH AND METHOD

The following key questions were the starting points for analysing the agile maturity issue:

1. Is an agile maturity model something of relevance?

2. Does a common accepted agile maturity model exist?

3. How would such a model map to Capability Maturity Model Integration (CMMI)?

4. Does this model fit to common accepted standards as stated in ISO/IEC 15504 Part 2?

5. How would such a model map to ISO/IEC 15504 Part 5:2012?

6. If such a model could be found, would it more be like a stairway or more like a spider web?

For the first question, a survey was performed. Considering that agile maturity is of high interest, the

results were published in 2012 [1].

To answer the second and third questions, an internet search was undertaken, and its results were

sampled including 40 sources dealing with agile maturity. As completeness criterion, somewhat as a

jackknife algorithm was used, assuming that starting with a Google search and following the links

in the found documents as well as checking given references, no more sources will be found when a

*Correspondence to: Tomas Schweigert, SQS, Cologne, Germany. †E-mail: [email protected]

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS

J. Softw. Evol. and Proc. 2013 Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/smr.

source is found the third time following a chain of links. The result contains one cluster of models that

somewhat refer to CMMI and other models that follow their own maturity approaches. The detailed

preliminary analysis is documented in section 3.

As there was no common accepted agile maturity model found, questions 4 and 5 became more

interesting. The approach and its result are described in section 4.

The first answer of question 6 is mentioned in section 5.

As it was clear that this paper did not have the intention to deliver a complete detailed analysis or a

complete agile maturity model, section 6 deals with some useful follow up actions.

2. THE CURRENT DISCUSSION ON AGILE MATURITY MODELS

While it is common opinion that it is possible for an agile organisation to reach high CMMI® maturity

levels or high Software Process Improvement and Capability Determination (SPICE) Capability levels

[2], it seems that some agile gurus are not happy with the support offered by CMMI or SPICE. As one

of the consequences, we have about 40 different models that call themselves agile maturity models.

There are several types of agile maturity models published, mainly in the Internet. There are also

some principal thoughts published about agile maturity. The discussion about agile maturity is

influenced by ideas of the CMMI® model. See also Schweigert et al. [3].

So it seems to be adequate to group the published agile maturity models into those which are close to

the level structure of CMMI® [4–11], those which have a level structure at all [5, 9, 12–28] and those

which do not use explicit levels [6, 14, 16, 21, 29–41, 61]. A detailed synopsis of level naming can be

found in Schweigert et al. [42].

All of these models have in mind the approach, which was one of the goals of the BOOTSTRAP

methodology about 20 years ago: ‘Change and reorganize the software development and

maintenance activities so that the software production as a whole better complies with business

needs’ [43]. The methods changed, but the goals remain.

This result creates however a heavy challenge for the SPI community. Like at the early times of

SPICE, many models (e.g. ISO 9000, Trillium, TickIT, CMM, BOOTSTRAP, ISO 12207 and ISO

15288) were on the market, and there was no method to make their results comparable.

The need for structured modelling is agreed in the whole IT business (see, e.g. TestSPICE® for the

software testing business [44, 45]).

The challenge for SPICE assessors in an agile environment is the heterogeneity of agile

implementations. So there is a need to distinguish between malpractice and next practice [46]. To do

so, it might be helpful to identify anti-patterns to mark malpractices [47] and also implementation

patterns [48]. Looking deeper into the agile maturity issue, it becomes clear that improving agile

development and management is not only an issue of formal capability or maturity levels but also an

issue of values, emotions and culture [49, 50, 64].

An analysis of the quality of a subset of these agile maturity models was performed by Özcan-Top

[51]. Instead of asking about the naming and content, this analysis took a set of model quality criteria

(fitness for purpose, completeness, definition of agile levels, objectivity, correctness and consistency)

checking if these quality criteria were fully, largely, partially or not fulfilled by the models of Patel [8],

Yin [11], Sidky [27], Benefield [18] and Ambler. As an overall result, it could be said that the rating of

the analysed subset was more or less poor [51].

3. DO AGILE MATURITY MODELS REALLY MEASURE AGILITY?

The first idea, when analysing agile maturity models in detail, was to check which capability or

maturity levels they are supporting. Trying to map the available agile maturity models to capability

indicators of SPICE turned out to be very difficult as many authors of agile maturity models have an

undisciplined wording. So there is no clear connotation if a model describing a level, a process

attribute, a process, an outcome or an indicator is like a base practice. Even a rough analysis shows

that none of the analysed agile maturity models fulfil the requirements of ISO/IEC 15504 Part 2 [60].

TOMAS SCHWEIGERT ET AL.

For each characteristic, the following attributes are applied:

ID
Author
Type: {value, principle, process, purpose, outcome, practice, work product, process attribute

and level}

Article
Content (the extracted statement)

These attributes where placed in an analysis card (A5). About 600 of these cards were prepared for

the agile maturity workshop at the 2012 EuroSPI Conference.

Sometimes, it was not possible to define the exact type of the statement. In this case, more than one

type was chosen.

This approach was pragmatic. There exist more sophisticated approaches [52], and the above one

proved, however, to be effective for the development of a first sample.

During a workshop that took place at the EuroSPI 2012 in Vienna, a subset of 250 characteristics of the

sample was mapped by the participants to ISO/IEC 15504 Part 5 2012 [53]. The detailed result is as follows:

Most important processes:

ORG.1 Life cycle model management

ORG.3 Project portfolio management

ORG.4 Human resource management

ORG.7 Organization management

PRO.1 Project planning

PRO.2 Project assessment and control

It was also found that core software engineering practices were highly relevant.

Even if it was not possible to map the agile maturity characteristics directly to capability levels, it should

be taken into account that the processes mentioned earlier are supporting processes for levels 2 and 3.

If maturity is an organizational topic, which was especially highlighted by Hammer [54], it is

reasonable that some agile maturity models deal either with maturity characteristics or with

organizational processes.

But also often agile maturity models deal with simple software development practices, as shown in

the figure above.

These results lead to the conclusion that agile maturity has a view different from the classic one

regarding capability; however, its approach to process/practice implementation of organizational or

project management processes follows the agile principles.

More research is also important regarding that the definition of agile maturity depends on the

definition of agile [59] itself. It was reported that this definition is also evolving [55]. At the very

end, it must also be taken into consideration that agility is definitely not the ultimate goal but one

important aspect of high performance teams [56, 65].

4. GENERAL INTERPRETATION

Considering the aforementioned results, it is certainly not surprising that several related initiatives were

recently born.

One of these is of [57], consolidating the values and principles that a group of experts within the

EuroSPI (http://www.eurospi.net/) community proposed to be of key significance. The three key

values of the SPI Manifesto are that SPI

‘must involve people actively and affect their daily activities’,
‘is what you do to make business successful’ and
‘is inherently linked with change’.

TOMAS SCHWEIGERT ET AL.

The European Certification and Qualification Association Software Systems SPI Manager Certification

Scheme developed by the authors of this paper, among others, carefully covers these issues [62, 63].

Software Engineering Method and Theory (SEMAT) [58] is an initiative with a high number of

supporters who agree that

Software engineering is gravely hampered today by immature practices. Specific problems include:

The prevalence of fads more typical of fashion industry than of an engineering discipline.
The lack of a sound, widely accepted theoretical basis.
The huge number of methods and method variants, with differences little understood and artifi-

cially magnified.

The lack of credible experimental evaluation and validation.
The split between industry practice and academic research.

The survey results reported in this paper are intimately related to the aforementioned initiatives and

can be considered to validate the general interpreting ideas advanced in the following paragraphs.

It is a general fact that a sound theoretical basis is usually built on mathematical approaches, which

are clearly used in all widely accepted sciences. Let us use analogies from mathematics to characterize

the state-of-the art in process improvement methods.

In mathematics, there can be many interesting statements (usually called theorems, lemmas, etc.), which

are deductively proven to be true (valid) starting from axioms whose truth is taken for granted within the

particular domain of analysis. Still, there are mostly many ways to get from the axioms to the same

theorem. These ways may be very different as far as their elegance (aesthetics), effectiveness and

usability are concerned, which have a definite impact on their capability to extend and generalize the results.

Abstraction, being essential for model building, is a key process in mathematics just as in software

engineering or software process modelling. From the most commonly used mathematical abstraction

called ‘natural number’, to the highly different abstractions used in classical analysis and topology,

all of mathematics shows how the different models applied in given theories can lead to a more or

less elegant and extensible approach to the same or even revolutionarily new concepts.

It is a similar situation we are facing in SPI. We have many different approaches and statements that are

claimed to be effective in leading to the achievement of the same business goals. Nevertheless, SPI is not

rocket science, so the deductive proof of these claims is mostly impossible; by consequence, they must be

and are usually proven empirically, which means inductive reasoning. The reference to best practices in

either agile or heavyweight approaches claimed to be generally effective is clearly inductive reasoning. This

is definitely part of the common theoretical foundation of process improvement whether agile or heavyweight.

The key analogy with mathematics is that there are different ways (CMMI, SPICE, agile maturity

models as discussed in the survey, etc.) to get to the conclusion that a method is effective in leading

to the achievement of business objectives. These ways are just as different in their elegance

(aesthetics) and usability as there are very different approaches in mathematics to the same concepts.

It is also true that elegance (aesthetics) depends on subjective taste, while effectiveness and usability

may be objectively measurable. By consequence, there will always be differences in the opinions

regarding the elegance of approaches while at the same time all parties may measurably support

their claims regarding the effectiveness or usability of their approach.

At this point, we have to recur to one of the key principles applied by SEMAT as well: separation of

concerns. Subjective concerns sucha s elegance (aesthetics), for example, should be separated from

objectively measurable concerns such as effectiveness and usability, especially if the objective

measurements are not differentiating enough. And we are at the heart of the success factors

addressed in [58]: better, faster and happier.

REFERENCES

Biro M, Korsaa M, Nevalainen R, Vohwinkel D, Schweigert T. Agile maturity model. Go back to the start of the cycle, industrial proceedings of the 2012 EuroSPI conference pp 5.9–5.30.
Bianco C. Agile and SPICE Capability levels. in O Connor, Rout, Mc Gaffery, Dorling, Software Process Improve- ment and Capability Determination, 11th International SPICE Conference Proceedings, S. 181ff
Schweigert T, Korsaa M, Nevalainen R, Vohwinkel D, Biro M. Agile maturity model: oxymoron or the next level of understanding. Proceedings of the SPICE 2012 Conference, pp 289–294.

AGILE MATURITY CHARACTERISTICS

Malik N. Simple lifecycle agility maturity model. Web Publishing. http://blogs.msdn.com/b/nickmalik/archive/2007/ 06/23/simple-lifecycle-agility-maturity-model.aspx
Pettit R. An “agile maturity model?”, 2007. Web publishing. http://www.agilejournal.com/articles/columns/ the-agile-manager/52-an-qagile-maturity-modelq
René R. Corporate Foresight. Physica Verlag: Heidelberg, 2011.
Royce W. Improving software economics, Top 10 principles of achieving agility at scale. IBM Rational White Paper, Web Publishing. http://www.agilejournal.com/pdf/RAW14148USEN.pdf
Sehlhorst S, Blain T. Agile maturity model—what’s next? Web publishing. http://tynerblain.com/blog/2009/06/30/ agile-maturity-model/
Waters K. 10 key principles of agile software development. Web publishing. http://www.agilejournal.com/resources/ directory?sobi2Task=sobi2Details&catid=10&sobi2Id=
Schweigert T, Vohwinkel D, Korsaa M, Nevalainen R, Biro M. Agile maturity model: a synopsis as a first step to synthesis. in Fergal McCaffery, RoryV. O’Connor, Richard Messnarz (Eds.), Systems, Software and Service Process Improvement, Proceedings of the EuroSPI 2013 Conference, Heidelberg, Dordrecht, London, New York (Springer) 2013; 214–227.
Kuvaja P, Simila J, Krzanik L, Bicego A, Saukkonen S, Koch G. Software Process Assessment & Improvement, The BOOTSTRAP Approach. Blackwell: Oxford, 1994.
Blaschke M, Philipp M, Schweigert T. The Test SPICE Approach. Test process assessments follow in the footsteps of software process assessments, Testing Experience, S.56.
Steiner M, Blaschke M, Philipp M, Schweigert T. Make test process assessment similar to software process assess- ment—the Test SPICE approach. Journal of Software Maintenance and Evolution: Research and Practice Article first published online: 25 AUG 2010. DOI: 10.1002/smr.
Kruse P. Next Practice. Gabal: Offenbach, 2004.
Brown WJ, Malveau RC, McCormick III HW, Mowbray TJ. Anti Patterns. mitp: Bonn. 2004.
Elssamadisy A. Agile Adoption Patterns a Roadmap to Organizational Success. Addison Wesley: Boston USA,
Lundak J. Agile Prozesse. Fallstricke erkennen und vermeiden, Frankfurt (entwickler.press) 2009.
Beck K. Extreme Programming. Addison Wesley: Das Manifest, München, Boston, San Francisco, Harlow, Don Mills, Sydney, Mexco City, Madrid, Amsterdam, 2000.
Ozcan-Top O, Demirörs O. Assessment of agile maturity models. A multiple case study in Tanja Woronowicz, Terry Rout, Rory V. O’connor, Alec Dorling Eds. Software Process Improvement and Capability Determination, Proceed- ings of the 13 th^ international Conference SPICE 2013, Heidelberg, Dordrecht, London, New York (Springer) 2013.
Jeners S, Lichter H, Dragomir A. Towards an Integration of Multiple Process Improvement Refernce Models Based on Automated Concept Extraction. Proceedings of the EuroSPI 2012 Conference pp. 205–216.
ISO/IEC 15504 Part 5:2012. An exemplar Process Assessment Model.
Hammer M. The Process Audit. Harvard Business Review 4/2007, Published online at http://hbr.org/2007/04/the- process-audit.
Laanti M, Similä J, Abrahamsson P. Definitions of agile software development and agility. in Fergal McCaffery, RoryV. O’Connor, Richard Messnarz (Eds.), Systems, Software and Service Process Improvement, Proceedings of the EuroSPI 2013 Conference, Heidelberg, Dordrecht, London, New York (Springer) 2013; 247–258.
Kettunen P. The many facets of high-performing software teams, a capability based analysis approach. in Fergal McCaffery, RoryV. O’Connor, Richard Messnarz (Eds.), Systems, Software and Service Process Improvement, Proceedings of the EuroSPI 2013 Conference, Heidelberg, Dordrecht, London, New York (Springer) 2013; 131–142.
Pries-Heje J, Johansen J, et al. (eds.). SPI Manifesto. Alcala 2010, Version A.1.2.2010. http://www.eurospi. net/images/documents/spi_manifesto.pdf (accessed: 21/02/2012)
Jacobson I, Huang S, Kajko-Mattsson M, McMahon P, Seymour E. Semat—three year vision. Web Publishing. http://semat.org/wp-content/uploads/2012/03/Semat_-_Three_Year_Vision13Jan12.pdf (accessed: 21/02/2012)
K Beck, et al. Agile Manifesto. 2001. http://agilemanifesto.org/
ISO/IEC 15504 Part 2:2003. Guidance on use for process improvement and process capability determination.
King J. A mathematical formula to make agile work. Web Publishing. http://kingsinsight.com/2011/07/14/a-mathe- matical-formula-to-make-agile-work/#more-
Korsaa M, Biro M, Messnarz R, Johansen J, Vohwinkel D, Nevalainen R, Schweigert T. The SPI Manifesto and the ECQA SPI manager certification scheme. Journal of Software Maintenance and Evolution: Research and Practice, published online: 25 AUG 2010. DOI: 10.1002/smr.
Korsaa M, Johansen J, Schweigert T, Vohwinkel D, Messnarz R, Nevalainen R, Biro M. The people aspects in modern process improvement, published online: 2 NOV 2011. DOI: 10.1002/smr.
Rothman J. Where is agile going?, 2011. Web publishing. http://www.slideshare.net/johannarothman/where-is-agile- going-withculture
Wagner KW, Patzak G. Performance Excellence, Der Praxisleitfaden zum effektiven Prozessmanagement. Hanser: München, 2007.

AGILE MATURITY CHARACTERISTICS

AUTHORS’ BIOGRAPHIES

Tomas Schweigert has studied law at Cologne (Germany) University and joined SQS in

He has worked as software and systems testing expert; sometime in 1996, he fo- cused his career on process assessment and process improvement. He is now senior prin- cipal consultant at SQS, head of the ECQA Job Role Committee ‘SPI Manager’ and member of the Test SPICE special interest group. He holds certificates as INTACS SPICE Principal Assessor, PMP and V-Model XT Process Engineer. He is also a well-known conference speaker and tutor at the SPICE and EuroSPI conference series.

Detlef Vohwinkel is the manager of the Process Intelligence Competence Center and is responsible for servicing the support of the clients in the process assessment and improvement sectors in the whole of Europe. His main duties and responsibilities include the implementation of assessments and the organization and support of process modifica- tions for the SQS clients. This also includes organizing trainings in this sector. He is a rep- resentative of the SQS in the advisory board of INTACS™, Business Point of Contact of the SEI for the CMMI Product Suite member in the Steering Group of the SIG Test SPICE. Detlef Vohwinkel studied business economics at the University of Cologne and his degree focused on business informatics.

Morten Korsaa is a specialist at DELTA, a Danish research and consultancy company. He was part of the research team behind the ImprovAbility model and is now responsible for bringing the research to the market as support to ensure success with improvement projects. Mr Korsaa has worked as a global SPI manager in a large telecom company and has acted as a consultant in supported companies from 20 people to it departments of 3500. He has performed more than 100 assessments in both vendor and acquire orga- nisations. Mr Korsaa is SEI certified ‘Introduction to CMMI Instructor’ and a strong pro- moter for agile development in the medical sector.

Mr. Risto Nevalainen (licensed technician) has long experience in software measure- ment and quality topics. He has been managing director of Spinet Oy for the last 10 years. He is also senior advisor in the Finnish Software Measurement Association (FiSMA). His working experience includes position as managing director of Finnish Information Tech- nology Development Center during 1989–1995. Before that, he had different research and management positions, for example, in Technical Research Centre (VTT) and Technical University of Helsinki (HUT). Mr Nevalainen has participated in ISO/IEC 15504 (SPICE) standard development since the beginning. He is competent SPICE assessor and ISO lead assessor. Mr Nevalainen is the head of Delegation of Finland in software and systems engineering standardization in ISO/IEC JTC1 SC 7 subcommittee.

Dr. Miklos Biro is the key researcher and scientific head of the Process and Quality Engineer- ing Research Focus at the Software Competence Center Hagenberg GmbH (SCCH, Austria), a full professor (Ordentlicher Hochschulprofessor in German) nominated by the Prime Minister of Hungary, with a Doctor Habilitatus degree (Corvinus University of Budapest) with software engineering, university teaching (including professorship in the USA), research and manage- ment experience. He holds a PhD degree in Mathematics (Loránd Eötvös University in Buda- pest) and a Master of Science degree in Management (Purdue University, USA). He is fluent in Hungarian, English and French languages. He has initiating and managing roles in numerous European projects. He has authored various Hungarian and English language books and pub- lications. He is the founding president of the professional division for Software Quality Man- agement of the John von Neumann Computer Society, Hungarian national representative in IFIP TC-2 Software: Theory and Practice. He has become chair of professional conferences and a member of programme committees and journal editorial boards.

Analyzing Agile Maturity Models: A SPICE Perspective, Essays (high school) of Software Engineering

Related documents

Partial preview of the text

Download Analyzing Agile Maturity Models: A SPICE Perspective and more Essays (high school) Software Engineering in PDF only on Docsity!

Agile maturity model: analysing agile maturity characteristics from

the SPICE perspective

Tomas Schweigert

, Detlef Vohwinkel

, Morten Korsaa

, Risto Nevalainen

and Miklos Biro

ABSTRACT

The paper discusses structure, quality and content of the currently available agile maturity models. It

presents two approaches on how to deal with such models. As a first step of the analysis, the paper contains

a compilation of maturity level naming used by these agile maturity models because the variety of level

naming is a sign of the variety of understanding and of definition of agile maturity.

While many papers deal with agile from an inside perspective, this paper is written from the perspective

of Software Process Improvement (SPI) and Capability Determination, the European Certification and

Qualification Association PI Manager Certification Scheme and also the SPI Manifesto.

The paper does not explicitly present its own agile maturity model.

The analysis approaches presented in the paper show that the currently available agile maturity models are not

fit for industrial use. The synthesis of an acceptable model seems to be feasible as the analysed models address

typical organisational processes including life cycle management. Copyright © 2013 John Wiley & Sons, Ltd.

KEY WORDS: agile; agile maturity; SPI manifesto; agile manifesto; SPICE; CMMI; SEMAT; ISO/IEC 15504;

EuroSPI; ECQA

1. APPROACH AND METHOD

The following key questions were the starting points for analysing the agile maturity issue:

1. Is an agile maturity model something of relevance?

2. Does a common accepted agile maturity model exist?

3. How would such a model map to Capability Maturity Model Integration (CMMI)?

4. Does this model fit to common accepted standards as stated in ISO/IEC 15504 Part 2?

5. How would such a model map to ISO/IEC 15504 Part 5:2012?

6. If such a model could be found, would it more be like a stairway or more like a spider web?

For the first question, a survey was performed. Considering that agile maturity is of high interest, the

results were published in 2012 [1].

To answer the second and third questions, an internet search was undertaken, and its results were

sampled including 40 sources dealing with agile maturity. As completeness criterion, somewhat as a

jackknife algorithm was used, assuming that starting with a Google search and following the links

in the found documents as well as checking given references, no more sources will be found when a

JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS

source is found the third time following a chain of links. The result contains one cluster of models that

somewhat refer to CMMI and other models that follow their own maturity approaches. The detailed

preliminary analysis is documented in section 3.

As there was no common accepted agile maturity model found, questions 4 and 5 became more

interesting. The approach and its result are described in section 4.

The first answer of question 6 is mentioned in section 5.

As it was clear that this paper did not have the intention to deliver a complete detailed analysis or a

complete agile maturity model, section 6 deals with some useful follow up actions.

2. THE CURRENT DISCUSSION ON AGILE MATURITY MODELS

While it is common opinion that it is possible for an agile organisation to reach high CMMI® maturity

levels or high Software Process Improvement and Capability Determination (SPICE) Capability levels

[2], it seems that some agile gurus are not happy with the support offered by CMMI or SPICE. As one

of the consequences, we have about 40 different models that call themselves agile maturity models.

There are several types of agile maturity models published, mainly in the Internet. There are also

some principal thoughts published about agile maturity. The discussion about agile maturity is

influenced by ideas of the CMMI® model. See also Schweigert et al. [3].

So it seems to be adequate to group the published agile maturity models into those which are close to

the level structure of CMMI® [4–11], those which have a level structure at all [5, 9, 12–28] and those

which do not use explicit levels [6, 14, 16, 21, 29–41, 61]. A detailed synopsis of level naming can be

found in Schweigert et al. [42].

All of these models have in mind the approach, which was one of the goals of the BOOTSTRAP

methodology about 20 years ago: ‘Change and reorganize the software development and

maintenance activities so that the software production as a whole better complies with business

needs’ [43]. The methods changed, but the goals remain.

This result creates however a heavy challenge for the SPI community. Like at the early times of

SPICE, many models (e.g. ISO 9000, Trillium, TickIT, CMM, BOOTSTRAP, ISO 12207 and ISO

15288) were on the market, and there was no method to make their results comparable.

The need for structured modelling is agreed in the whole IT business (see, e.g. TestSPICE® for the

software testing business [44, 45]).

The challenge for SPICE assessors in an agile environment is the heterogeneity of agile

implementations. So there is a need to distinguish between malpractice and next practice [46]. To do

so, it might be helpful to identify anti-patterns to mark malpractices [47] and also implementation

patterns [48]. Looking deeper into the agile maturity issue, it becomes clear that improving agile

development and management is not only an issue of formal capability or maturity levels but also an

issue of values, emotions and culture [49, 50, 64].

An analysis of the quality of a subset of these agile maturity models was performed by Özcan-Top

[51]. Instead of asking about the naming and content, this analysis took a set of model quality criteria

(fitness for purpose, completeness, definition of agile levels, objectivity, correctness and consistency)

checking if these quality criteria were fully, largely, partially or not fulfilled by the models of Patel [8],

Yin [11], Sidky [27], Benefield [18] and Ambler. As an overall result, it could be said that the rating of