• Aufbau einer Omnikanal-Plattform bei IT-Dienstleister in streng reguliertem Bank-Umfeld (SAFe-Programm, 175 Teams)

Rollen: 

• Scrum Master für zwei Teams im Agile Release Train (ART) "Dokumentenlogistik"
• Unterstützung der Programmleitung bei Jira-Auswertungen über die 175 Teams hinweg
• Unterstützung und Agiles Coaching für Tribe Leads, People Leads, Release Train Engineer (RTE)
• Multiplikator für organisatorische Themen im Bereich Agilität auch in andere ARTs
• Multiplikator für technische Themen: komplexe Jira- Auswertungen, Aufbau dazu passender Confluence- Seiten zur Überwachung regulatorischer Ordnungsmäßigkeit, Jira Automation via Scripting per REST API, Git Multi-Branch Workflow u.a.

Situation: 

• Atruvia steht unter Innovationsdruck, möchte Altverfahren ablösen durch eine moderne Omnikanal-Plattform (cloud-basierter Stack mit Kubernetes, Spring Boot Back-End, Angular Front-End), sowohl für Bankmitarbeiter als auch für Bankkunden.
• Linienprozesse sind schwerfällig und bürokratisch, daher beschließt Atruvia, die neue Plattform über mehrere Jahre in einer separat, parallel zur Linie existierenden Ablauforganisation nach SAFe als großes Programm umzusetzen, um flexibler und agiler zu werden.
• Program ONE läuft bereits seit einigen Jahren, nimmt aber zum Zeitpunkt meines Einstieges erst richtig Fahrt auf. Immer mehr Teams stoßen hinzu, intern gibt es nicht genügend erfahrene Agile Coaches und Scrum Masters. Daher stoße ich, gemeinsam mit anderen Agile Coaches, hinzu.
• Alle SAFe-Rollen sind besetzt, alle Zeremonien (z.B. PI Plannings mit hunderten Teillehmern) auf Programm-, Value Stream-, ART- und Teamebene finden statt, aber in den Teams selbst gibt es wenig Agilität ("doing agile" vs. "being agile").
• Die Mitarbeiter haben zu wenig Fokus, weil sie parallel in der Linie und im Program ONE arbeiten.
• Herausforderung: agilere Prozesse in stark reguliertem Umfeld.

Maßnahmen:

• Verkleinerung von Teams mit dem Ziel der Durchsatzsteigerung (lieber weniger Mitarbeiter, dafür mehr Fokus statt Teilzeitarbeit im Program ONE)
• Verbesserung des agilen Grundlagenwissens (Werte, Prinzipien, Praktiken) in den Teams. Einführung klarer Strukturen für Planungskadenzen, Sprints und Meetings.
• Bessere Integration einerseits, aber auch klarere Definition und Abgrenzung von Verantwortlichkeiten andererseits für externe Entwicklungspartner, um Reibungsverluste und Ineffizienzen in Kommunikation, Requirements Engineering und Implementation zu verringern
• Einführung eines Multi-Branch-Workflows in der Softwareentwicklung, um technisch und regulatorisch sauberer zu arbeiten: Anstatt halb fertige Features auszubringen und sie mit Feature Toggles zu deaktivieren, bis sie fertig und stabil sind, werden jedes noch so kleine Feature und jeder Bugfix immer in je einem separaten Entwicklungszweig (Feature Branch) entwickelt, um sie erst dann ins Endprodukt zu übernehmen, wenn sie fertig entwickelt, dokumentiert, getestet und abgenommen wurden.
• Entwicklung von Skripten, Abfragen und Auswertungen für die Programmleitung, um einen besseren Überblick über den Fortschritt der 175 Teams und die Einhaltung regulatorischer Vorgaben (z.B. Vorwärts- und Rückwärts-Traceability) zu erhalten.
• Eskalation organisatorischer Impediments und entsprechender Verbesserungsvorschläge bis hinauf zur Programmleitung, um Ineffizienzen im Gesamtprogramm (nicht nur in einzelnen Teams) zu verringern.
• Verbreitung agilen und technischen Wissens in Communities of Practice (CoP), z.B. für Agile Coaches, Scrum Masters, Testautomatisierer, Entwickler.

Ergebnisse:

• Regulatorik-Verstöße in der Portfolio-Planungs- Hierachie in Jira müssen nicht mehr übers gesamte Program ONE (ca. 200 Jira-Projekte) hinweg von der Programmleitung manuell gesucht und von den 175 Teams nachträglich korrigiert werden über Tausende Issues, sondern meine Auswertungen identifizieren sie sofort und ermöglichen es, sie direkt zu beheben, während sie noch offen sind.

