Agile Coach, Scrum, Kanban, XP, Lean, Theory of Constraints, Multi-Projektmanagement, Portfoliomanagement

Situation:

• Kunde SDV steht als Dienstleister einerseits unter enormem Innovations­druck, wird Erwartungshaltung seitens der Auftrag­geber-Banken schwer gerecht.
• Prozesse sind andererseits schwerfällig und bürokratisch, insbes. seit Verschärfung der Compliance-Anforderungen seitens Bankenaufsicht (BaFin) in Folge der weltweiten Banken- und Finanzkrise ab 2008.
• SDV hat den Ruf, für Projekte jeglicher Größenordnung immer (zu) lange zu brauchen.
• Projekte werden nach klassischem Wasserfall-Verfahren geplant und durchgeführt: ohne vollständiges, bank­fachliches Konzept kein Softwarekonzept, ohne SWK keine Implementierung, am Ende der Entwicklung folgt eine sehr lange Testphase, Inbetriebnahme muß mit vielen Monaten Vorlaufzeit angemeldet werden.
• Herausforderung: agilere Prozesse in stark reguliertem Umfeld.
• Voriges großes sog. "Scrum-Projekt" läuft alles andere als agil (Banken leben nicht die Product Owner-Rolle, noch kein öffentliches Produkt-Release nach fast drei Jahren), daher Zweifel, ob agile Methoden sich überhaupt bei SDV einsetzen lassen.
• Nächstes großes Projekt auf der Agenda ist OKVS, in dem einerseits die bislang separaten Produkt-Vertriebskanäle für z.B. Girokonto, Baufinan­zierung, Privatkredit vernetzt werden sollen, um nahtlose Kanalwechsel (z.B. von Smart­phone zu Desktop-PC, Call Center oder Filiale) innerhalb eines Produkts zu ermöglichen.
• Andererseits soll der bislang nicht existente Kanal Mobil/Smartphone überhaupt erst aufgebaut werden: responsive Webseite, die sowohl auf dem Handy als auch später auf dem Desktop/Tablet gut aussieht und sich dynamisch an die Displaygröße anpaßt.
• Bei einer geschätzten Projektlaufzeit von drei Jahren wünschen die Banken frühere Releases wichtiger Kern­funktionalitäten statt des üblichen Big-Bang-Verfahrens mit großem Release am Ende des Projekts.
• [Name auf Anfrage] wird beauftragt, ein agiles Projekt so aufzusetzen, daß die schlechten Erfahrungen vorherigen "agilen" Projekts vermieden werden und tatsächlich sehr schnell nutzbarer Geschäftswert entsteht, den man produktiv setzen und daraus Nutzen ziehen kann.

Maßnahmen

• Die 12 Regionalbanken der Sparda-Gruppe delegieren alle Entscheidungen an einen Lenkungsausschuß mit Vertretern von nur 3 Pilotbanken plus SDV und Sparda Consult (SC), anstatt sich, wie üblich, immer in der großen Runde einigen zu müssen.
• SC setzt ein Product Owner Team (PO-Team) aus Bankmitarbeitern und einem externen Scrum Coach als Chief Product Owner auf.
• [Name auf Anfrage] setzt unter meiner Leitung bei SDV ein interdisziplinäres Scrum Team auf, bestehend aus o.g. PO-Team, in- und externen Entwicklern sowie weiteren Fachleuten von SC und SDV, welches vor Ort in einem großen Raum eng zusammenarbeitet. Dies ist das erste Sparda-Projekt, bei dem jemals Bankmitarbeiter und Entwickler direkt zusammengearbeitet haben.
• Scrum Training und fortlaufendes Vollzeit-Coaching für alle Projektmitarbeiter
• Die Verantwortung für das Recruiting externer Entwickler wird an mich delegiert, da ich anscheinend ein "gutes Händchen" dafür habe, gute Mitarbeiter auszuwählen.
• Ich übernehme neben dem Coaching und der Beratung des Managements bei SDV und SC auch die Rolle des Scrum Masters.
• Einführung agiler Entwicklungspraktiken: hoher Grad an Testautomation bis hin zu automatisieren Abnahmetests, Pair Programming, Continuous Integration, Feature Branch Workflow, Limitierung der WIP (work in progress) gemäß Kanban-Modell zur Vermeidung schädlichen Multitaskings.
• Einführung moderner Tools: Spock & Geb für Testauto­mati­sierung statt JUnit & Selenium, Git zur Versionsverwaltung statt Subversion (SVN), Jenkins mit Continuous Builds für jeden Commit statt nur Nightly Builds, Maven statt Ant für Build & Dependency Manage­ment, IntelliJ IDEA statt Eclipse, Jira Agile mit vom SDV-Standard abweichen­dem, vereinfachtem, auf agile Methoden angepaßten Workflow.
• Verzicht auf bankfachliches und Software-Konzept, statt­dessen agiles Requirements Engineering mittels User Stories, welche direkt von den Bankmitarbeitern des Scrum Teams geschrieben werden.
• Einführung projektbegleitender Abnahmetests im laufenden Sprint durch das PO Team pro User Story
• Etablierung zweiwöchiger Scrum Sprints, jeweils mit Lieferung eines lauffähigen, getesteten, abgenommenen Releases am Sprint-Ende.
• Kampf für mehr Autonomie des Entwickler-Teams bei tech­nischen Entscheidungen. Daraus resultieren vom SDV-Standard abweichende, zukunftsweisende Entscheidungen bzgl. Architektur, Infrastruktur, Applikationsserver, Versions­­verwaltung u.v.m.

