Search

Seit Bestehen des Agilen Manifests 2001 bildeten sich vermehrt agile Softwareentwicklungs-Teams, die sich in Aufbau und Funktionsweise voneinander unterscheiden. Viele dieser Teams verteilen sich auf mehrere Standorte. Der Grad der Verteilung kann dabei von „in unterschiedlichen Gebäuden auf einem Firmengelände“ bis hin zu „anderer Kontinent“ reichen. Da das Agile Manifest auf stetige informelle Kommunikation (kurze, unbürokratische Wege) und vergleichsweise wenig Dokumentation setzt, sind bei verteilten Teams Schwierigkeiten und Probleme zu erwarten, wenn die Werte des Manifests konsequent verfolgt werden. Ein verteiltes Softwareentwicklungs-Projekt birgt an sich bereits Risiken (z.B. im Wissenstransfer zwischen den Entwicklern), wobei bei einem verteilten agilen Projekt zusätzliche Probleme auftreten können. Die Fachliteratur befasst sich seit rund 15 Jahren mit dieser Problematik. Befunde empirischer Studien beschreiben verschiedene Problembereiche; zudem werden Lösungswege erläutert. Im gegenständlichen Beitrag wird der aktuelle Stand der Literatur analysiert, um die wichtigsten Problembereiche herauszuarbeiten. Die Beschreibung dieser Problembereiche hilft insbesondere Handlungs- und Entscheidungsträgern in der Praxis, potenzielle Schwierigkeiten verteilter agiler Teams zu erkennen. Dies ist eine wesentliche Grundlage für proaktives Management, um die möglichen negativen Wirkungen zu vermeiden. Since the foundation of the Agile Manifesto in 2001, increasingly more agile software development teams have been formed, which differ in terms of structure and organization. Many of these teams are spread across multiple locations. The degree of distribution can range from “in different buildings on one company site” to “another continent”. As the Agile Manifesto focuses on constant informal communication (short unbureaucratic channels) and comparatively little documentation, difficulties and problems can be expected in distributed teams if one consistently follows the values of the manifesto. A distributed software development project already involves risks (e.g., transfer of knowledge between developers), and additional problems can arise in a distributed agile project. The academic literature has been dealing with this problem for around 15 years. Findings from empirical studies describe various problem areas and solutions are also outlined. The present article analyzes the current state of the literature in order to identify the most important problem areas. The description of these problem areas helps decision-makers in practice to better understand potential difficulties of distributed agile teams. This is an essential basis for proactive management in order to avoid possible negative effects. (VLID)5689629 Version of record

Agile Entwicklungsansätze existieren seit etwa 15 Jahren und haben speziell in der jüngeren Vergangenheit starken Anklang gefunden. Hierbei steht Scrum als eine agile Methode im Fokus. Und das, obwohl Studien zeigen, dass Scrum out-of-the-box für die meisten Unternehmen wenig gewinnbringend ist. Stattdessen besteht die Notwendigkeit einer kontextspezifischen Anpassung. Ergänzend zum Einsatz der agilen Entwicklung als Grundlage des Softwareentwicklungsprozesses bietet die agile Welt die Möglichkeit zur schrittweisen Softwareprozessverbesserung. Die von uns entwickelte Agile Potenzialanalyse stellt eine Möglichkeit dar, den spezifischen Kontext zielgerichtet und angepasst zu analysieren. Es wird untersucht, welcher Grad an Agilität geeignet ist, um den aktuellen Entwicklungsprozess zu verbessern. Die Analysemethode arbeitet mit empirischen Daten, die in einem Modell integriert sind. Das Ergebnis der Analyse ist eine Liste von für den Unternehmenskontext passenden Agilen Praktiken. Diese Liste unterstützt die evolutionäre Transition des Entwicklungsprozesses zu mehr Agilität, um die damit verbundenen unternehmensspezifischen Ziele, wie eine schnellere Reaktionsfähigkeit auf Änderungen, zu adressieren.

Mit der zunehmenden Verbreitung agiler Softwareentwicklung steigt auch die Zahl problematischer Projekte. Ziele wie eine schnelle Reaktionsfähigkeit auf Änderungswünsche werden nicht erreicht, obwohl (vordergründig) nach agilen Grundsätzen vorgegangen wird. Im Artikel fassen wir wiederkehrende Praxiserlebnisse in Form von Anti-Patterns zusammen und schildern, wie agile Entwicklung wiederholt zu dogmatisch gelebt oder als Ausrede für schlechte Projektorganisation missbraucht wurde. Diese Anti-Patterns ermöglichen dem Leser eigene Projekte auf ähnliche Missstände zu prüfen und gegebenenfalls dagegen anzugehen.