• Mehr "being agile", nicht nur "doing agile" in den von mir betreuten Teams. Dadurch auch Erhöhung der Velocity und regelmäßige Erreichung der zuvor meistens verpassten Entwicklungsziele.
• Durch mehr Fokus in den Teams wird das bei Atruvia beinahe krankhaft gelebte Multitasking zumindest auf ein erträglicheres Maß verringert, wodurch sich Effizienz und Effektivität erhöhen.
• Deeskalation der angespannten Situation mit den externen Entwicklungspartnern durch harmonischere Zusammenarbeit und mehr beiderseitige Transparenz. Weg von "wir vs. sie" hin zu "wir sind ein Team". Dadurch Erreichung der gemeinsamen Ziele.
• Sauberer Multi-Branch-Workflow beseitigt zuvor vorhandene Probleme (Seiteneffekte) mit unfertigem, per Feature Toggles angeblich inaktivem Code. Es wird nur noch ausgeliefert, was getestet und abgenommen wurde. Entwickler, Tester und Product Owners verlieren die Angst vor vielen Branches, weil sie gelernt haben, damit umzugehen.
• Architectural Runway- und Business Runway- Anforderungen aus der SAFe-Programmebene werden nicht mehr verschleppt, sondern von den Teams zeitnah umgesetzt.

Rollen:

Situation:

• Heterogene Teams (Kultur, Sprache, Mentalität, Arbeitsweise staatlich vs. privatwirtschaftlich geprägt)
• Kaum initiales Verständnis von Agilität, aber gemeinsames Vorgehen unter Zeitdruck und mit beweglichen Projektzielen bedingt flexibles, agiles Vorgehen

Maßnahmen:

• Initiales Training (Lean/Agile, Scrum, Kanban)
• Aufbrechen starrer, abgrenzender Strukturen zwischen Lieferant (mein Kunde) und Endkunde (staatlicher Akteur) hin zu gemeinsamer, agiler Planung und Umsetzung
• In einem Fall freiwilliges Lernen der lokalen Landessprache, weil das Englisch (offizielle Projektsprache) vieler Endkunden-Mitarbeiter nicht gut genug war, um reibungslose Kommunikation zu gewährleisten, die Mitarbeiter des Lieferanten aber die Landessprache nicht können

Ergebnisse:

• Interdisziplinäre Teams wachsen zusammen, sind mehr als die Summe der Einzelteile
• Agilität und "Can Do" Kultur etabliert sich auf beiden Seiten
• Durch meine inzwischen guten, lokalen Sprachkenntnisse erwerbe ich mir Respekt und Vertrauen der Endkunden-Mitarbeiter und kann als Vermittler dienen, sowohl sprachlich als auch organisatorisch
• Projekt erfolgreich und im vorgegebenen Zeitrahmen umgesetzt (Live-Betrieb)

Rollen:

• Agiler Coach
• Interim Scrum Master
• Troubleshooter

Situation:

• Gut eingespieltes, aber auch eingefahrenes Team (Projektleiter, Entwickler, Tester, Kundensupport) mit Ende-zu-Ende-Verantwortung für eine "Cash Cow" des Unternehmens
• Hervorragend ausgestattete Büroräume und Arbeitsplätze, offene Firmenkultur, bestens geeignet für Agiles Arbeiten, welches im Rest des Unternehmens bereits etabliert ist
• Ehemals sehr erfolgreiches Produkt hat über viele Jahre Gewinn abgeworfen, daher hat man das Team lange in Ruhe gelassen. Aber von Jahr zu Jahr wurde die Marge geringer, weil die Innovationsfähigkeit verloren gegangen ist und sich das Team auf seinen Lorbeeren ausgeruht hat.
• Wasserfall-Arbeitsweise mit klassischen Anforderungs- und Planungszyklen
• Anforderungen technisch beschrieben, nicht aus Kundensicht
• Neue Releases beheben tendenziell eher bestehende Probleme und "bauen an", anstatt überfällige Umbauten in Angriff zu nehmen und neue, von Kunden gewünschte Funktionen zu implementieren
• Unternehmensentscheidung steht bevor, das Team entweder zu verbessern und agiler zu machen, um das Produkt wiederzubeleben, oder das Team aufzulösen
• Agilisierung aus eigener Kraft hat nicht funktioniert, daher werde ich als externer Coach für 4 Monate hinzugezogen, um Anschubhilfe zu leisten und das Team aus seiner Komfortzone zu holen