Ergebnisse

• Schnellere Entscheidungen durch Lenkungsausschuß-Modell. Durch Scrum Möglichkeit, unterwegs zu lernen und den Projektplan entsprechend zu verfeinern und anzu­passen, z.B. durch Aufnahme eines neuen, innovativen Features in den Projektplan, von dem man zu Projekt­beginn noch gar nicht wußte, ob und wie es gesetzeskonform um­setzbar wäre.
• Verkürzung der Release-Zyklen: erstes Release (öffent­licher Launch der OKVS-Plattform) nach 6 Monaten, zweites Release 3 Monate später, drittes 6 Wochen später.
• Aufgrund ständiger PO-Tests im Sprint Verkürzung der Release-Abnahme-Phase von min. 7 auf max. 3 Wochen wegen bereits vorhandener Qualität und Testabdeckung.
• Für SDV-Projekte beispiellos hoher Test-Automationsgrad
• Ende 2015 überträgt SDV vom Projekt-Jahresbudget (2,8 Mio. €) einen Betrag von 1 Mio. € ins Jahr 2016, weil das Projekt mit weniger Entwicklern auskommt als geplant.
• Außer den anfänglich geplanten 7 Sparda-Banken ent­schließen sich nach dem erfolgreichen Release 1 auch die restlichen 5 dazu, OKVS einzusetzen und entsprechend mit­zufinanzieren. Daß alle 12 Institute an Bord sind, kommt ansonsten nicht oft vor.
• Beschluß von Sparda-Banken und SDV, künftig große, komplexe Projekte bevorzugt mit Scrum umzusetzen und dabei auf interdisziplinäre Teams mit direkter Beteiligung von Bankmitarbeitern zu setzen.
• Stärkung des gegenseitigen Vertrauens zwischen Kunden (Banken) und Dienstleister (SDV) durch tägliche, direkte Zusammenarbeit vor Ort im Projekt. Abbau der vorherigen Abschottung gegeneinander.
• Erhebung diverser von OKVS erstmals eingesetzter Technologien zum neuen SDV-Standard
• Aufgrund des 2-wöchigen Release-Zyklus des Scrum Teams wächst der Wunsch der Banken, diese internen Releases auch häufiger produktiv in Betrieb zu nehmen. Erste Schritte hin zu einem DevOps-Modell (Verzahnung von Entwicklung und Betrieb), z.B. dauert das Produktiv-Deployment eines neuen Releases nur noch Minuten, weil es auf Knopfdruck erfolgt. Zuvor wurden noch Releases auf CD gebrannt, per Unterschriften auf Laufzetteln frei­gegeben und ins Rechenzentrum zur manuellen Installation transportiert.

Situation:

• Kleine Internet-Agentur, beauftragt mit größtem Projekt der Firmengeschichte
• Schnelles Personalwachstum aufgrund Rekrutierung spezieller Entwickler für dieses Projekt
• Aufgrund chaotisch gelaufener Projekte in der Vergangen­heit wollte man "besser planen", es wurde ein Wasserfall-Planungsansatz umgesetzt.
• Projekt läuft seit einem Jahr, es sind aber nicht einmal die vor einem halben Jahr fälligen Visual Designs einer ex­ternen Agentur fertig, weil man sich in Details verstrickte.
• Noch zwei Monate bis zur Deadline (Hauptsaison für Reise­buchungen) des Auftraggebers
• Verspäteter Launch = Konkurs von Tegtmeier aufgrund Entzug des Projektauftrags ohne Zahlung (Werkvertrag)
• Stress und gereizte Stimmung im Team
• Kein Glaube mehr an den Projekterfolg
• Firmengründer & Geschäftsführer hat kein Vertrauen mehr in sein Team, glaubt alles kontrollieren zu müssen mit rigidem Mikromanagement
• Persönlicher Konflikt zwischen Geschäftsführer und besser­wisserischem, sich nicht unterordnendem Lead Developer

Maßnahmen:

