155 research outputs found

    Scaling Scrum - Survey and evaluation of challenges and approaches

    Get PDF
    Diese Arbeit evaluiert die Herausforderungen, denen Scrum bei der Skalierung für große Projekte gegenübersteht. Diese bestehen hauptsächlich aus der Synchronisation der Teams, dem effizienten Auflösen von Abhängigkeiten, dem Sicherstellen von regelmäßiger sowie direkter Kommunikation, der Reduktion von Komplexität sowie dem Fördern und Fordern von regelmäßigem Feedback aller Projektbeteiligten. Abstract Die Herausforderungen unterteilen sich in die Skalierung der Scrum Artefakte, Rollen und Meetings. Für jeden der drei Bereiche werden in dieser Arbeit mehrere Lösungsmöglichkeiten vorgestellt, evaluiert und bewertet. Abstract Neben den Scrum Artefakten, Rollen und Meetings gibt es weitere, querschnittliche Herausforderungen, welche es bei der Skalierung von Scrum zu beachten gilt. Dabei handelt es sich um die Gebiete Softwarearchitektur, Unternehmenskultur, Projekt- und Prozessmanagement sowie Unternehmensstruktur. Abstract Die als starr angesehene Entwicklung einer Softwarearchitektur für ein großes Softwareprodukt steht der agilen Entwicklungswelt gegenüber und auch bei den unterschiedlichen Unternehmenskulturen gibt es Differenzen hinsichtlich der Kompatibilität mit Scrum und dessen Skalierung. Bezüglich der Softwarearchitektur im skalierten Umfeld wurde ein Mittelweg gefunden, der sich als „Enough Design Up Front” betitelt. Dieser stellt einen Kompromiss zwischen dem rein inkrementellen Ansatz des „No Design Up Front” und dem an das Wasserfallmodell angelehnten „Big Design Up Front” dar. Abstract Hinsichtlich der in den Unternehmen vorgefundenen Unternehmenskulturen obliegt es den jeweiligen Vorständen, sich für eine Entwicklung der vorhandenen Unternehmenskultur zu entscheiden oder versuchen, eine gänzlich andere Unternehmenskultur anzustreben. Beide Möglichkeiten können je nach Grad und Ausprägung der vorliegenden Unternehmenskultur mehrere Jahre des Wandels in Anspruch nehmen. Abstract Das Projekt- und Prozessmanagement muss für die Skalierung von Scrum geeignete Teamstrukturen sowie Integrationsstrategien finden, um die Produktinkremente der einzelnen Teams optimal zusammenzuführen. Die in dieser Arbeit vorgeschlagenen Möglichkeiten bieten den Verantwortlichen einige Optionen, müssen jedoch mit Bedacht gewählt und eingeführt werden. Viele dieser Lösungsmöglichkeiten fordern Veränderungen in der Unternehmensstruktur. Der Wandel der Unternehmensstruktur zur Unterstützung der Teams für eine effektive Produktentwicklung stellt somit eine weitere Herausforderung bei der Skalierung von Scrum dar.This paper evaluates the challenges that are faced in scaling Scrum for large-scale projects. These consist mainly of the synchronisation of the teams, the effective resolution of dependencies, the ensuring of regular and direct communication, the reduction of complexity and the support and demand of regular feedback from all stakeholders. The challenges can be divided into the scaling of Scrum artifacts, roles and meetings. For each of the three sections in this paper, several possible solutions are presented, evaluated and given a rating. In addition to the Scrum artifacts, roles and meetings, there are several other cross-sectional challenges that need to be considered in terms of scaling Scrum. These are the areas of software architecture, corporate culture, project and process management and corporate structure. Abstract The development of a software architecture for a large-scale software product can be viewed in terms of rigid faces of an agile development world and also in terms of the different corporate cultures. There are also compatibility differences with Scrum and its scaling. Regarding the software architecture in the scaled environment, a balance has been found, which is referred to a

    EDiT - Enabling Distributed Teams: Eine Methode zur Identifikation und Erschließung von Verbesserungspotenzialen in der standortverteilten Produktentwicklung = EDiT-Enabling Distributed Teams: A method for identifying and exploiting improvement potentials in distributed product development

    Get PDF
    Um die Vorteile der standortverteilten Produktentwicklung ausschöpfen zu können, ist es notwendig, die Herausforderungen der standortverteilten Produktentwicklung frühzeitig zu erkennen und anzugehen. Daher ist das Ziel der vorliegenden Arbeit die Entwicklung einer Methode, die Produktentwicklungsteams dazu befähigt, Verbesserungspotenziale der standortverteilten Zusammenarbeit innerhalb einer Organisation basierend auf der individuellen Entwicklungssituation zu identifizieren und zu erschließen. Dazu wird aufbauend auf den Grundlagen des Stands der Forschung ein Verständnis für die Charakteristika der standortverteilten Produktentwicklung geschaffen. Durch die Analyse möglicher Ursachen von Herausforderungen in standortverteilten Produktentstehungsaktivitäten in den Dimensionen Mensch, Technologie und Organisation werden zunächst Indikatoren möglicher negativer Auswirkungen auf die Effizienz und Effektivität in der standortverteilten Produktentwicklung abgeleitet. Diese werden zu sechs Kritikalitätsfaktoren zusammengefasst: Digitale Infrastruktur, Planung und Prozesse, Entwicklungsteam, Entwicklungsaufgabe, Ressourcenverfügbarkeit sowie Kommunikation und Wissenstransfer. Anschließend werden 10 Handlungsfelder der Produktentwicklung identifiziert, welche einen entscheidenden Einfluss auf den Erfolg von standortverteilten Produktentwicklungsprozessen aufweisen und damit als Stellhebel zum Entgegenwirken der Ursachen negativer Auswirkungen auf die Effizienz und Effektivität dienen. Zu den einflussreichsten Handlungsfeldern zählen Zielverständnis und Vision, Informationen, Daten und Wissensmanagement sowie (virtuelle) Kommunikation und Zusammenarbeit. Anschließend wird anhand des Zielsystems an eine Methode zur Befähigung von Produktenwicklungsteams zur Identifikation und Erschließung von Verbesserungspotenzialen in der standortverteilten Zusammenarbeit die EDiT-Methode (Enabling Distributed Teams) iterativ entwickelt. Die EDiT-Methode unterstützt einen, auf die standortverteilte Produktentwicklung ausgelegten Problemlösungsprozess entlang der SPALTEN-Methode zur kontinuierlichen Verbesserung der standortverteilten Zusammenarbeit. Um die situationsgerechte Anpassung und nutzerzentrierte Anwendung der EDiT-Methode zu unterstützen, wird die Methode in einem Online Leitfaden umgesetzt und mithilfe von vier Anwendungsvarianten Spiel Team Space, Workshop-Anwendung, Retrospektive und individuelle Tools veranschaulicht. Zur Analyse des Beitrags, den die Anwendung der entwickelten EDiT-Methode leistet, wird die EDiT-Methode iterativ in unterschiedlichen Reifegraden sowie in den Validierungsumgebungen Feld, Live-Lab und Labor insgesamt in neun Validierungsiterationen angewendet. Die Auswertung der Validierungsiterationen legt dar, dass sich durch die Anwendung, der in dieser Arbeit entwickelten Methode, individuelle Verbesserungspotenziale der standortverteilten Zusammenarbeit in den Produktentwicklungsaktivitäten identifizieren und erschließen lassen. Dies zeigt sich insbesondere in den quantitativen Nachweisen des Effekts, die statistisch signifikante Verbesserungen in den betrachteten Potenzialfeldern deutlich machen

    Einsatz Domänen-spezifischer Sprachen für Komponenten-basierte Web Anwendungen

    Get PDF
    In Projekten zur Entwicklung verteilter Web-basierter Systeme stellt die Spezifikation der zu entwickelnden Lösung eine zeitintensive Aufgabe dar, bei der häufig Kommunikationsschwierigkeiten zwischen Kunden, Anwendern und Entwicklern auftreten. Domänen-spezifische Sprachen (DSLs) bieten sich hier aufgrund ihrer Nähe zur Problemdomäne und der damit einhergehenden leichteren Erlernbarkeit und Verständlichkeit als ideale Alternative zu schwergewichtigen Modellierungsmethoden an. Dieser Beitrag präsentiert einen Ansatz zur Entwicklung von Web Anwendungen durch Komposition hochgradig konfigurierbarer Fachkomponenten und deren Konfiguration mittels DSLProgrammen

    Einfluss agiler Methoden auf den Erfolgsfaktor. Benutzerakzeptanz in IT-Projekten

    Get PDF
    Ein zentraler Erfolgsfaktor, der für den Nutzen einer IT-Entwicklung maßgeblich sein kann, ist die Akzeptanz des zu entwickelnden Produkts durch die Benutzer. Vor dem Hintergrund dieses wichtigen Erfolgsfaktors wird die Fragestellung untersucht, inwiefern agile IT-Projektentwicklungsmethoden die Akzeptanz der späteren Benutzer, aber auch der am Entwicklungsprozess beteiligten Personen fördern können. Dabei wird insbesondere ermittelt, welche Voraussetzungen agile Methoden schaffen, damit während des Projekts und nach Projektende eine möglichst hohe Benutzerakzeptanz erreicht werden kann. Das Ziel dieser Arbeit ist demnach eine eingehende Betrachtung der Benutzerakzeptanz im Umfeld agiler Methoden sowie eine Beurteilung der Förderung dieses Erfolgsfaktors durch die neuen leichtgewichtigen Ansätze.The user acceptance represents an important success factor for the usefulness of IT development projects. This thesis analyses how agile software development influences the user acceptance of end-users and software producers. Furthermore the author examines the conditions for achieving this important success factor with regard to the development phase but also with regard to the final product. In the end this scientific research presents a detailed analysis of agile development methods and their overall impact on the success factor user acceptance. The author uses several approaches in different categories to point out the importance of user acceptance in all stages of a development process

    Bessere Kundenorientierung bei der Entwicklung physischer Produkte - Nutzung agiler Vorgehensweisen kombiniert mit Additiven Fertigungsverfahren

    Get PDF
    Viele Industrieunternehmen sind auf der Suche nach neuen Strategien für eine zukunftssichernde Produktentwicklung. Die Gründe dafür sind in den Herausforderungen zu suchen, die häufig in schnelle Änderungen von Kundenwünschen, der Verbreitung moderner Informations- und Kommunikationstechnologien, kürzeren Technologielebenszyklen, Forderungen nach ökologischer Nachhaltigkeit wie auch in der weiteren zunehmenden Vernetzung der Wirtschaft zu suchen. Die heutige Entwicklungsumgebung in Unternehmen, mit meist starren Abteilungsstrukturen, wenig Kommunikation mit den Kunden und zwischen den Abteilungen im Unternehmen sowie der Auslieferung eines auf einem einmal erstellen Lastenheft basierenden Produkten wird den Anforderungen nicht mehr gerecht. In diesem Zusammenhang rücken agile Vorgehensweisen gepaart mit additiven Fertigungsverfahren für physische Produkte in den Fokus der Entwicklung

    Agile Entwicklung physischer Produkte 2023: Eine Studie zum aktuellen Stand in der industriellen Praxis

    Get PDF
    In der Entwicklung von mechatronischen Produkten nimmt die agile Entwicklung bereits seit einigen Jahren eine zunehmend wichtigere Rolle ein. Im Rahmen dieser Studienserie wird seit 2018 das Fortschreiten der Agilität in der DACH-Region untersucht. In der vorliegenden Ausgabe des Jahres 2023 liegt der Fokus dem Verständnis und der Anwendung agiler Arbeitsweisen, den Herausforderungen in deren Skalierung und der Bedeutung von Prototyping im genannten Kontext. Die Ergebnisse dieser Studie beruhen, wie auch in den vorangegangenen Jahren, auf den Aussagen von Praktikern aus einem breiten Spektrum an Industrieunternehmen, die an einer Online-Umfrage teilgenommen haben. Die Studie beschreibt sowohl quantitative als auch qualitative Ergebnisse aus der industriellen Praxis

    Ansatz zur Entwicklung von SOLL-Prozess Baukästen für die Instanziierung und Konfiguration von SOLL-Prozess Vorschlägen in der automobilen Vorentwicklung = Approach for the development of target-process module sets for the instantiation and configuration of target-process suggestions in the automotive predevelopment

    Get PDF
    In der vorliegenden Arbeit wird ein Ansatz zur Entwicklung von SOLL-Prozess Baukästen für die agile, situations- und bedarfsgerechte Kombination flexibler und strukturierender Elemente in SOLL-Prozessen vorgestellt. Dieser Ansatz unterstützt Prozessautoren bei der Identifikation von Prozessanforderungen und der Konzipie-rung eines organisationsspezifischen SOLL-Prozess Baukastens. Zudem unterstützt der Ansatz Projektleiter bei der kontextspezifischen Instanziierung und Konfiguration von SOLL-Prozess Vorschlägen, sowie der Erstellung und Adaption von realistischen SOLL-Prozessen. Basierend auf einer Literaturanalyse wird abgeleitet, dass SOLL-Prozesse unsicher-heitsbehafteter Entwicklungsprojekte sowohl flexible wie auch strukturierende Prozesselemente umfassen sollten, wobei die Kombination dieser Prozesselemente kontextindividuell ausgeprägt sein muss. Eine empirische Untersuchung zu den Anforderungen an eine prozessuale Unterstüt-zung in der automobilen Vorentwicklung zeigt das Potential auf, das durch den Einsatz von Prozess Baukästen erschlossen werden kann. Auf Basis des ASD – Agile Systems Design Ansatzes wird ein Ansatz entwickelt, der die Erstellung realistischer SOLL-Prozesse durch den Einsatz von SOLL-Prozess Baukästen in automobilen Vorentwicklungsprojekten unterstützt. Dieser Ansatz wird im Zuge von vier empirischen Untersuchungen in unterschiedlichen Anwendungsbereichen evaluiert. Die erste Studie forciert die Evaluation der grundsätzlichen Realisierbarkeit und Anwendbarkeit des Ansatzes in einer Live-Lab Studie. In der zweiten Studie wird der gesamte Ansatz für die automobile Vorentwicklung der AUDI AG realisiert, angewendet und evaluiert. In der dritten Studie werden ausgewählte Aspekte des Ansatzes in einem automobilen Serienentwicklungsprojekt eines anderen Unterneh-mens realisiert und angewendet, um so Erkenntnisse für eine mögliche Übertragbar-keit zu erhalten. In der vierten Studie werden Experteninterviews mit Prozessautoren aus drei unterschiedlichen Unternehmen der Automobilindustrie durchgeführt, um den Nutzen des Ansatzes aus der Perspektive von Prozessautoren zu evaluieren

    Ein Modell zum Konzept Klarheit gewinnen und dessen Ursachen und Auswirkungen auf die Zusammenarbeit in selbstorganisierten Softwareentwicklungsteams

    Get PDF
    Hintergrund: Agile Softwareentwicklungsteams setzen Scrum unterschiedlich und individuell in der Praxis um. Anleitungen, Leitfäden und Handreichungen aus der Praxis und Forschung verlieren sich in den Details einzelner Werkzeuge,Faktoren oder Teile. Forschungsfrage: Was hält selbstorganisierte Softwareentwicklungsteams zusammen und fördert eine gute Zusammenarbeit? Methode: Es wurde mit Grounded-Theory-Methodologie nach Charmaz geforscht. Es wurden in 5 Scrum-Teams aus der Praxis intensiv Daten erhoben und weitere Interviews und Validierungen mit Expert_innen durchgeführt. Ergebnisse: Es wurde ein Modell entwickelt, das als zentrales Konzept "Klarheit gewinnen" enthält. Erstmals werden bekannte und neue Erkenntnisse zu einem gemeinsamen Modell verbunden und erklären Grundlagen funktionierender Zusammenarbeit in agilen Softwareentwicklungsteams. Fazit: In der Validierung wird deutlich, dass agile Teams das Modell anwenden können, um ihre Zusammenarbeit zu analysieren und zu stärke

    Typical changes at the SCRUM development process

    Get PDF
    Scrum ist eine der weit verbreiteten Vorgehensmodelle zur agilen Softwareentwicklung. Doch so einfach die Regeln auch sind, fällt es vielen Teams schwer diese vollkommen zu verinnerlichen und einzuhalten. Es ist nicht immer möglich allen Grundsätzen von Scrum zu entsprechen und auch nicht nötig dies zu tun. Viele Unternehmen passen Scrum daher an die eigenen Bedürfnisse an. Ziel dieser Bachelorarbeit ist es herauszuarbeiten, welche Anpassungen die Unternehmen getroffen haben und darin Muster zu erkennen. Um die Anpassungen aufzudecken, wurden semi-strukturierte Interviews mit Partnern aus der Wirtschaft durchgeführt. Eine Beobachtung dabei ist, dass das Standard-Scrum, das Ken Schwaber und Jeff Sutherland defniert haben, von keinem Team, das Bestand dieser Arbeit ist, vollkommen gelebt wird. Oftmals liegen die Gründe in der Unternehmensstruktur, dem mangelnden Verständnis von seitens der Unternehmensleitung oder des Teams für Rollen, die keinen aktiven Fortschritt in dem laufenden Projekt erzeugen, und der inkonsequenten Durchführung von Regeln, die dem Team als unwichtig erscheinen. Im Allgemeinen ist zu sagen, dass alle Teams Scrum grundsätzlich korrekt eingeführt haben und es in den meisten Fällen nur Anpassungen gibt, die als nicht-kritisch einzustufen sind. Auffallend ist in jedem Fall, dass mit der Verteilung der Rollen Scrum Master und Product Owner auf einzelne Personen als Vollzeitjob viele Konflikte, die in anderen Teams vorhanden sind, nicht mehr auftreten. Um dies mit einer hohen Wahrscheinlichkeit zu beweisen, weist die Grundgesamtheit von 7 Teams allerdings keine statistische Relevanz auf. Die Untersuchung einer großen Anzahl an Teams könnte eine Weiterführung der Arbeit sein. In diesem Fall sollte man auf einen Fragebogen zurückgreifen, da Interviews sehr zeitintensiv sind.Scrum is one of the common frameworks used for agile software development. Although the rules are simple, many teams have problems to internalize and stick to them completely. It is not always possible or necessary to realize all components of Scrum as they were intended. Many companies changed Scrum according to their requirements. The aim of this bachelor thesis is to distinguish the adaptions of the companies and to recognize patterns. To reveal those adaptions, semi-structured interviews were conducted with partners of the economy. One observation is, that none of the teams, which are considered in the thesis, stick to the rules of the standard of scrum - defined by Ken Schwaber and Jeff Sutherland - to 100%. Therefore the reasons are in many cases the company structure, the lack of comprehension by the management or the team for roles, which don't create an active progress in the current project, and the inconsistent execution of the rules, which seem to be unimportant for the team. But in general all teams adopted Scrum correctly and in most cases the adoptions have an positive impact and don't have an critical impact. Remarkable is, that as soon as the roles Scrum Master and Product Owner are applied as full time job to single people, many conflicts, which are detected in other teams, don't occur any more. But to prove this theory with a high probability, the universe of 7 teams doesn't have a statistical relevance. The investigation of a large number of teams, could be a continuation of this work. In that case a questionnaire should be considered, because interviews are quite time-consuming. Nevertheless, it is necessary to detect the reasons for the adaptions
    corecore