Aufrufe
vor 1 Jahr

02 | 2017 public

  • Text
  • Verwaltung
  • Transformation
  • Entwicklung
  • Digitale
  • Unternehmensarchitektur
  • Digitalen
  • Anforderungen
  • Organisation
  • Fachverfahren
  • Mitarbeiter
Schwerpunkt: Agilität und digitale Transformation

Dr. Christian Anhalt ist

Dr. Christian Anhalt ist Leiter des Services für Onlineverfahren im IT-Systemhaus der Bundeagentur für Arbeit. In seinen Zuständigkeitsbereich fallen die Pflege und Weiterentwicklung des Linienverfahrens EGOV sowie des sich aktuell in der Projektentwicklung befindlichen Onlineverfahrens APOLLO. Dr. Anhalt ist seit 2008 bei der BA tätig, unter anderem als fachlicher Architekt und technischer Projektleiter. Seine akademische Ausbildung erfolgte am Lehrstuhl für Wirtschaftsinformatik II der Universität Hohenheim, zuletzt als Forschungsgruppenleiter eHealth. Die Hochlaufphase dauerte in EGOV zweieinhalb Monate. Durch die Einführung weiterer Werkzeuge (CI-Kette, automatisierte Test, statische Codeanalyse [SONAR], Schärfung der DoDs) konnte die Leistungsfähigkeit gesteigert werden. Besonders hat sich bewährt, dass die „fachliche Architektur EGOV“ als Ordnungskriterium für die Zuständigkeit der Teams, die Struktur der Testfälle und die Dokumentation etabliert und sichtbar gemacht wurden, zum Beispiel durch Poster in allen Räumen. Negativ war, dass durch externe Vorgaben (geplante Funktionalität des Releases) die Sprints oft überladen und die Sprintziele nicht erreicht wurden. Dies führte teilweise auch zu Demotivation. Ebenfalls hinderlich war, dass noch keine gesicherte Historie zu den pro Sprint leistbaren und geleisteten Storypoints existierte. Durch die enge Beteiligung über Sprint-Reviews und Refinements funktionierte die Integration des Fachbereichs sehr gut, ohne dass der Kunde als PO agierte. Positiv wirkte sich aus, dass im Team erreichte Ziele, insbesondere Terminziele und Quality Gates, bei den Stakeholdern „vermarktet“ wurden. PO-Boards zur Abstimmung zwischen den verfahrensinternen PO und hochfrequente Scrum of Scrums (SoS) (täglich) förderten die Abstimmung zwischen den Teams und mit den übergreifenden Rollen. Durch wachsendes Engagement aller Beteiligten und Verständnis der Prozesse konnte die anfängliche „80-Prozent-Lösung“ kontinuierlich verbessert werden. PHASE 5: STABILISIERUNGS- & NACHHALTUNGSPHASE Ziel dieser Phase ist es, das erreichte Leistungsniveau nachhaltig zu stabilisieren. Dies muss durch die kontinuierliche Optimierung und Weiterentwicklung der Prozesse wie auch durch eine Sicherstellung der Anwendung des grundsätzlichen SCRUM-Prozesses geschehen. Unterstützende Strukturen und Prozesse der Transformation können nun abgebaut werden. Die Steigerung des Leistungsniveaus erfolgt insbesondere über ein konsequentes Ausfüllen der definierten Rollen im Team, der Schaffung von Transparenz für Teams, dem Management ihrer Performance (Velocity) und der Verbesserung der Toolunterstützung. Die Evolution der Gesamtorganisation und die Optimierung und Weiterentwicklung der Prozesse erfolgen über Communities of Practice (CoP), in die bei Bedarf auch das Management einbezogen wird. Über Sprint Reviews, Berichtsstrukturen und durch in Werkzeugen (JIRA) abgelegte Informationen kann die Nachhaltigkeit der eingeführten Methodik beobachtet werden. Vermieden werden muss, dass das Leben der Scrum-Zeremonien „schleichend“ endet. In dieser Phase hat sich ein Wechsel der Scrum-Coaches als positiv für die weitere Agilisierung des Verfahrens und den Mindshift aller Mitarbeiter herausgestellt. Zudem wurden die Qualitätssicherungsprozesse durch teamübergreifende Reviews erweitert und optimiert. Weitere Optimierungen sind in Planung. ERRORS MADE UND LESSONS LEARNED – WORAUF MAN BESONDERS ACHTEN SOLLTE Im Rahmen des Transformationsprozesses des IT-Verfahrens EGOV wurden folgende Erkenntnisse gewonnen: • Es muss akzeptiert werden, dass das Arbeitsmodell der reinen Scrum-Lehre nie zu 100 Prozent entsprechen wird. Unternehmens- oder verfahrensspezifische Anpassungen sind die Regel, nicht die Ausnahme. • Die Schlüsselrollen für den Transformationsprozess (Scrum- Coaches) müssen, auch gegen Widerstände (Aussage: „Brauchen wir die wirklich, wäre nicht ein weiterer Entwickler besser?“), schnell besetzt werden. Nur so kann der paral- lel stattfindende Mindshift frühzeitig initiiert und kontinuierlich gefördert werden. • Die „Steuerung“ der Teams über DoD, Sprint-Reviews und Refinements will gelernt sein, kann aber durch den Einsatz erfahrener Scrum-Coaches beschleunigt werden. Eine gestufte Einführung von DoD bietet sich an und sorgt dafür, dass der Umgang mit diesem wertvollen Instrument zur Qualitätssteuerung schnell gelernt wird. 40 | .public 02-17 | Projektmanagement