• Bestandsaufnahme aller Aspekte: Anforderungskatalog, methodische Vorgehensweise, zwischenmenschliche Konflikte, Kompetenzgefälle im Team
• Scrum-Training für Geschäftsleitung und Team
• Personal Coaching für Geschäftsführer, um das Mikro­management zu beenden und ihn freizumachen für wichtigere Aufgaben
• Ausbildung einer integrativen Persönlichkeit (Organisations­psychologin) zum Scrum Master
• Schmieden eines Teams aus einer heterogenen Gruppe von Individualisten
• Ausbildung des Auftraggeber-Geschäftsführers zum Product Owner mit Schwerpunkt Requirements Engineering
• Gemeinsamer Aufbau eines streng priorisierten Product Backlogs
• Neuer Zuschnitt der Anforderungen in User Stories, fokus­siert auf den zum Launch wesentlichen Geschäftswert
• Offene Diskussion der Konflikte in Retrospektiven
• Schaffung neuen, gegenseitigen Vertrauens zwischen Scrum Team einerseits und Geschäftsführer und Auftrag­geber andererseits

Ergebnisse:

• Neues Selbstvertrauen im gesamten Scrum Team
• Product Owner fühlt sich nach eigener Aussage "befreit" und "empowered", weil er nun handwerklich das Zu­schneiden und Priorisieren einzelner Anforderungen innerhalb des Backlogs beherrscht, nachdem er vorher immer dachte, alles müsse auf einmal fertig werden.
• Soziale Balance im Team kehrt wieder ein, Stimmung verbessert sich
• Erster Sprint ist sehr schwierig, aber es wird am Ende ein Produktinkrement geliefert. Dadurch steigt das Selbst­vertrauen im Team und das Vertrauen des Auftraggebers.
• Zweiter Sprint läuft schon viel besser, die Gruppe wird zum echten Team.
• Trotz Zeitdrucks und Vorbehalten seitens des Chefs inve­stiert das Team in Testautomation. Die Qualität steigt, Regressionen (ein altes Hauptproblem) werden weniger und fallen schneller auf.
• Release-Termin wird gehalten, CU Ski geht im Juli 2015 online. Weitere Releases im Rahmen der Scrum-Sprints folgen in kurzen Abständen.
• Parallel dazu wird das bestehende Portal CU Camper (Wohnmobil-/Camping-Reisen) renoviert und im Rahmen eines Refactorings an das technologisch fortschrittlichere CU Ski angepaßt.
• Tegtmeier eK stabilisiert sich und firmiert um in GmbH

Situation:

• Scrum als Prozeßrahmen ist seit drei Jahren eingeführt, funktioniert zufriedenstellend und hat für meßbare Verbesserungen gesorgt. TRUMPF als Maschinenbauer hat einen unternehmensweit etablierten KVP/Kaizen-Prozeß, d.h. Verbesserungen werden auch wirklich gemessen und neue Ziele werden jährlich gesteckt.
• Die neuen Ziele sind mit den bestehenden Prozessen nicht zu erreichen, insbesondere Release-Zyklen sind zu groß und zu aufwendig.
• Unterschiedliche Reifegrade einzelner Teams
• Probleme, externe Zulieferer in den Scrum-Prozeß zu integrieren

Maßnahmen:

• Beobachtung mehrerer Teams bei der täglichen Arbeit
• Teilnahme an regelmäßigen Scrum-Meetings (Daily Scrum, Sprint Review, Retrospektive, Planning, Backlog Grooming)
• Einzelinterviews mit Abteilungs- und Teamleitern, Product Owners, Scrum Masters sowie in-/externen Teammitgliedern
• mehrmals wöchentlich Jour Fixe mit Hauptabteilungsleiter, täglich mit Abteilungsleiter zur Besprechung der Zwischenergebnisse und nächsten Schritte
• Erarbeitung einer Situationsbeschreibung (Status Quo)
• Erarbeitung eines Katalogs von Verbesserungsmaßnahmen

Ergebnisse:

• Ca. 50 konkrete Verbesserungsmaßnahmen wurden von mir identifiziert, beschrieben und auf Kundenwunsch hin bewertet hinsichtlich Impact und möglicher Fristigkeit der Umsetzung.
• Der Katalog umfaßt Themen aus Organisationsentwicklung, Projektmanagement, Technologie, Agile Entwicklungs- und Testpraktiken bis hin zur Auswahl von und Vertrags­gestaltung mit externen Zulieferern.
• Zur Überraschung des Kunden waren die identifizierten Potentiale nicht nur marginal – TRUMPF dachte, der etablierte Prozeß und die Entwicklungspraktiken hätten bereits einen hohen Reifegrad erreicht – sondern massiv, da aus Beratersicht eine Professionalisierung in allen o.g. Bereichen notwendig war. Es gab viel „Luft nach oben“.
• Vorbesprechung der Ergebnisse mit dem Management
• Präsentation und Diskussion der Ergebnisse in einem Workshop mit Abteilungs- und Teamleitern
• Auf meinen Vorschlag hin Präsentation der Ergebnisse vor allen Mitarbeitern (volle Transparenz) und gemeinsame Priorisierung der Verbesserungsmaßnahmen durch die Mitarbeiter als Vorschlag (nicht bindend) fürs Management
• Diskussion des Mitarbeiter-Feedbacks im Management und Erstellung eines priorisierten Maßnahmenkatalogs zur Umsetzung der Verbesserungsvorschläge
• Außerdem wurden noch während meiner relativ kurzen Anwesenheit Zulieferer dahingehend ausgetauscht bzw. bestehende Vereinbarungen mit entsprechend willigen Zulieferern modifiziert, daß eine engere Zusammenarbeit möglich wurde, indem externe Mitarbeiter vor Ort beim Kunden in den Teams mitarbeiten statt remote. Diese Maßnahme hatte vor dem Review/Assessment überhaupt nicht zur Diskussion gestanden.

