Establishing Experience Factories at Daimler-Benz An Experience Report Frank Houdek(‘,*), Kurt Schneider”), Eva Wieser”) {houdek,k.schneider,wieser}~dbag.ulm.daimlerbenz.com “‘Daimler-Benz AG Research and Technology P.O. Box 23 60 89013 Ulm, Germany ABSTRACT The experience factory concept enables systematic learning and continuous improvement in software development. As with most learning initiatives, it is hard to establish. In our experience, there is a great deal of uncertainty and skepticism about the mission and contents of an experience factory. The starting phase is especially endangered through pitfalls or unexpected delays. As expectations vary and there is pres- sure to demonstrate success within only a few months, tension arises which may jeopardize the entire enterprise. In the course of a large-scale software improvement program, we have established three experience factories in different environments of the Daimler-Benz AG within two years. At each site, several application projects are involved. In this paper we describe how we approached the task, what actions we took, and the lessons we learned. Keywords Experience Factory, process improvement, organizational learning, lessons learned. 1 INTRODUCTION At Daimler-Benz AG, software plays a major role in the whole array of products, e.g. Mercedes cars, Airbus air- planes, various reconnaissance systems, space systems or control systems. But software is not only embedded in products. Services such as guarantee management, sales, and administration are software-based as well. Since the 80s more and more functionality has moved from hardware to software. Like many other organizations with a high proportion of embedded real-time software, we have to deal with its exploding size and complexity. Developing this software economically is still problematic [8]. (*‘University of Ulm Faculty of Computer Science Dept. Software Engineering 89069 Ulm, Germany Continuous improvement in this area is indispensable. Due to varying demands, constraints, maturity levels, and de- velopment policies as well as to cultural differences, a one- size-fits-all improvement initiative is inadequate [ 121. In- stead, we have put a special focus on learning from own experiences. We decided to apply the Experience Factory concept (short: EF, [3]), which supports continuous im- provement according to the Quality Improvement Paradigm (QIP, VI). The transfer step is especially essential when applying the QIP, as local improvement actions are expensive. Only when they are exploited more than once, can their fill economic benefit be reaped. As activities for transference, such as packaging, engineering, storing, and retrieving experience, are long-term activities that exceed the scope of a single project, they are usually delegated to the experience factory organization, which is set up and funded independently of projects. It works closely together with the projects by collecting their results and providing concrete support. Figure 1 illustrates this interaction. In this figure, a databasesymbol is used to denote the storage unit of an EF. Here, it is important to note that the EF can be supported by tools (see [9], for instance), however it consists of significantly more than a tool. As part of a large-scale improvement program for software engineering at Daimler-Benz, we are concerned with estab- lishing experience factories in three different business units. Project organization Experience factory Figure I : Interactionbetween EF and project organization. 443 O-8186-8368-6/98 $10.00 0 1998 IEEE