Mobirise

 

 

Harmonisierung von Salesforce-Applikationen mit Scrum & Kanban

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

Kontext
Ein internationales Industrie­unternehmen setzt Salesforce ein, um die Vertriebsprozesse der Vertriebs­gesellschaften zu steuern. Ein Team aus Prozess­beratern, Entwicklern, Administratoren und Support-Mitarbeitern ist 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 projekt­orientierten Vorgehensweise hat das Salesforce Team nach einem besseren Weg gesucht, die Anforderungen von mehr als zwei Dutzend Vertriebs­gesellschaften umzusetzen. Motiviert durch die Erfolgsgeschichte eines in die Krise geratenen Projekts im Unternehmen, bei dem JOHANNES GESKE durch Scrum und DevOps einen erfolgreichen Abschluss herbeiführen konnte, hat das Team auf eigenen Wunsch Scrum eingeführt.
Lösung
Durch ein Scrum Training hat das Team das nötige Grund­verständnis und Prozess­bewusstsein entwickelt und damit die Voraus­setzungen 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 wenigen Sprints waren die entsprechenden Voraussetzungen geschaffen und die ersten Erfolge stellten sich ein, als das hochmotivierte Scrum Team neue Salesforce-Applikationen zeigen und mit den Nutzern diskutieren konnte.

Durch regelmäßig stattfindende Sprint Retrospektiven, an denen von Beginn an auch der Product Owner teilnahm, hat sich das Scrum Team kontinuierlich verbessern können. So wurde zum Beispiel frühzeitig erkannt, dass die bestehende räumliche Trennung von Product Owner und Development Team für die reibungslose Zusammenarbeit und schnelles Feedback hinderlich war. 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 Nutzung einfacher Metriken wie Product Backlog Size, Velocity und Kosten je Story Point 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, konkurrierende 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. Hatten die Key User früher ihres Budgets separat verwendet, 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 den Kundenbedürfnissen, über die Koordination von Abhängigkeiten zwischen Teams, über Rollouts und Anwendertrainings, bis hin zum Betrieb und Support der Salesforce-Applikationen.

Um mehr Transparenz über die Arbeiten und Abläufe außerhalb der eigentlichen Entwicklung zu erhalten, entschied sich das Team für den zusätzlichen Einsatz von Kanban als Ergänzung zu Scrum. Damit wurde der gesamte Wertstrom sichtbar gemacht. Der Scrum Flow wurde dabei in den Wertstrom des Kanban-Systems integriert und das Scrum Board als Teil der Kanban-Tafel visualisiert. Über “Work in Progress Limits” wird der Gesamtfluss gesteuert.

Durch diese 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 Development 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.

Teilen Sie diese Seite

Über Scrum
Scrum ist ein Framework, das seit den 1990er Jahren zur Entwicklung komplexer Produkte eingesetzt wird. Das Scrum Framework besteht aus Scrum Teams und den zu ihnen gehörenden Rollen (Product Owner, Development Team, Scrum Master),Ereignissen (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive), Artefakten (Product Increment, Product Backlog und Sprint Backlog) und Regeln.1
Über Kanban
Kanban ist eine Methode, mit der Wissensarbeit organisiert und verbessert und sowohl physische als auch immaterielle Leistungen erzeugt werden können. Unternehmen können sich mit Kanban gezielt verändern und so nachhaltige Verbesserungen der eigenen Leistungsfähigkeit und der Kundenzufriedenheit erzielen.2

1: The Scrum Guide, http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf, 02.04.2017.
2: Die Essenz von Kanban, David J. Anderson, Andy Carmichael, dpunkt.verlag 2018.

Interesse an Scrum & Kanban?

Sie möchten mehr darüber erfahren, wie Sie mit Scrum und Kanban agiler werden? Kontaktieren Sie uns!