Situation:

• Existierendes Legacy-Produkt ist mächtig, skaliert aber schlecht (nur über extrem teure Spezialhardware) und hat eine unzeitgemäße, unergonomische Benutzerschnittstelle
• Existierender Prototyp (Proof of Concept) für neue, skalierbare Plattform mit zeitgemäßer Benutzerschnittstelle und Echtzeit-Analysefähigkeiten hat hohes Marktpotential, aber mangelhafte Architektur, Code-Qualität und Testabdeckung 0%
• Etablierte interne Prozesse sind extrem langsam und "wasserfall-artig" und zeichnen sich im wesentlichen durch mangelnde Kommunikation zwischen einzelnen Abteilungen und Innovationsfeindlichkeit aus ("wir haben das schon immer so gemacht")
• Interne Widerstände und große Zweifel an der Idee der neuen Plattform, obwohl die alte erkennbar das Ende ihres Lebenszyklus erreicht hat und sich kaum mehr an neue Kunden verkaufen läßt (Firma lebt von Wartungsverträgen)
• Termindruck, weil eine Instanz der neuen (noch gar nicht existierenden) Plattform bereits an einen Neukunden, welcher vom Prototyp beeindruckt war, verkauft wurde. Auslieferung in 6 Monaten steht bevor.

Maßnahmen:

• Coaching des Managements (CEO und abwärts)
• Aufbau eines neuen Projektteams
  • Auswahl interner Mitarbeiter
  • Rekrutierung externer Spezialisten
  • Auswahl von Mitarbeitern einer US-amerikanischen Schwesterfirma und Einfliegen selbiger für 3 Monate (Team Building)
• Interimsweise Übernahme der Scrum Master-Rolle
• Training und Coaching für Product Owner, zukünftige Scrum Masters und Teammitglieder
• Aufbrechen organisatorischer und infrastruktureller Hindernisse, die zuvor immer als gegeben hingenommen wurden, gegen erhebliche Widerstände zu Beginn
• Einführung zeitgemäßer Entwicklungspraktiken wie Testautomation, Peer Reviews, kontinuierliche Integration und Auslieferung, Code-Metriken, Clean Code-Prinzipien
• Umstellung der Build-Infrastruktur von Subversion, Ant auf Git, Maven, Jenkins inkl. intensiver Nutzung eines Feature Branch-Modells (ähnlich GitFlow)
• Nach 3 Monaten Rückkehr der US-Mitarbeiter in ihre Heimat. Daraufhin Aufbau eines verteilten Scrum-Modells mit Scrum of Scrums, weiterhin Arbeit an gemeinsamer Codebasis und gemeinsamer kontinuierlicher Integration.

Ergebnisse:

• Refactoring des nahezu unwartbaren Prototyps in eine modulare Plattform, die auf Standard-Hardware einen Cluster-Betrieb mit nahezu linearer Skalierbarkeit bzgl. Performance durch Hinzufügen neuer Server erlaubt
• Liefertermin für Erstinstallation wird gehalten
• Etablierung einer agilen, auf Kollaboration über Abteilungs- und Teamgrenzen hinausgehenden Kommunikationskultur
• Abbau von Skepsis durch rigorose Transparenz bzgl. Scrum-Prozeß und Entwicklungsfortschritt ("Information Radiators")
• Schaffung von Vertrauen in die Tragfähigkeit der neuen Plattform
• Offizieller strategischer Wechsel in Marketing und Vertrieb von der alten, nun gegenüber den Kunden abgekündigten Plattform auf die neue

Situation:

• komplexes, skaliertes Scrum-Projekt mit Hardware- und Software-Anteilen, vielen (90%) externen Mitarbeitern, externen Zulieferern und verteilten Teams
• Scrum seit 9 Monaten eingeführt
• Probleme aufgrund mangelnder Methodendisziplin ("Frankenstein-Scrum")
• Projekt hinter Zeitplan
• unsaubere, nicht agile Release-Planung
• mangelnde Transparenz
• Teams liefern regelmäßig weniger als 50% der geplanten Story Points
• schädliches Multitasking: viel wird parallel angefangen, wenig zeitnah fertiggestellt

