Agile & Digital Transformation
MENÜ

Bei einem internationalen Industrieunternehmen hat JOHANNES GESKE mit Hilfe von Scrum und Kanban konkurrierende Interessen von Vertriebsgesellschaften harmonisiert, einen massiven Entwicklungsstau im Salesforce Team aufgelöst, die Produktivität des Teams mehr als verdoppelt und das Team zu einem agilen Vorbild im Unternehmen entwickelt.

Ein internationales Industrieunternehmen setzt Salesforce ein, um die Vertriebsprozesse aller Ländergesellschaften zu steuern. Ein Team aus Prozessberatern, Salesforce-Entwicklern, -Administratoren und Support-Mitarbeitern zeichnet verantwortlich für die Beratung der Inhouse-Kunden in den Vertriebsgesellschaften sowie für die Entwicklung und Betreuung sämtlicher Salesforce-Applikationen.

Ausgehend von einer klassisch projektorientierten Vorgehensweise hat das Team nach einem besseren Weg gesucht, die Anforderungen von mehr als zwei Dutzend Vertriebsgesellschaften zu harmonisieren, koordinieren, planen und umzusetzen. Motiviert durch die Erfolgsgeschichte eines in die Krise geratenen Projekts im Unternehmen, bei dem JOHANNES GESKE durch agile Arbeits- und Denkweisen einen erfolgreichen Abschluss herbeiführen konnte, hat das Team auf eigenen Wunsch Scrum eingeführt.

Durch ein zweitägiges Scrum Training hat das Team das nötige Grundverständnis und Prozessbewusstsein entwickelt und damit die Voraussetzungen geschaffen, Scrum erfolgreich einzusetzen. Als Bestandteil des von JOHANNES GESKE durchgeführten Scrum Trainings hat das Salesforce Team ein Transition Backlog aufgebaut. Dieses beinhaltete die Arbeiten, die das Team durchzuführen hatte, um sich selbst in die Lage zu versetzen, erfolgreich Scrum zu praktizieren, wie zum Beispiel “Wir schaffen uns einen Arbeitsraum, in dem wir zusammenarbeiten können.” und “Wir identifizieren, überzeugen und trainieren einen Product Owner auf der Kundenseite, der mit uns und unseren gemeinsamen Kunden unsere Salesforce-Applikationen weiterentwickelt”. Damit hat das Team direkt zu Beginn Scrum nicht nur als agile Vorgehensweise zur Entwicklung von Software, sondern auch als Transformationshilfe verstanden und eingesetzt.

Nach zwei Sprints war die Transformation soweit fortgeschritten, dass das Team die Arbeiten an den Salesforce-Applikationen wieder aufnehmen konnten: Die Arbeitsumgebung war geschaffen, der Product Owner auf Kundenseite gefunden und trainiert, und die relevanten Stakeholder im Unternehmen waren überzeugt, sich auf das “Experiment Scrum” einzulassen.

Schnell stellten sich die ersten Erfolge ein, als das hochmotivierte Scrum Team bereits nach wenigen Wochen die ersten Erweiterungen der Salesforce-Applikationen zeigen und mit den Nutzern diskutieren konnten. Diese mussten sich freilich zunächst daran gewöhnen, nun häufiger kleinere Neuerungen und Verbesserungen zu Gesicht zu bekommen, dafür jedoch durch ihr Feedback die weitere Gestaltung direkter mitgestalten zu können. Dabei bleibt auch festzustellen, dass dieses inkrementelle Vorgehen nicht bei allen Kunden und Nutzern auf Gegenliebe gestoßen ist. Einige betrachteten die regelmäßigen Möglichkeiten zur direkten Einflussnahme auf die Entwicklung, zum Beispiel durch Sprint Reviews oder Teilnahme als Experte am Backlog Refinement, als eine zeitlich zu große Herausforderung; letztlich wurde dies von der ganz überwiegenden Zahl der Kunden und Nutzer jedoch als sehr wertvoll angesehen.

Durch die regelmäßig stattfindenden Sprint Retrospektiven, an denen direkt von Beginn an auch der Product Owner teilgenommen hat, hat das Scrum Team sich kontinuierlich verbessern können. So wurde zum Beispiel früh erkannt, dass die noch bestehende räumliche Trennung von Product Owner und Development Team für die reibungslose Zusammenarbeit und schnelles Feedback sehr hinderlich war. Unter anderem musste das Development-Team stellenweise länger als einen Tag auf den Review von User Stories durch den Product Owner warten. Damit vergrößerte sich das Risiko, dass durch den Product Owner gefundene Mängel nicht mehr rechtzeitig vor Ablauf des Sprints behoben werden konnten. Um dies von vornherein zu vermeiden, hatte das Scrum-Team einen Review durch den Product Owner auch zum Bestandteil der Definition of Done deklariert. Gelöst wurde dieses Impediment, indem der Product Owner seine Vorgesetzten überzeugen konnte, zum Standort des Development Teams umzuziehen - damals ein Novum in dem Unternehmen.

