Abstract For this paper, we have identified a list of 32 characteristic symptoms that is often discussed during assessments, generated by two experienced assessors who had undertaken maturity assessments in more than 300 companies. We then use cognitive mapping and the “five whys” technique to look beyond the symptoms and reveal the underlying problems or causes of the problems. Following that, we evaluate our findings through the design and evaluation of a web‐based tool where users can score statements based on a formulation of the symptoms. This enables us to recommend to users the areas where they probably need to improve. We designed the tool in three learning cycles of design evaluation and ended up in a summative evaluation where we compared the outcome of using the website tool with a CMMI maturity assessment. We conclude that a systematic quest for symptoms coupled with scoring statements based on the symptoms can point to improvement areas. However, we conclude that doing so is no substitute for a maturity assessment; the scoring of statements cannot reveal the maturity of the organization, but it can quickly and easily point in a useful direction and provide recommendations for going in that direction.

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.

It is well-known that process improvement change requires “tools-processes-people.” Engineers have spent most energy on the tools and processes, but everything is done by people, and success depends on people and their competencies. The increasing focus on people is reflected in many change models; some are discussed in this paper.

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.