Maßnahmen:

• Coaching des Managements (Leiter BU, Technischer Leiter, Chief Product Owner, Product Owners, Leiter Program Management) bzgl. agiles Multi-Projektmanagement, Theory of Constraints, Requirements Engineering, User Stories
• Einführung von Kanban als Alternative zu Scrum für unterstützende Teams außerhalb der Produktentwicklung wie DevOps und Task Forces
• Schulungsmaßnahmen für Scrum- und Kanban-Teams
• Coaching der Scrum Masters und Kanban Senseis
• Aufbau teamübergreifender Synchronisation via Scrum of Scrums, Master Product Backlog, Communities of Practice
• verbessertes, tagaktuelles Management Reporting
• transparente und realistische Release-Planung basierend auf Team Velocity (nicht auf Wunschdenken des Managements)

• Übernahme eines neuen Teams als Scrum Master als "Show Case" für die anderen Teams und das Management, um zu zeigen, was möglich ist, wenn man sauber nach Scrum arbeitet
• Übernahme erfolgreicher Praktiken aus dem Leuchtturm-Team in die übrigen Teams
• interne Umzüge, um Entwickler, Tester, Product Owner, Scrum Master pro Team in jeweils einem Raum zu versammeln und unnötigen zeitlichen und kommunikativen Overhead zu eliminieren
• Ablösung der alten, für Scrum/Kanban schlecht geeigneten Projektmanagement-Software durch ein enterprise-fähiges, agiles Tool
• Etablierung von "state of the art" Engineering Practices: stark erhöhte Testautomation und -abdeckung, Continuous Integration & Deployment, Pair Programming, Einführung und Beachtung einer Definition of Done für jedes Team
• Einführung klarer Time Boxes für Sprints und Meetings

Ergebnisse:

• Gruppen werden zu echten, selbstorganisierenden Teams mit mehr Verantwortung und höherem Anspruch an eigene Qualität
• Sprint-Reviews mit mehr teilnehmenden Stakeholders, klarem Fokus auf Live-Vorführung fertiggestellter Funktionalität (statt Powerpoint-Folien und Konzepten)
• Abschaffung von über mehrere Sprints verteilten "Mini-Wasserfällen" und Langläufer-Stories durch besseres Requirements Engineering
• deutlich erhöhte Velocity durch Stabilisierung der Teams, weniger WIP (work in progress), weniger ungeplante Störungen durch Stakeholders
• stark verbesserte Liefertreue: Teams liefern, was für den Sprint geplant war, nicht nur die Hälfte
• Scrum Masters attackieren Impediments früher und entschiedener, weil Sprint Backlogs und Task Boards besser gepflegt werden und Störungen früher sichtbar werden
• bessere Auskunftsfähigkeit der Teams gegenüber Stakeholders durch sauberes Tracking des Fortschritts
• realistische Release-Planung auf Basis belastbarer Velocity-Daten und Team-Schätzungen, nicht vager Vermutungen
• mehr wird erreicht durch ruhigeres Arbeiten: weniger "Panik-Modus" und "Ad-Hoc-Management"
• jedes Sprint-Ergebnis wird auch an die Stakeholders ausgeliefert: Fakten ersetzen Fiktionen, Qualität steigt

Situation:

• SAP-Einführungsprojekt hängt fest in der Planungsphase, weil die Planung immer wieder der veränderten Realität hinterher hinkt
• interne Prozesse zu bürokratisch, nicht agil genug
• viele Stakeholders, viele Projektbeteiligte, verteilte Standorte
• Schwierigkeit, trotz teils unklarer Anforderungen ins Projekt einzusteigen und Fortschritte zu erzielen
• Wunsch nach fortlaufender, flexibler Planung

Maßnahmen

• Management-Beratung bzgl. Scrum im Besonderen bzw. Lean und Agile allgemein
• Konzeption eines Scrum-Rollouts in der Projektorganisation unter Einbezug der Stakeholders aus den IT-fremden Fachbereichen
• Scrum-Trainings für Projektmitarbeiter und Führungskräfte
• Erarbeiten von Vorschlägen für Vorgehensweise bei Planung, Aufwandschätzung, Ressourcenzuteilung (Ziel: weitgehende Vermeidung schädlichen Multitaskings)

Ergebnisse:

• noch keine (Großprojekt fortlaufend)

Situation:

• Management des Projektportfolios funktioniert bereits zufriedenstellend nach eingeführtem Prozeß, weitere Verbesserungen werden gewünscht
• Lean Production bereits etabliert, aber im Bereich Projektmanagement wird weder lean noch agil, sondern weitgehen klassisch (Wasserfall-Prozeß mit entsprechend bürokratischen Entscheidungswegen) gearbeitet

