Optimierung des agilen Ansatzes: Fünf Schritte zu einer besseren Sprint-Planung in SAP
Bei Basis Technologies sind wir so überzeugt davon, dass die agile Entwicklung und DevOps-Tools SAP-Workflows revolutionieren können, dass wir diese Ansätze beim Erstellen unserer Produkte selbst anwenden. Bei der agilen Entwicklung werden Projekte in kleinere Einheiten, die so genannten Sprints, aufgeschlüsselt. Ihre Funktionsweise zu verstehen ist der erste wichtige Schritt für eine erfolgreiche Umsetzung agiler Verfahren.
Natürlich wissen wir, dass nicht alle Unternehmen auf demselben Stand bei der Einführung agiler und DevOps-Methoden sind. Daher wollen wir an dieser Stelle ein wenig über unsere Erfahrungswerte berichten. Wir haben uns mit dem Product Owner für unsere ActiveControl-Lösung zusammengesetzt und ihn um einige Tipps zur optimalen Planung eines agilen Sprints in SAP gebeten.
Und hier ist, was er zu sagen hatte:
Ein Teil meiner Arbeit als Product Owner unseres Produkts ActiveControl fühlt sich ein bisschen wie Weihnachten an … mit der Ausnahme, dass nicht nur einmal im Jahr der große Tag ist, sondern alle zwei Wochen.
Der Grund dafür ist, dass wir bei Basis Technologies mit einem zweiwöchigen agilen Sprintzyklus arbeiten. Zu Beginn jedes Zyklus schreibe ich einen „Wunschzettel“ für unser Entwicklungsteam. Genauer gesagt haben wir ein Meeting für die Sprint-Planung, bei dem ich erläutere, welche Arbeiten ganz oben im Backlog stehen und im bevorstehenden Sprint realisiert werden sollen.
Vierzehn Tage später erhalte ich dann beim Sprint-Review-Meeting als Ergebnis die verschiedenen, hübsch verpackten User Stories für mich (oder vielmehr für unsere Kunden) von unserem Entwicklungsteam.
Es kommt tatsächlich alle zwei Wochen so etwas wie weihnachtliche Vorfreude auf. Denn seit ich der Product Owner von ActiveControl bin, haben meine Entwicklerkollegen über die letzten Jahre hinweg durchgängig großartige Arbeit geleistet und mit jedem Sprint Verbesserungen bereitgestellt, die unseren Kunden in zukünftigen Versionen von ActiveControl einen Mehrwert und eine höhere Rentabilität bieten werden.
Mit diesen Entwicklungen sind wir weit entfernt von den Zeiten des Wasserfallmodells, das ich noch aus grauen Vorzeiten aus meinen Jahren als SAP Change & Release Manager kenne. SAP-Projekte liefen damals noch ein bis zwei Jahre, bevor der Kunde (d.h. der geschäftliche Endanwender) überhaupt irgendwelche Änderungen (oder eine Wertsteigerung) bemerkte.
Zudem arbeiten heute viele SAP-Kunden ganz anders als damals – oder jedenfalls viele der Unternehmen, mit denen Basis Technologies arbeitet. Es gibt einige beeindruckende Beispiele von großen Unternehmen, die den agilen Ansatz erfolgreich mit SAP umsetzen. Beispielsweise veranschaulicht diese aktuelle Kundenfallstudie, wie ein bekannter Einzelhandelskonzern den Sprung von einem 3-monatigen Releasezyklus zu einem zweiwöchigen agilen Sprintzyklus schaffte. Und mit dieser schnelleren Wertschöpfung für das Unternehmen steht der Konzern nicht allein da. Andere SAP-Kunden, wie Vistaprint, John Deere und IPG haben mit ActiveControl erfolgreich agile Transformationsprozesse umgesetzt und etabliert.
Eine der Fragen, die wir häufig von anderen SAP-Kunden gestellt bekommen, die einige dieser erfolgreichen agilen Ansätze für sich umsetzen möchten, ist: „Wie planen wir einen agilen Sprint in SAP“?
Unabhängig davon, ob Änderungen an SAP, an ActiveControl oder im Rahmen einer Softwareentwicklung vorgenommen werden, bleibt die Antwort auf diese Frage meiner Meinung nach weitestgehend dieselbe.
Es braucht folgende fünf einfache Schritte …
Schritt 1: Bewertung der Produkt-Roadmap
Ein agiler Sprint zielt auf eine schnellere Bereitstellung von Verbesserungen für Softwareanwendungen ab. Ganz gleich, ob der Zeitrahmen für diesen Sprint zwei oder drei Wochen ist (oder sogar vier Wochen, was die allgemein akzeptierte Obergrenze für einen agilen Sprint ist): Das Ergebnis am Ende des Sprints sollte ein nutzbares Produktinkrement sein, das in die Produktion übergeben werden kann.
Wichtig hierbei ist anzumerken, dass dies nicht bedeutet, dass am Ende jedes Sprints immer unbedingt etwas für Anwender in Produktionsumgebungen bereitgestellt werden muss; in der Welt von SAP ist dies bekanntermaßen ja nicht immer möglich.
Die Verantwortung liegt beim Product Owner, der genau wissen sollte, wie das Produkt optimal weiterentwickelt werden sollte. Findet die Entwicklung im Widerspruch zur Produkt-Roadmap statt? Oder gibt es zu viel Ablenkung durch kurzzeitige Probleme (oder Anwender, die immer etwas anzumerken haben)?
Der erste Schritt bei der Planung und Vorbereitung von Sprints ist zu entscheiden/wissen, wo man in sechs Monaten, einem Jahr oder sogar mehr stehen möchten, nicht nur nach dem nächsten Sprint.
Schritt 2: Vorhandensein einer aktualisierten Liste mit User Stories vor dem Meeting für die Sprint-Planung
Vor dem Meeting für die Sprint-Planung sollten die User Stories, die im Rahmen des bevorstehenden Sprints bereitgestellt werden sollen, dem Scrum-Team für eine umfassende Prüfung und Verwendung zur Verfügung stehen. Dafür ist der Product Owner verantwortlich, da ihm/ihr letztendlich die Roadmap und Produktvision und im weiteren Sinne auch die Priorisierung des Produkt-Backlogs unterliegt.
Ich persönlich habe auch gerne eine grobe Idee über den Zeitrahmen und den Aufwand für jede der projektbezogenen Arbeiten, die weit oben im Backlog stehen. Dies hilft nicht nur dabei zu entscheiden, was im Rahmen des nächsten Sprints erreicht werden kann, sondern unterstützt den Scrum Master und mich als Product Owner bei der effektiven Verwaltung des Gesamtbudgets und Zeitrahmens für das Projekt.
Schritt 3: Regelungen für Meetings
Meetings für die Sprint-Planung sind auf maximal acht Stunden für einen einmonatigen Sprint begrenzt. Bei kürzeren Sprints sind sie in der Regel kürzer.
Hier bei Basis Technologies mit unseren zweiwöchigen Sprints dauert das Planungs-Meeting für gewöhnlich ein bis zwei Stunden. Es findet jeden zweiten Donnerstag pünktlich um 13 Uhr statt.
Im Agile Manifesto wird darüber gesprochen, wie „Konsistenz die Komplexität verringert und dadurch die Vorhersagbarkeit optimiert“ – das kann ich auf jeden Fall so unterschreiben. Viele SAP-Unternehmen sind durch virtuelle Teams geprägt und auch bei Basis Technologies arbeiten in Zeiten nach der Pandemie immer noch viele von uns im Homeoffice. Meiner Meinung nach ist es von Vorteil, Meetings für die Sprint-Planung immer zur selben Zeit abzuhalten, da mit jedem Mal die Chance größer wird, dass das Scrum-Team pünktlich zum Meeting erscheint.
So jedenfalls die Theorie 😉
Schritt 4: Nutzung von Daten und Know-how zur ständigen Verbesserung der Sprint-Planung
SAP-Teams bauen ihre Erfahrung in Sachen agile Entwicklung immer weiter aus. In diesem Zusammenhang können Daten die zukünftige Herangehensweise für eine erfolgreiche Sprint-Planung unterstützen. Hier bei Basis Technologies ist dies auf jeden Fall der Fall und ich bin mir sicher, dass dies auch auf unsere wachsende Zahl von SAP-Kunden zutrifft, die bereits agilere Ansätze bei der Softwareentwicklung nutzen.
Durch das Wissen und die Erfahrung aus früheren Sprints verfügen unser Scrum Master, das Entwicklungsteam und ich nun über empirische Daten (darüber), wie lange die Entwicklung bisheriger User Stories tatsächlich im Vergleich zu den Story Points, die als Ausgangspunkt dienten, gedauert hat. Außerdem haben wir basierend auf früheren Ergebnissen eine weitaus bessere Vorstellung, was einzelne Entwickler erreichen können.
Zudem spielen Sprint-Retrospektiven eine wichtige Rolle bei der Verbesserung zukünftiger Sprint-Planungen. Dieses Meeting am Ende eines Sprints zeigt Möglichkeiten auf, wie die Qualität und Effektivität der Arbeit im Team gesteigert werden kann und gleichzeitig – obwohl ich es nicht gerne zugebe – auch ich als Product Owner durch verbesserte Arbeitsweisen den Prozessablauf optimieren kann.
Nein, das habe ich so nicht gesagt – ich bin natürlich stolz, es zuzugeben! Nur dadurch, dass wir unsere eigenen Schwächen eingestehen und Bereiche für zukünftige Verbesserungen ausmachen, können wir als agiles Team gemeinsam daran arbeiten, zukünftige Sprints effektiver zu gestalten.
Schritt 5: Gemeinsame Planung des Sprint-Backlogs
Das Sprint-Backlog ist die Liste der User Stories, die im Rahmen des anstehenden Sprints bereitgestellt werden sollen, um das Sprintziel zu erreichen.
Das Sprint-Backlog muss gemeinsam geplant werden und darf nicht die alleinige des Product Owners oder Scrum Masters sein. Das Team muss gemeinsam die projektbezogenen Leistungen für den Sprint und den Umfang des Sprint-Backlogs festlegen. Es gibt diejenigen, die zur Verwirklichung der Produkte beitragen. Gleichzeitig muss es aber auch diejenigen geben, die entscheiden, was sie beitragen.
Dies sind also die fünf Bereiche, die meiner Meinung nach unbedingt als Teil der Sprint-Planung in SAP berücksichtigt werden sollten. Die Sprint-Planung ist ein wichtiger Teil der agilen Entwicklung und sollte für SAP-Unternehmen bei ihrem Weg hin zu einem agileren Ansatz der Softwareentwicklung unbedingt ein integrierter Bestandteil ihrer Prozesse sein.
Und da wir schon davon reden: Es ist gerade 12:39 Uhr an einem Donnerstag und mein nächstes Meeting für die Sprint-Planung beginnt in 21 Minuten. Frohe Weihnachten!
Wenn Sie mehr über das Anwenden agiler Prinzipien in Ihrer SAP-Umgebung erfahren möchten, kontaktieren Sie uns bitte.
