Since the beginning of the 1990s, process improvement was considered as a formal issue. Focus was on process description, and improvement was a somewhat better description. Also, process improvement was driven by the customer side. Currently, we see a move forward to focus on people because they are recognised as key success factors. The first model that really emphasised the ownership and empowerment of people was the Process and Enterprise Maturity Model (PEMM) model of Michael Hammer [14]. In the IT community, Ivar Jacobson [15] developed his approach while criticising the current process description approach. At the same time, Jan Pries-Heje did research related to effective Software Process Improvement (SPI) approaches [6].In 2007, a first attempt was made to develop a training curriculum for SPI Management. From the very beginning, it was clear that people are a key factor to be addressed. This process of reorientation of the SPI community reached a milestone, when the SPI manifesto [12] was published and the Skill Card for the SPI Manager Qualification Scheme was approved by the authorised Job Role committee. Right now, the first training is delivered and experience is excellent.

SUMMARY Software process improvement (SPI) can be seen as a profession having its own competence needs and its own community of interest. European projects EQN and EU Cert have defined skill sets and a common certification scheme for about 20 professions, mainly in the IT domain. European Certification and Qualification Association ECQA is created to manage certification and provide the necessary infrastructure. A common way to approach the IT domain from a process perspective is the ‘3S’ concept (Software, Systems, Services). Software process can be seen as the first spearhead among these. The first software process models, such as CMM and SPICE, have already existed for about 20 years. With all the experience that the models bring, it is reasonable to start the PI profession from the software process. Software Process Improvement Manager (SPI Manager) is one of the new topics in ECQA. The development of the SPI Manager training and certification scheme has been done in many small steps so far. This paper explains the current structure and the main components of SPI Manager competences, training needs and the certification scheme. Several other schemes will be developed in the future for process improvement‐related competences. The current version of the SPI Manager skill set is mainly based on software, systems and service processes and their related reference models. It could also be used in the future in domains other than IT. Copyright © 2010 John Wiley & Sons, Ltd.

No abstract

No 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. 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