Aufrufe
vor 11 Monaten

02 | 2017 public

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

Team 1 Team 2 Team 3

Team 1 Team 2 Team 3 übergreifende Rollen Scrum-Coach Scrum-Coach Scrum-Coach Produktverantwortlicher PO-Support PO-Support PO-Support Product Owner (PO) Build & Deployment Konzeption Teamanalyst (1 x) Teamanalyst (1 x) Teamanalyst (1 x) Lead-Analyse Entwicklung Teamentwickler (2 -3 x) Teamentwickler (2-3 x) Teamentwickler (2-3 x) Lead-Entwickler Lead-Architekt Test Teamtester (2 x) Teamtester (2 x) Teamtester (2 x) Testmanager Abbildung 2: Teamstruktur Das Testmanagement, Lead-Analyse, Lead-Entwicklung, Architektur sowie Build & Deployment sollten außerhalb der Teams agieren (vgl. Abbildung 2). Bereits in der Konzeptionsphase wurde festgestellt, dass eine sofortige Übernahme der Product-Owner-Rollen (PO) durch den Kunden (Fachbereich) aus Kapazitätsgründen nicht möglich war. Daher wurden verfahrensinterne Mitarbeiter, unterstützt durch je einen PO-Support innerhalb der Teams, als PO eingesetzt. Anhand des Release-Plans wurde der frühestens mögliche Beginn der Startphase identifiziert. Wie Abbildung 1 zeigt, korreliert der Termin mit dem Beginn der Umsetzung für das Release (Release-Container 2016/02) und der Qualitätssicherung für das vorhergehende Release (Release-Container 2016/01). Mit dieser Planung konnte die Unterstützung des Managements erfolgreich gesichert und die zweite Phase der Transformation gestartet werden. PHASE 2: INITIALISIERUNG In dieser Phase ist es wichtig, den bestehenden Personalkörper „mitzunehmen“, die essenziellen Ressourcen zu beschaffen und Steuerungs- und Entscheidungsstrukturen einzurichten. Um die im Verfahren tätigen Mitarbeiter in den Veränderungsprozess zu integrieren und Ängste abzubauen, müssen sie kontinuierlich begleitet werden. Hier gelten die für alle Veränderungsprozesse üblichen Regeln: offene Kommunikation über das Vorhaben, die Prozesse und Ziele, kontinuierliche Vorteilsübersetzung, Schulungen und Wissenstransfers etc. Damit für die nächste Phase alle benötigten Personen, Werkzeuge und Budgets bereitstehen, müssen die entsprechenden Ressourcen beschafft werden. Ist für die Transformation zusätzliches Personal nötig, so muss auf zweierlei geachtet werden: Erstens auf die Methodenkompetenz bezüglich agilem Arbeiten sowie die Sozialkompetenz bezüglich der Veränderungen im Denken und Handeln (Mindshift). Dieser Mindshift darf im Team nicht durch die Dominanz neuer, agil erfahrener Kolleginnen und Kollegen „erzwungen“ werden, da sonst der notwendige Mindshift bei den vorhandenen Mitarbeitern bestenfalls „nachgeahmt“ würde. Zweitens müssen die für agiles Arbeiten nötigen Steuerungswerkzeuge, zum Beispiel JIRA, bereits frühzeitig konfiguriert werden und für eine Einarbeitung zur Verfügung stehen. Continuous Integration (CI) sollte – zumindest teilautomatisiert – frühzeitig verwendet werden. Beim Aufsetzen von Steuerungsstrukturen spielt die Größe des Vorhabens eine entscheidende Rolle. Für Vorhaben mittlerer Größe (bis ca. 50 Personen) empfiehlt es sich, ein Steuerungsgremium mit Entscheidungskompetenz und regelmäßigen Abstimmungsrunden zu etablieren. In dieses Gremium berichten Arbeitskreise aller von der Transformation betroffenen Mitarbeiter. Sie erarbeiten inhaltliche Vorschläge zu Fragen, wie die konkrete Verteilung der Bestandsmitarbeiter auf die Teams, die Übernahme von Rollen und (neuen) Aufgaben, Ressourcenbedarfe, die Planung der Fortführung der Pflege und Weiterentwicklung, das Zusammenspiel von Scrum- und Unternehmensprozessesen, den „Zeremonienkalender“. Je nach Wissensstand der Bestandsmitarbeiter sind Arbeitskreise erst mit der Verfügbarkeit neuer Kompetenzträger möglich. 38 | .public 02-17 | Projektmanagement

