Improving Practices in a Small Software Firm: An Ambidextrous Perspective

Despite documented best practices and specialized tools, software organizations struggle to deliver quality software that is on time, within budget, and meets customer requirements. Managers seeking improved software project outcomes face two dominant software paradigms which differ in their emphasis on upfront planning, customer collaboration, and product documentation: plan-driven and agile. Rather than promoting one approach over the other, this research advocates improving software management practices by developing the organization’s ambidextrous capability. Ambidextrous organizations have the ability to simultaneously succeed at two seemingly contradictory capabilities (e.g. discipline and agility) which leads to enhanced organizational performance. Overall, this study asks the question: How can an ambidextrous perspective facilitate improvement in software practices? Driven by this question, and based on a two year action research study at a small software firm, TelSoft, the objectives of this research are to: 1. Identify dualities involved in improving software practices 2. Design interventions based on these dualities to improve software practices 3. Explore the process of becoming an ambidextrous software organization The resulting dissertation consists of a summary and four papers that each identify and address particular dualities encountered during software process improvement. The first paper asserts that both process-driven and perception-driven inquiry should be used during assessment of software practices, presents a model that shows how this combination can occur, and demonstrates the use of this model at TelSoft. The second paper explicates two theories for understanding and resolving issues in requirements engineering practice – repeat-ability and response-ability – and argues for the need to negotiate between the two. The third paper identifies a tension between managing legacy and current processes and proposes a model for software process reengineering, a systematic process for leveraging legacy processes created during prior SPI efforts. Finally, the fourth paper applies the theoretical lens of ambidexterity to understand the overall change initiative in terms of the tension between alignment and adaptability. The study used a variety of data sources to diagnose software practices, including semi-structured interviews, software process documents, meeting interactions, and workshop discussions. Subsequently, we established, facilitated, and tracked focused improvement teams in the areas of customer relations, requirements management, quality assurance, project portfolio management, and process management. Furthermore, we created and trained two management teams with responsibility for ongoing management of SPI and project portfolio management respectively. We argue that these activities improved software practices at TelSoft and provided a stronger foundation for continuous improvement. Keywords: Ambidexterity, software process improvement (SPI), action research, requirements engineering assessment, action planning, software process reengineering, software management

Aus Fehlern in der Softwareentwicklung lernen. Wie durch Fehleranalysen die Prozesse der Anforderungsanalyse und der Qualitätssicherung verbessert werden können

Softwarefehler existieren, seit Menschen Software entwickeln. Fehler können mitunter zu erheblichen wirtschaftlichen Verlusten und im schlimmsten Fall zum Verlust von Leben führen. Viele Fehler können auf Mängel im Prozess der Anforderungsanalyse zurückgeführt werden. Je später ein Anforderungsfehler entdeckt und behoben wird, desto aufwändiger wird die Korrektur. Die vorliegende Arbeit beschreibt, wie aus Fehlern in der Softwareentwicklung gelernt werden kann. Sie beschreibt ein Verfahren zu Fehleranalyse, auf dessen Basis insbesondere Prozesse der Anforderungsanalyse und der Qualitätssicherung verbessert werden können. Ziel der Verbesserungen ist es, Anforderungsfehler und mögliche Folgefehler im Entwurf und der Implementierung zu vermeiden oder zumindest früher zu finden. In dieser Arbeit wird zunächst ein Modell hergeleitet, das erklärt, warum Anforderungsfehler entstehen. Für bestimmte Typen von Anforderungsfehlern werden auf der Grundlage empirische Befunde konkrete Ursachen im Prozess der Anforderungsanalyse aufgezeigt. Dieses Erklärungsmodell ist Bestandteil eines Verfahrens zur Fehleranalyse, das den Anspruch erhebt, über die Auswertung von Fehlern Rückschlüsse über mögliche Ursachen im Prozess zu ziehen. Das Verfahren ist eine Weiterentwicklung der Orthogonal Defect Classification, kurz ODC. ODC wird in der Arbeit ausführlich dargestellt und auf der Grundlage empirischer Befunde kritisch gewürdigt. Das weiterentwickelte Verfahren zur Fehleranalyse wurde im Rahmen einer einjährigen Fallstudie bei dem IT-Dienstleister einer großen deutschen Versicherung erfolgreich angewandt. Hierbei wurden nachträglich reale Fehler von zwei Softwareentwicklungsprojekten einer geschäftskritischen Anwendungssoftware klassifiziert und analysiert, um Verbesserungspotenziale zu identifizieren. Das in der Arbeit entwickelte Verfahren zur Fehleranalyse leistet einen unmittelbaren Beitrag zur Lösung des aufgezeigten Praxisproblems: sie ist ein Instrument, um Prozessmängel der Anforderungsanalyse zu identifizieren, die systematisch Anforderungsfehler und Folgefehler verursachen