Durch den Aufbau und die Pflege eines für alle transparenten Product Backlogs sowie der Kommunikation einfacher Metriken wie Product Backlog Size, Velocity und Story-Point-Kosten wurde der massive Umfang der Entwicklung für alle sichtbar. Schnell wurde klar, dass diese Herausforderung nicht durch eine sofortige Skalierung des Scrum Teams, sondern am wirtschaftlichsten durch die Stakeholder und Nutzer selbst gelöst werden konnte: Vor der Einführung von Scrum hatte sich das Salesforce-Team in dem Versuch aufgerieben, widerstreitende Anforderungen und Prioritäten der Nutzer aufzulösen. Nun wurden die Konflikte transparent und an die Stakeholder und Nutzer adressiert. Dazu hat der Product Owner alle Key User regelmäßig zu Priorisierungs-Workshops eingeladen und diese moderiert. Dort konnten die Key User für “ihre Features” werben. Über die Priorität eines Features im Product Backlog wurde per Prioritization Poker entschieden. Beim Prioritization Poker wird auf spieltheoretische Ansätze zurückgegriffen, nach denen Beteiligte dann ein optimales Ergebnis erzielen, wenn sie mit anderen Beteiligten kooperieren. Hatten sich Key User früher über die Verwendung ihres Budgets gestritten, begannen sie nun, Features soweit möglich zu harmonisieren, ihr Budget zu kombinieren und damit mit einem größeren Budget die Priorisierung zu gestalten. Auch wenn damit nicht alle Widersprüche aufgelöst werden konnten, wurden die Prioritäten dennoch für die überwiegende Mehrheit der Key User positiv gesetzt und die Größe des Product Backlogs wirksam reduziert.

Da der Bedarf an Salesforce-Applikationen im Unternehmen weiterhin anstieg, musste sich in einem weiteren Schritt auch das Scrum Team vergrößern, was jedoch mit einer sinkenden Velocity einherging: Die Teamgröße von mehr als zehn Personen führte zu weniger effizienter Kommunikation und Zusammenarbeit. Das Scrum Team teilte sich in zwei Scrum Teams, stellte jedoch schnell fest, dass dies zwar den Output erhöhte, nicht aber das Outcome verbesserte. Im Rahmen einer längeren Reflexion betrachtete das Scrum Team daher den Gesamtprozess, angefangen mit der Analyse von Kundenbedürfnissen, über die Koordination von Abhängigkeiten zu anderen Teams, über Rollouts und Anwender-Trainings, bis hin zum Support der Salesforce-Applikationen. Um mehr Transparenz über die Arbeit und Abläufe außerhalb der Scrum-basierten Entwicklung zu erhalten, entschied sich das Team für den zusätzlichen Einsatz von Kanban-Prinzipien und -Praktiken.

Damit wurde der gesamte Wertstrom des Teams sichtbar, und das gewachsene Salesforce Team organisierte sich als Kanban Team. Der Scrum Flow wurde dabei in den Wertstrom des Kanban-Systems integriert und das Scrum Board als Teil der Kanban-Tafel visualisiert. Während ein “Kern”-Scrum Team weiterhin die Entwicklung der Salesforce-Applikationen vorantreibt, übernimmt das übrige Kanban Team die Kundenberatung und Bedürfnisanalyse (“upstream” vom Scrum Team) sowie die Roll-outs, Trainings und Anwenderbetreuung (“downstream” vom Scrum Team)." Abläufe, für die das “Kern”-Scrum Team nicht benötigt wird (z.B. Konfigurationsaufgaben), werden in einer separaten Swimlane auf der Kanban-Tafel visualisiert. Über “Work in Progress Limits” wird der Gesamtfluss gesteuert.

Durch die hier dargestellte Kombination von Scrum und Kanban werden vor allem die Aktivitäten, die dem Scrum Flow vorgelagert sind und üblicherweise als Aufgaben des Product Owners umrissen werden (z.B. Kommunikation mit Kunden, Beratung von Nutzern und Analyse von Anforderungen), transparent gemacht, in Einklang mit dem Fluss des Gesamtsystems gebracht und zudem auf mehrere Personen verteilt. Damit wird zugleich das Scrum Team entlastet, Wissen zu einzelnen Vertriebsprozessen untereinander stärker geteilt und die Key User in den Ländergesellschaften intensiver betreut. Gerade die so intensivierte Betreuung der Key User führt dazu, dass die Akzeptanz bereits vorhandener Salesforce-Applikationen bei den Key Usern gestärkt und so der Bedarf an weiteren, stellenweise redundanten Entwicklungen vermieden werden kann.

Mit Scrum hat das Salesforce Team viel Transparenz in die Entwicklung gebracht, signifikante Blockaden adressiert und die Produktivität mehr als verdoppelt. Durch die Kombination mit Kanban hat sich der Fokus aller Beteiligten auf kundenorientierte Wertgenerierung nochmals erhöht.