Im Transformationsprozess des Verfahrens EGOV dauerte die Initialisierungsphase rund drei Monate. Die frühe Verfügbarkeit eines Scrum-Coaches sorgte für das schnelle und effektive Aufsetzen der Steuerungswerkzeuge. Dass er zudem den Mindshift auf breiter Basis förderte, ohne ihn „schulmeisterhaft“ zu erzwingen, erhöhte die Akzeptanz des Vorhabens zusätzlich. Zudem wurden die Bestandsmitarbeiter nach Bekanntgabe und Vorstellung des Transformationsvorhabens intensiv in die konkrete Ausgestaltung einbezogen und konnten über Teamstruktur und -zugehörigkeit mitentscheiden. Damit fand frühzeitig eine hohe Identifikation mit dem Transformationsvorhaben statt. Auch aufgrund des Zeitdrucks hat sich in den Arbeitskreisen schnell ein pragmatisches Vorgehen – zum Beispiel eine Fokussierung auf „80-Prozent-Lösungen“ statt Perfektionismus – herausgebildet. Parallel zu den Arbeitskreisen wurde ein wöchentliches Steuerungsgremium aufgesetzt, in dem das operative und mittlere Management ebenso vertreten waren wie (Software-)Architekten und Scrum-Coaches. Als positiv erwies sich außerdem, einen Vertreter einer bereits agil arbeitenden dritten Organisationseinheit aufzunehmen. Aufgrund des umfangreichen Personalzuwachs wurden bereits in der Initialisierungsphase neue Mitarbeiter gewonnen und in die tägliche Arbeit nach klassischen Prozessen und Strukturen eingebunden. Flexibilität einzuschränken. Diese Ordnungsstruktur verdeutlicht zum einen, für welche Funktionalitäten die Teams zuständig sind. Zum anderen dient sie als Ordnungsstruktur für Testfälle, Dokumen tationen, Schätzungen und Architekturentwürfe. Die Startphase dauerte in EGOV lediglich eineinhalb Monate – drei zweiwöchige Sprints. Teams, die von Beginn an in einem Raum arbeiteten, erzielten deutlich bessere Ergebnisse. Das Rollenverständnis in den Teams war dank der Scrum-Coaches schnell umgesetzt, das der übergreifend agierenden Mitarbeiter anfangs schwierig: Nachdem die Planungs- und Steuerungsverantwortung wegfiel, schwand häufig auch die „Methoden- und Qualitätsverantwortung“. Insgesamt reichte der Findungsprozess bis in die nächste Phase hinein. Da die Leistungsanforderungen nur im ersten Sprint reduziert waren, wurden die Sprintziele jeweils nicht vollständig erreicht. Gleichzeitig erwies sich der gezielte, aber umsichtig aufgebaute Leistungsdruck als förderlich für die Teambildung. Problematisch war die doppelte Testdurchführung, einmal im Team und ein zweites Mal übergreifend, da die hierfür gedachte Testautomatisierung – im Rahmen des Nightly Builds – noch nicht existierte. PHASE 3: STARTPHASE PHASE 4: HOCHLAUFPHASE Hier stehen die tatsächliche Bildung der Teams und das Arbeiten nach den Scrum-Prozessen im Fokus. Der Start wird durch zwei Faktoren erleichtert: zum einen durch die Reduzierung der Leistungsanforderungen an die Teams und zum anderen durch eine Ordnungsstruktur, die die Dynamik von Scrum unterstützt. Die Teammitglieder arbeiten erstmals entsprechend ihrer neuen Rollen und praktizieren die vereinbarten Scrum-Zeremonien. Mit Unterstützung der externen Scrum-Coaches werden die Definition of Done (DoD) und Definition of Ready (DoR) vereinbart und angewendet. Bereits jetzt erfolgt eine erste „Nachjustierung“ beim Rollenverständnis und der Organisation der Zeremonien. Durch reduzierte Leistungsanforderungen wird der Findungsprozess unterstützt. Dabei wird eher die Nichterfüllung der Sprintziele akzeptiert, als eine zu starke Reduzierung der Leistungsanforderungen vorzunehmen. Um Irritationen und Zweifel am neuen Vorgehensmodell zu vermeiden, wird der Fachbereich (Kunde) in dieser Phase nur am Rande beteiligt. Durch die Einführung einer Ordnungsstruktur (zum Beispiel die fachliche Architektur des Verfahrens) wird ein stabilisierendes Element im dynamischen Scrum geschaffen, ohne dabei die Im Fokus dieser Phase stehen sowohl das Erreichen des Standardleistungsniveaus als auch die Integration beziehungsweise das Heranführen des Kunden (Fachbereich) an die neue Organisations- und Arbeitsform. Die kontinuierliche Erhöhung des Leistungsniveaus wird durch ein stetiges Nachjustieren, Tuning und Präzisieren des Arbeitsmodells über alle Bereiche hinweg erreicht. Wichtig ist es, die Historie von geplanten und umgesetzten Storys (Points) je Sprint sowie die Transparenz über deren Veränderung zu beobachten. Doch die Veröffentlichung und der Vergleich zwischen den Teams sind mit Vorsicht zu genießen. Existieren Vorgaben aus dem „klassischen Umfeld“ (Schätzungen und Termine aus dem Anforderungsmanagement), so werden die von den Teams erreichten Werte als Hochrechnungsgrundlage verwendet. Der Fachbereich wird über Refinements und Sprint-Reviews in seiner Rolle als PO einbezogen. Das Tunning des Arbeitsmodells erfolgt durch Justieren der Defintion-of-Done, das Hinterfragen des Rollenverständnisses der beteiligten Mitarbeiter sowie die Erhöhung des Automatisierungsgrades (CI-Kette). Projektmanagement | .public 02-17 | 39

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

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
2016 | 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