Maßnahmen

• Einführungs-Workshop für Führungskräfte aus unterschiedlichen Unternehmensbereichen
• Scrum- und Lean-Coachingsitzungen mit einzelnen Führungsteams

Ergebnisse:

• Nach eingehender Beratung mit Workshops und Coaching-Terminen für einzelne, verantwortliche Manager beschließt TRUMPF, Scrum in Einzelprojekten zu verwenden und mit ToC/CCPM-Ansätzen im Projektportfolio-Management zu verbinden.

Situation:

• Probleme im Bereich Multi-Projektmanagement: zu viele offene Projekte, zu lange Projektlaufzeiten, fehlender Überblick über Ressourcenauslastung, keine konsequente Priorisierung des Projektportfolios
• Probleme in einzelnen Projektteams: jeder arbeitet für sich, kein echtes Teamwork, stattdessen Kopfmonopole, fehlende Koordination, mangelnde Planung
• Probleme einzelner Experten: Überbuchung, extremes Multitasking, Überarbeitung, nichts wird fertig

Maßnahmen:

• Einführung von Scrum als Management-Framework
• Iterativ-Inkrementelles Arbeiten im Team mit Konzentration auf Qualität und regelmäßige Lieferungen von Zwischenergebnissen
• Begrenzung der WIP (Work in Progress) durch Einführung kanban-typischer Höchstgrenzen für Arbeitspakete in bestimmten Prozeßschritten
• Auswertung von Kennzahlen bzgl. Projektdauern, Auslastung pro Projekt und Mitarbeiter, Multitasking
• Mitarbeiter helfen einander gegenseitig auch in für das Individuum atypischen Aufgaben, um die Wissensweitergabe zu fördern

Ergebnisse:

• besserer Überblick, wo "Zeit liegen bleibt"
• Verständnis für und Verringerung schädlichen Multitaskings
• Gruppen werden zu Teams
• weniger Kopfmonopole
• höherer Projektdurchsatz
• priorisiertes Projektportfolio bringt bessere Planungssicherheit

Beschreibung:

• Scrum-Einführung im Bereich Parallels Automation, Standort Moskau
• Training, danach Coaching vor Ort über mehrere Monate
• 2 von 3 Produktlinien, ca. 80 Mitarbeiter in mehrstufigem Prozeß mit Scrum of Scrums (mehrere Teams pro Projekt)
• Standort Novosibirsk mit 3. Produktlinie folgt später
• Umstellung von spezialisierten in interdisziplinäre Teams
• Kollokation der neuen Teams: Umzug der Mitarbeiter auf zwei Stockwerken und Abbau der Cubicles, so daß jedes Team inkl. Scrum Master und Product Owner zusammen in einem Open Space sitzt
• Aufbau und Leitung eines Meta Scrum Teams aus Führungskräften mit eigenem Meta Backlog und Product Owner (Bereichsleiter), um die Scrum-Einführung und weitere Organisationsentwicklungs-Vorhaben zentral zu steuern
• Umstellung bisheriger Planungs- und Reporting-Werkzeuge auf Scrum-Artefakte
• Verschlankung von Planungs-, Entscheidungs- und Entwicklungsprozessen
• Einführung von Continuous Integration
• mehr Test-Automation, früheres Testen

(Zwischen-) Ergebnisse:

• 8 Teams arbeiten mit Scrum (Sep. 2009), weitere geplant
• Management-Team arbeitet ebenfalls mit Scrum → fraktale Selbstähnlichkeit der Makro- und Mikroprozesse in Management- und Projektteams
• Zuvor übliches, zeitliches "Überziehen" von Iterationen wird abgeschafft, alle Sprints enden pünktlich
• Selbstorganisierende Teams statt Arbeitszuteilung durch diverse Teamleiter
• Release-Planung orientiert sich an gemessener Velocity der Teams, nicht mehr am Wunschdenken des Managements

Beschreibung:

• Strategisches Projekt von 1&1 (größtes laufendes Projekt im Bereich Webhosting)
• Projektstruktur/Beteiligte:
• - interdisziplinäres Projekt-Team aus Entwicklern von drei Produktentwicklungs-Teams und einer Core-Develop­ment-Abteilung sowie Mitarbeitern aus Konzeption (User Experience), technischem Produkt­management, Redak­tion und Qualitäts­sicherung (Tests)
• - Projektleiter berichtet an Leiter Project Office und Bereichsleiter Webhosting
• - Vorgehensmodell: Scrum (inkl. Ersteinführung des Prozesses)
• Projektumfang / Umgebung:
• - Gesamtdauer ca. 1,5 bis 2 Jahre
• - durchschnittlich 10 Entwickler im Projekt
• - Hauptziel: Neuentwicklung eines Homepage-Baukastens für mehrere Mio. 1&1-Kunden, skalierbarer Betrieb auf Hosting-Hardware
• - Weitere Ziele: Einführung eines Enterprise Service Bus für bereichsweite Inter-Prozeß-Kommunikation; Ent­wick­lung einer deskriptiven UI-Beschreibungssprache, die es ermöglicht, multikanal-fähige Applikationen zu bauen (z.B. Rich Client für Breitband-Kunden, Thin Client für Modem-/ISDN-Kunden, Version für mobilen Zugriff via Handy)