Maßnahmen:

• Bestandsaufnahme, Kennenlernen der Teamkultur und Arbeitsweise. Ich möchte lernen, wieso das Team denkt, nichts verändern zu müssen, weil alles in Ordnung sei.
• Coaching: Agiles Projektmanagement, Agiles Requirements Engineering mit Kundenfokus (User Stories), Agile Softwareentwicklung, Testautomation
• Viele interne Diskussionen mit dem Projektleiter, der kein echter Product Owner sein möchte, und dem Team, das in Ruhe gelassen werden und wie bisher weiterarbeiten will, weil es nicht begriffen hat, dass die alten Erfolge dem Team in Gegenwart und Zukunft nicht mehr helfen.

Ergebnisse:

• Team gibt sich zu Beginn offen und hat mich im Vorstellungsgespräch selbst als Coach aus mehreren Kandidaten ausgewählt
• In der täglichen Arbeit zeigen sich sowohl der als Product Owner vorgesehen Projektleiter als auch das Team weitgehend uneinsichtig und beratungsresistent
• Verbesserungsvorschläge werden abgelehnt
• Ich sage der Bereichsleiterin, dass ich ihrem Team nicht helfen kann, weil es sich nicht helfen lassen will.

Rollen: 

• Agiler Coach für gemischte Projektteams aus internen Mitarbeitern des Herstellers und Endkundenmitarbeitern
• Interim Scrum Master
• Troubleshooter für Projektteams bereits laufender Projekte mit Umsetzungsproblemen

Situation: 

• Heterogene Teams (Kultur, Sprache, Mentalität, Arbeitsweise staatlich vs. Privatwirtschaftlich geprägt)
• Kaum initiales Verständnis von Agilität, aber gemeinsames Vorgehen unter Zeitdruck und mit beweglichen Projektzielen bedingt flexibles, agiles Vorgehen

Maßnahmen:

• Initiales Training (Lean/Agile, Scrum, Kanban)
• Aufbrechen starrer, abgrenzender Strukturen zwischen Lieferant (mein Kunde) und Endkunde (staatlicher Akteur) hin zu gemeinsamer, agiler Planung und Umsetzung
• In einem Fall freiwilliges Lernen der lokalen Landessprache, weil das Englisch (offizielle Projektsprache) vieler Endkunden-Mitarbeiter nicht gut genug war, um reibungslose Kommunikation zu gewährleisten, die Mitarbeiter des Lieferanten aber die Landessprache nicht können

Ergebnisse: 

• Interdisziplinäre Teams wachsen zusammen, sind mehr als die Summe der Einzelteile
• Agilität und "Can Do" Kultur etabliert sich auf beiden Seiten
• Durch meine inzwischen guten, lokalen Sprachkenntnisse erwerbe ich mir Respekt und Vertrauen der Endkunden-Mitarbeiter und kann als Vermittler dienen, sowohl sprachlich als auch organisatorisch
• Projekt erfolgreich und im vorgegebenen Zeitrahmen umgesetzt (Live-Betrieb)

• Scrum-Einführung in strategischem Software-Projekt (Firmenziel 2015-2017) bei IT-Dienstleister in streng reguliertem Bank-Umfeld

Rollen:

• Management-Berater für Bereichs- und Abteilungsleitung
• Agile/Lean Coach für Scrum/Kanban Team
• Scrum Master
• Coach für projektleitende Beratungsgesellschaft Sparda Consult

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 muss 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 angepassten 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 Lenkungsausschuss-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. Dass alle 12 Institute an Bord sind, kommt ansonsten nicht oft vor.
• Beschluss 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.

• Krisen-Intervention bei strategischem Firmenprojekt in Schieflage

Rollen:

• Management-Berater für Geschäftsleitung
• Personal Coach für Geschäftsführer
• Agile Coach für Scrum Team (PO, SM, Entwickler)

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 besserwisserischem, 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

Rollen:

• Management-Berater bis Ebene Hauptabteilungsleiter Software-Entwicklung
• mit Review beauftragter Beobachter und Coach für Abteilungs- und Teamleiter

Situation:

• Scrum als Prozessrahmen ist seit drei Jahren eingeführt, funktioniert zufriedenstellend und hat für messbare Verbesserungen gesorgt. TRUMPF als Maschinenbauer hat einen unternehmensweit etablierten KVP/Kaizen-Prozess, 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-Prozess 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 umfasst 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 Prozess 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, dass 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.

