1 Introduction The improvement of the quality of software development processes is frequently searched through a formal definition of the work practices involved. As expressed in the well-known Capability Maturity Model Integration (CMMI), a rigorous process description should clearly state its “purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, and exit criteria” (CMMI, 2006). In this way, formal process descriptions combined with efforts to quantitative measurement and continuous optimization of processes are regarded as key factors to process improvement 1 . However, whilst compliance with formal process descriptions would lead to more predictability about characteristics of products and services yielded (and the associated resources required), a “blind” attachment to previous ways of working is harmful to the process flexibility, diminishing responsiveness to new, unexpected situations (Krause et al., 2006, p. 272). Indeed, research on management and organization studies have controversially debated the trope organizational flexibility in the last years (Tienari and Tainio, 1999), with the common claim that organizational form cannot be fixed, but is rather an emergent property of relationships, such that “we must allow [organizational] form to change at a moment’s notice” (Lee and Hassard, 1999, p. 401). As for the field of software development, there has been recently great attention to agile development techniques (Cockburn, 2002) that strive to give flexibility to software development by employing light-weight methods and rather informal processes with focus on “the use of light-but-sufficient rules of project behaviour and the use of human- and communication- oriented rules” (Cockburn, 2002, p. 8). Looking at these two battle fronts, a software engineer may well pose her/himself the question: could we combine these two requirements (namely formalisation of processes and flexibility) in order to improve quality of software development processes? 2 Or are they contradictory, even mutually exclusive? From the viewpoint of the process definition, combining the two types of requirements above would imply elaborating process descriptions (and ways of dealing with them) to support practice with cumulative results of past experience, whereas at the same time keeping space for improvement and innovation that responds to changing situations and environment. In order to reason about how could a process improver achieve (or not) such acrobatic feat, we need a Scientia Interdisciplinary Studies in Computer Science 18(1): 15-23, January/June 2007 © 2007 by Unisinos Formal models, flexible processes? Lessons from a socio-technical analysis of business process modelling João Porto de Albuquerque, Marcel Christ University of Hamburg, Department of Informatics Vogt-Kölln-Str. 30, D-22527 Hamburg {porto, christ} @informatik.uni-hamburg.de Abstract In order to achieve quality in software development processes, it has been argued that one must not only rely upon rigorous descriptions and models of processes to consolidate past experience, but also maintain flexibility in responding to new, unexpected situations. Aiming at examining the relationship between formal process models and flexibility, this paper presents a socio-technical analysis of a business process modelling project in an aircraft maintenance company. This analysis dialogues with works on the actor-network tradition, concluding that the relation between formal models and flexible processes is complex and multi-dimensional, and thus offering resources for a more comprehensive perspective of process modelling projects. KEY WORDS: software quality, formal models to software engineering. 1 As reflected by the capability and maturity levels of CMMI (CMMI, 2006). 2 Indeed, that is the question posed by Boehm and Turner (2003) in their comparative analysis of plan-driven and agile approaches.