Aufgaben als Projekt­leiter / Scrum Master:

• Führung des interdisziplinären Teams
• Termin- und Ressourcenplanung
• Steuerung des Scrum-Prozesses
• Reporting bzgl. Projektfortschritt und Kosten
• Coaching für den Product Owner bzgl. Release-Planung, Ermittlung des und Priorisierung nach Business Value
• Einführung von Unit Testing, Continuous Integration, Code Coverage, Projekt-Wiki, Bug-Tracking-System

Aufgaben als Scrum Evangelist:

• Management-Beratung bzgl. Agile Enterprise (z.B. Scrum im Multi-Projektmanagement)
• Scrum-Trainer (Schulungen, Workshops) für Project Offices unterschiedlicher Bereiche, Produktmanagement, Redaktion, Support, Qualitätssicherung u.a.
• Coach/Supervisor für bereichsweite und ‑übergreifende Einführung des Scrum-Vorgehens­modells; Unterstützung beim Aufsetzen weiterer Scrum-Projekte
• in- und externe Vorträge zum Thema "Scrum bei 1&1", z.B. http://www.andrena.de/Entwicklertag/2008/Vortraege/Scrum-1und1.html

Beschreibung:

• Strategisches Projekt der NVG
• Projektstruktur:
  • vier Teilprojekte mit interdisziplinären Teams
  • Teilprojektleiter berichten an Gesamt­projektleiter
  • Gesamtprojektleiter berichtet an Vorstand und Lenkungsausschuß
• Beteiligte:
  • zwei Informatik-Abteilungen
  • mehrere Fachbereiche
  • drei externe Dienstleister
• Projektumfang / Umgebung:
  • Umstellung von papiergebundenem Antrags-Workflow auf frühes Scannen mit elektro­nischem Antrags-Routing
  • vollautomatische Policierung von Anträgen (vorher nicht möglich)
  • Anbindung eines neuen medizinischen Expertensystems zur Risikoprüfung
  • Ablösung der Antragsbearbeitung am Host durch J2EE-Server
  • Anbindung von >20 CICS-basierenden Subsystemen am Host über MQ Series
  • Erfassungs-Client in C# und .NET
  • Bearbeitungs-Client in Java (Eclipse RCP)
  • Archiv-Anbindung (FileNet und IBM) inkl. Scanning, Indizierung, Viewing, Annotationen
  • Postkorb-Integrationen (Host und Tibco)
  • Integration der Gesamtanwendung ins Security-Konzept des Konzerns (Authenti­sierung, Autorisierung, Rollenkonzept)

Aufgaben als Gesamtprojekt­leiter:

• Koordination der Teilprojekt-Teams
• Schnittstelle zwischen Auftraggebern (diverse Fachabteilungen) und Auftragnehmern (zwei IT-Abteilungen unterschiedlicher Konzernsparten)
• Regelmäßiger direkter Bericht an Vorstand und Lenkungsausschuß
• Fachliche Analyse
• Anwendungs-Design
• Schulungs- und Coaching-Konzept für das in Java unerfahrene Entwickler-Team des Kunden
• Ressourcenplanung (Aufwandsschätzungen, Zeitpläne)
• Leitung fachlicher und technischer Meetings
• Etablierung eines Wiki als zentrale, bereichs­über­greifende Informations-Plattform
• Etablierung von Werkzeugen und Metriken für die Softwareentwicklung (Use Cases, UML, CVS, Unit Testing, Code Coverage, Build Management)
• Koordination der Entwickler des Kunden und dreier externer Firmen

Ergebnis:

• Erfolgreicher Abschluß der Projektphase 1 (Analyse, Design, Proof of Concept)
• Entgegen der ursprünglichen Planung wurde der über den vereinbarten Lieferumfang weit hinaus gehende, bereits über alle beteiligten Systeme hinweg laufende Prototyp produktiv gesetzt.
• Entscheidung der NVG, die weiteren vier Projekt­phasen in Angriff zu nehmen und das Projekt in den folgenden zwei Jahren abzu­schließen.

Beschreibung:

• offene Einführungsveranstaltung zum Thema Scrum im Dezember 2007 im Rahmen eines Firmen-Kolloquiums, beauftragt durch den Leiter Qualitäts- und Wissensmanagement
• Entscheidung von EB, ab März 2008 Scrum als neue Methode für Software-Entwicklung und Projekt­management im laufenden Projekt einzuführen, um sich ständig ändernden Anforderungen gerecht zu werden
• Scrum-Training für Product Owner und Scrum Master
• regelmäßige Projekt-Retrospektiven vor Ort, um den Scrum-Prozeß zu verbessern als Berater für Team (7 Entwickler), Scrum Master und Product Owner
• zusätzlich fortlaufendes Coaching via E-Mail und Telephon

Ergebnis:

• externer Kunde von EB akzeptiert nach anfänglicher Skepsis Scrum, weil die Ergebnisse für sich sprechen, und nimmt aktiv teil an Projekt-Reviews sowie der Gestaltung des Product Backlogs
• Anfrage seitens EB bei [Name auf Anfrage] nach Vollzeit-Coaching für zwei Monate (kam nicht zustande wegen anderweitiger Verpflichtungen)

Beschreibung:

• Scrum bereits in Anwendung, aber Probleme bei der Prozeß-Implementierung
• Ziel: besseres Verständnis für Scrum schaffen, Produktentwicklungs-Prozeß und Zusammenarbeit Kunde vs. Auftragnehmer verbessern

Beschreibung:

• Kernportfolio des Softwarehauses COI umfaßt seit 1988 ein integriertes System für Archiv, DMS, Workflow mit Zielmarkt Fortune 500
• Strategische Produktlinie COI-Intelliger soll Wissens­management als neuen Unternehmens­bereich etablieren
• Projektstruktur:
  • fünf Teilprojekte
  • Teilprojektleiter berichten an gesamtverant­wortlichen Produktmanager
  • Produktmanager berichtet an Geschäftsführung
• Beteiligte:
  • 5 interne MA der Entwicklung für Integrations- und Qualitätstests
  • Marketing, Vertrieb
  • Entwicklungspartner in Osteuropa entwickelt im Outsourcing-Betrieb mit 25 MA
• Projektumfang / Umgebung:
  • hochskalierbarer Server zur Indizierung von Datenbeständen im Terabyte-Bereich
  • automatische thematische Klassifizierung und Clustering von Inhalten mittels lernfähiger Algorithmen
  • automatische Generierung von Inhalts­angaben (Abstracts) beliebiger Länge aus indizier­ten Dokumenten
  • automatische Verschlagwortung von Archiv/DMS-Inhalten automatisches Auslesen von gescannten Textseiten via integrierter OCR-Engine
  • Assoziative Ähnlichkeitssuche für natürlich­sprachige Sätze, Absätze, Kapitel oder voll­ständige Dokumente
  • Integration unterschiedlicher Wissensquellen (Fileserver, Archiv/DMS, Datenbanken, Groupware-Systeme, Intra- und Extranet) unter Beachtung von Benutzerrechten
  • Komfort-Client mit graphischer Oberfläche und integriertem Multiformat-Viewer (>200 Formate) läuft stand-alone (lokale Suche) und mit Anbindung an den Enterprise-Server
  • Web-Client für Portal- und Intranet-Integration

Aufgaben als Produktmanager:

• Übernahme eines laufenden, am Rande des Scheiterns stehenden Entwicklungsprojekts (Termin- und Qualitätsprobleme, Streit mit dem Lieferanten) als Troubleshooter
• Erstellung der technischen Anforderungs­defini­tion (Lastenheft), Definition des jetzigen und zukünftigen Leistungsumfangs, Bestimmung der Prioritäten im Entwicklungsplan
• Steuerung der Entwicklungs- und Testmann­schaften sowohl intern bei COI als auch beim externen Entwicklungspartner
• Kontaktstelle und Vermittler zwischen Manage­ment und Vertrieb einerseits und der Entwick­lung andererseits. Einberufung und Moderation von Milestone-Meetings, auch unter Teilnahme der Projektleiter des Outsourcing-Partners.
• Ständiger Telephon- und Mailkontakt nach Osteuropa, direkte Kommunikation mit den Entwicklern dort in englischer Sprache.
• Leitung von Tests und Qualitätsmanagement während der Alpha- und Beta-Phase. Bewertung der Ergebnisse, bei Bedarf Anpassung des Entwicklungsfahrplans.
• Definition und Ausarbeitung von Lösungs­szenarien rund um die Intelliger-Produktlinie
• Finden von Erklärungsmöglichkeiten für die tech­nischen Details und Begrifflichkeiten des Pro­duktes (neuronale Netze, maschinelles Lernen, assoziative Suche, Klassifizierung, Lerndoku­mente, n-dimensionale Vektorräume) mit dem Ziel, daß auch ein Manager verstehen kann, was die Software tut. Erstellung entsprechender Präsentationsfolien und Texte für Produkt­broschüren und Veröffentlichungen in Fach­zeitschriften.

Ergebnis:

• Erfolgreiche Markteinführung der COI-Intelliger Suite im Zeit- und Budgetrahmen