Rollen:

• Management-Berater bis Ebene CEO und Verwaltungsrat
• Coach/Trainer für verteiltes Scrum-Team (D, USA)
• Interim Scrum Master in den ersten Monaten

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ässt (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-Prozess 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

• QIVICON (URL auf Anfrage), jetzt Magenta SmartHome

Rollen:

• Management-Berater bis Ebene Leiter Business Unit
• Bereichs-Coach/Trainer für Scrum/Kanban (7 Teams)
• Interim Scrum Master für Leuchtturm-Team

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

Management-Beratung und Training bzgl. Einsatz von Scrum in SAP-Großprojekt 

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)

• Management-Beratung bzgl. Agilen Multi-Projektmanagements

Rollen:

• Management-Berater
• Scrum-Coach
• Coach für Grundlagen von Theory of Constraints (ToC) und Critical Chain Project Management (CCPM)

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

• Scrum-Einführung und Interim-Projektleitung bei Internet Service Provider, Bereich Web Hosting Development

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ätssicherung (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-Prozess-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"

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)

Situation:

• 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

Ergebnisse: Siehe folgendes Original-Antwort-Schreiben auf

meine E-Mail-Anfrage beim Kunden (CEO und Chief Software Architect) zwei

Monate nach Abschluss des Coachings:

> Wie geht es Euch denn inzwischen mit Scrum?

Es läuft sehr gut, wir haben auf "Story Points" umgestellt und unser zweiter Sprint scheint eine Punktlandung zu werden. :)

> Wie arbeitet Ihr?

Wir haben radikal auf Pair Programming und Test-Driven Development umgestellt - zur Zufriedenheit aller (Team & Owner).

> Verwendet Ihr noch [Name eines bekannten Scrum-Tools] oder eine Tabellenkalkulation?

Wir haben auf Excel umgestellt - gefällt uns auch, ehrlich gesagt, besser. Der Umgang damit ist einfach agiler, wir passen das Werkzeug unseren Bedürfnissen an, nicht mehr umgekehrt. ;)

> Wie fühlen sich die Team-Mitglieder, der Product Owner (also Du selbst) und der Scrum Master?

Also ich persönlich fühle mich gut. Meine Rolle habe ich radikal verändert! Ich bin der Owner und definiere nur noch Stories und ihre Prioritäten. Wenn ich Stories erstelle, beschreibe ich nur, was ich haben will, nicht, wie es technisch gelöst werden soll - ich schalte hier jetzt ganz bewusst mein technisches Wissen als ehemaliger Entwickler aus - und lasse das Team ausdiskutieren, wie es gemacht wird.

> Ist es anders (besser?) als vorher seit der Schulung, oder ist alles geblieben, wie es war?

Ich denke, die Schulung war eine Initialzündung für alle. Vielen - inklusive mir selbst - waren die Scrum-Werte vorher nicht ganz klar. Mir hat die Schulung sehr geholfen zu verstehen, wie Scrum gemeint ist!

Ich habe dem Team jetzt auch wesentlich mehr Verantwortung übertragen: Messebesuche, Einkaufsbudgets (Software, Hardware, Bücher etc.) und selbst Urlaubsanträge werden jetzt vom Team selbst verwaltet, ich bekomme da nur noch eine Info! Ich bin da inzwischen, wie Du siehst, sehr entlastet worden und kann ich jetzt voll der Aufgabe widmen, Stories zu definieren und zu priorisieren. Wir planen außerdem, das Team in zwei aufzuspalten ab dem nächsten Sprint, damit wir auch die Tester sinnvoll einbinden können. 

> Wie priorisierst Du inzwischen?

Ich halte mich da jetzt an Deinen Vorschlag: Höchster Business Value, höchstes Risiko zuerst!

(...)

Ich denke, Du bemerkst, dass ich sehr glücklich mit der Entwicklung bin. Es gibt da auch noch so viel zu erzählen! Evtl. können wir ja mal telefonieren, falls Du noch Fragen hast!?

Beschreibung:

• Strategisches Projekt der NVG
• Projektstruktur:
  • vier Teilprojekte mit interdisziplinären Teams
  • Teilprojektleiter berichten an Gesamt­projektleiter
  • Gesamtprojektleiter berichtet an Vorstand und Lenkungsausschuss
• 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 Lenkungsausschuss
• 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 Abschluss 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:

• 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