Diebold, PhilippSimon, FrankLinssen, OliverMikusz, MartinVolland, AlexanderYigitbas, EnesEngstler, MartinFazal-Baqaie, MasudKuhrmann, Marco2021-02-022021-02-022019978-3-88579-692-3https://dl.gi.de/handle/20.500.12116/34853Dass agile Entwicklungsvorgehen signifikante Vorteile aufzeigen können, ist mittlerweile flächendeckend akzeptiert. Dass dies allerdings noch lange nicht in allen Organisationen umgesetzt ist, muss nicht zwangsläufig ein Problem des fehlenden Wollens sein: Überall finden sich Parameter, die dagegen sprechen, Agilität mittels Scrum als reine Lehre umzusetzen. Können manche dieser Parameter ggfs. noch direkt durch die Organisation verändert werden, so existieren gerade aus dem Bereich der Compliance und dort insbesondere aus dem Fokusbereich der Security viele Parameter, die manche Agilität schlichtweg verbieten. Dies führt häufig entweder zu einer grundlegenden Ablehnung, zu einer nicht umsetzbaren Agilität (nicht können) oder zu einer nicht erlaubten Agilität (nicht dürfen). Deshalb schlagen wir hier einen modularen Agilitätsansatz auf Basis von 5 Schritten vor: Zuerst werden die Ziele, die immer hinter der Einführungsidee von Agilität stehen (sollten), analysiert. Schritt 2 und 3 listen dann die Projekt- und Organisationsparameter, die wesentlich über das Können und Dürfen entscheiden. In Schritt 4 werden dann die zielführenden, möglichen und erlaubten agilen Methodenbausteine zur Zielagilität ausgewählt, deren Transition dann im letzten Schritt 5 Schritt-für-Schritt geplant wird.deAgile Entwicklungagile Bausteineagile PraktikenScrumComplianceSecurityText/Conference Paper1617-5468