• Die Scrum-Teams benötigen zwingend eigene Räume, damit die Kommunikation im Team und die Durchführung der Zeremonien optimal erfolgen können. Im Idealfall arbeitet das gesamte Team in einem Raum. • Die im klassischen Vorgehensmodell etablierten Strukturen müssen aufgebrochen, die Mitarbeiter in die Teams integriert oder einem Team mit teamübergreifenden Rollen zugeordnet werden. Auch wenn das klassische Scrum die teamübergreifenden Rollen (Produktverantwortlicher, Change- und Release- manager, Testmanager, Lead-Architekt, Lead-Entwickler) so nicht kennt, bieten sie sich bei einem Einsatz in Großunternehmen an: Standards und Reglementierungen können so dem Team besser zugänglich gemacht werden. • Noch aus der alten Struktur stammende „Informationsmonopole“ müssen aufgelöst werden und im Team aufgehen, denn das Team muss auch dann alle Aufgaben erfüllen können, wenn der Informationsmonopolist abwesend ist. • Beim Übergang zum agilen Vorgehensmodell gibt es eine Phase, in der der Softwaretest doppelt belastet ist: einerseits aufgrund der (ein letztes Mal) durchzuführenden Tests nach altem Vorgehen (Wasserfall), andererseits durch die zeitgleich durchzuführenden Tests in den Sprints der interdisziplinären Teams (vgl. Abbildung 1) . • Für übergreifende Tests (Integrationstest, Last- und Performancetest etc.) muss festgelegt werden, ob sie inner- oder außerhalb der Teams durchgeführt werden. • Die teamübergreifende Abstimmung und Zusammenführung der Ergebnisse durch SoS-Meetings, gemeinsame Sprint-Reviews und PO-Board-Meetings sind enorm wichtig. • Auch in Abwesenheitszeiten (Urlaub etc.) muss die Arbeitsfähigkeit der interdisziplinären Entwicklungsteams kontinuierlich sichergestellt sein. Außerdem muss für eine ausreichende „Robustheit“ gegenüber ungeplanten Mitarbeiterausfällen gesorgt werden. Gibt es zum Beispiel nur einen Tester je Team, kann bei dessen Abwesenheit ein erfolgreicher Sprintabschluss (nahezu) unmöglich werden. • Es hat sich bewährt, den Fachbereich in die Sprintreviews einzubeziehen, um die Fachseite unmittelbar am Entwicklungsprozess zu beteiligen und frühzeitig mögliche Fehlentwicklungen erkennen zu können. • Jeweils zu Sprintende ist die Qualität der Aufwandsschätzung zu verifizieren. Dies sollte bereits früh im Transformationsprozess erfolgen, sodass schnell belastbare Erkenntnisse über die Velocity der Teams verfügbar sind. • Der agile Entwicklungsprozess erfordert in jeder Iteration (Nightly Build, Build zu Sprintende) weitreichende Tests, die nur durch den Einsatz von Werkzeugen zur Testautomatisierung erfüllt werden können. • Während es sich bewährt hat, in der Sprintplanung und im Backlog insbesondere vor Inbetriebnahme und nach dem Go-Live des Release Kapazitäten zur Fehlerbehebung einzuplanen, hat sich das Erstellen expliziter User Storys für jeden Fehler nicht bewährt. FAZIT UND AUSBLICK Die Transformation bestehender IT-Verfahren hin zu einem agilen Arbeitsmodell kann anhand der vorgestellten fünf Phasen erfolgreich durchgeführt werden, ohne dass die Pflege und Weiterentwicklung unterbrochen werden müssen. Das Transformationsmodell hat sich in der Praxis bewährt. Im Beispielfall EGOV ist es gelungen, agile Methoden der Softwareentwicklung innerhalb „klassischer“ Rahmenprozesse erfolgreich zu etablieren. Die geforderten fachlichen Anforderungen wurden dabei trotz Transformation ohne Einschränkungen in den geplanten Releases bereitgestellt. Gut ein Jahr nach dem Start des Transformationsprozesses zeigt sich ein stabiles Bild im Verfahren. Prozesse, Rollen und Zeremonien werden auch nach Mitarbeiterwechseln und -wachstum zuverlässig und kontinuierlich gelebt. Eine verbleibende Herausforderung liegt (immer noch) darin, den Mindshift (Kulturwandel) zur agilen Arbeitsweise bei allen Beteiligten abzuschließen. Die Grundlagen hierfür, insbesondere die vorzuweisenden Erfolge des agilen Arbeitsmodells, sind jedoch ausreichend vorhanden.• ANSPRECHPARTNER – DR. CHRISTIAN MIRTSCHINK Lead IT Consultant Public Sector Solution Consulting Projektmanagement | .public 02-17 | 41

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum