responsive website templates

 

 

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

Interesse an Scrum und Kanban?

Sie wollen Scrum und Kanban einsetzen, um schneler, flexibler, innovativer und kunde­norientierter zu werden? Wir helfen Ihnen und freuen uns auf Ihre Kontakt­aufnahme!

über Scrum
über Kanban
über JOHANNES GESKE - Guide to Business Agility

Johannes Geske ist Agile Coach für Führungskräfte und Teams. Mit agilen Prinzipien und Praktiken befasst er sich seit 2003. Aus Erfahrung weiß Johannes Geske, dass Unternehmen Agilität nicht allein durch viele agile Teams erreichen, sondern durch agile Interaktionen zwischen den an der unternehmerischen Wertschöpfung beteiligten Teams. Daher hilft Johannes Geske Unternehmen, den gesamten Wertstrom „from concept to cash“ agil zu gestalten und so Business Agility zu erreichen.

Johannes Geske ist Agile Coach, Enterprise Kanban Coach (EKC), Kanban Management Professional (KMP), Scrum Trainer, Scrum Master (SPS, PSM, PSPO, PSD) und Design Sprint Moderator und vermittelt agile Arbeitsweisen wie Design Sprints, Scrum und Kanban mit großer Leidenschaft.


Interesse an Scrum und Kanban?

Sie wollen Scrum und Kanban einsetzen, um schneler, flexibler, innovativer und kunde­norientierter zu werden? Wir helfen Ihnen und freuen uns auf Ihre Kontakt­aufnahme!