The Oregon Software Development Process Till Sch¨ ummer 1 and Robert Slagter 2 1 Computer Science Department, FernUniversit¨at in Hagen, Universit¨atsstrasse 1, 58084 Hagen, Germany Till.Schuemmer@fernuni-hagen.de 2 Telematica Instituut, P.O. Box 589, 7500 AN, Enschede, The Netherlands Robert.Slagter@telin.nl Abstract. User participation is still a difficult topic in software develop- ment. Based on the results of the Oregon experiment in construction we propose a novel development process – the Oregon Software Development Process. The process focusses on patterns to empower end-users so that they can make well-informed design decisions and tailor their environ- ments. The four core principles of the process – participation, piecemeal growth, patterns, and diagnosis – are discussed and first anecdotal usage experiences are provided. 1 Introduction Although many technical problems in software development have been solved over the last twenty years, we still observe a lack of support for end-user partici- pation. While most modern software development processes highlight the impor- tance of considering all different stakeholders, it is still a difficult task to actively involve the end-user. Especially the knowledge transfer to end-users is difficult. We therefore propose the adaptation of a design process known in construction as the Oregon experiment. This design process combines aspects that are typically left unrelated. To give an overview, these aspects are: end-user participation, as it is present in a participatory design approach [12], piecemeal growth in short iterations, which is proposed by most iterative pro- cesses [5], especially the eXtreme Programming methodology [4], adaptability that is typically achieved by composing software out of indepen- dent functional building blocks (software components [15]) that are plugged into a framework, pattern oriented application design, which is represented by design pat- terns [9], and end-user tailorability that is proposed by recent literature to handle the changing needs and personal preferences [11]. This paper first summarizes how the design process worked in the Oregon experiment. It will then compare the process with the XP methodology as one representative for agile processes.