Für Hellmann Worldwide Logistics entwickelt Weber Data Service das Transport Management System DISPONENTplus entscheidend weiter. Die dabei erstmals angewendete agile Methode Scrum sorgt für schnelle Projektfortschritte und ein hohes Maß an Transparenz für Kunden und Entwickler.
Zwölf Uhr Mittags. Wie an jedem Arbeitstag trifft sich Jan van Lil mit seinen Kollegen zum täglichen Kurz-Meeting, dem so genannten "Daily Scrum". Jan van Lil ist Softwareentwickler beim Bielefelder Softwarehaus Weber Data Service und steckt in einem Großprojekt für Hellmann Worldwide Logistics. Die viertelstündigen Treffen sind für ihn als Scrum-Master wichtige Impulsgeber und fester Bestandteil des genutzten Scrum-Frameworks, mit der umfangreiche Projekte in kurze Planungs- und Entwicklungsphasen strukturiert werden. "Beim Daily Scrum berichten die Team-Mitglieder über die Veränderungen und Fortschritte der vergangenen 24 Stunden", sagt van Lil. Außerdem werde mitgeteilt, was bis zum nächsten Treffen erledigt werden soll und welche Hindernisse aufgetreten sind. Diese zu beseitigen ist u.a. Aufgabe des Scrum Masters.
Hellmann führt sukzessive an allen Standorten mit insgesamt mehr als 2.000 Anwendern die Speditionssoftware DISPONENTplus des IT-Dienstleisters Weber Data Service ein. Mit dem neuen Transport Management System löst Hellmann eine selbst entwickelte AS400-Lösung ab. Nachdem bereits der Bereich Teil- und Komplettladungen am Pilotstandort Crivitz bei Schwerin erfolgreich mit der neuen Lösung abwickelt wird, erfolgte im Februar 2016 die Umstellung des kompletten Sammelgutverkehrs auf DISPONENTplus. Im nächsten Schritt wird der deutschlandweite Rollout an weiteren Standorten starten.
Gerade für ambitionierte Projekte dieser Größenordnung empfiehlt sich der Einsatz von Scrum. Der Ansatz, mit der das Hellmann-Projekt zügig umgesetzt werden kann, bietet viele Vorteile gegenüber klassischen Entwicklungsmethoden und reduziert typische Schwierigkeiten von IT-Projekten: Nicht eingehaltene Zeitpläne, unklare Kundenwünsche, Missverständnisse zwischen Anwendern und Programmieren und unerwartete technische Hindernisse – aus diesen und anderen Gründen sind schon viele Projekte aus dem Budget- und Zeitrahmen gelaufen, manche gar ganz gescheitert. Auf diese Weise kann das Hellmann-Projekt zügig umgesetzt werden.
Anforderungen oft zu komplex
Der englische Begriff Scrum bedeutet so viel wie "Gedränge" und bezeichnet hier einen Handlungsrahmen für das Projektmanagement. Dieser beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um einen vollumfänglichen Plan erstellen zu können. "Derart umfangreiche Aufgaben zeichnen sich dadurch aus, dass ein wesentlicher Teil der Anforderungen und Lösungsansätze viel zu dynamisch sind, um zu Beginn des Projekts in einem Pflichtenheft für die nächsten Jahre festgeschrieben zu werden", erklärt der Scrum-Experte Jan van Lil von Weber Data Service.
Hohe Planungsdisziplin
Diese Dynamik und die daraus resultierende Unsicherheit lassen sich bei komplexen Aufgaben beseitigen, indem man sich in kleinen Schritten iterativ an die Lösung heranarbeitet. Anhand konkreter Zwischenergebnisse – den so genannten Increments – lassen sich die genauen Anforderungen und Lösungstechniken zeitnah und wirtschaftlicher klären, als durch eine abstrakte Spezifikationsphase ohne Zwischenergebnisse.
In Scrum wird neben dem Produkt deshalb auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan – das Product Backlog – wird kontinuierlich detailliert und verbessert. Statt einem vollumfänglichen Plan im Sinne eines Pflichtenheftes wird in Scrum ein Detailplan – das Sprint Backlog – nur für den jeweils nächsten Zyklus – dem Sprint – erstellt. Jeder Sprint ist zeitlich klar fixiert und wird, auch wenn die Funktionalität nicht fertig ist, nicht verlängert.
Kleine Häppchen
Scrum gehört damit zu den agilen Entwicklungsmethoden für Software. "Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist", sagt van Lil. Scrum kann die Komplexität der Aufgabe nicht reduzieren, strukturiert diese aber in kleinere und weniger komplexe „Häppchen“ und erfordert ein hohes Maß an Planungsdisziplin. Das Projekt ist in Sprints mit einer Dauer von jeweils zwei Wochen aufgeteilt. Danach wird das Product Increment ausgeliefert, von den Auftraggebern getestet und abgenommen oder mit Nachbesserungswünschen zurückgegeben.
Scrum ist nicht die einzige agile Methode, gilt jedoch aufgrund der geringen Zahl an Regeln als vergleichsweise einfach beherrschbar und universell einsetzbar. Regeln definieren für jedes Projekt drei Rollen, die den Kern von Scrum ausmachen. Es gibt den Product Owner, den Scrum Master und das Scrum-Team. Der Product Owner vertritt – vereinfacht beschrieben –die Interessen des Auftraggebers und seiner Anwender, der Scrum-Master ist zuständig für die Einhaltung bestimmter Spielregeln im Projekt. Das Scrum-Team schließlich übernimmt die tatsächliche Umsetzung. Der Product Owner trägt die Budget-Verantwortung, während die Projekt-Verantwortung vom gesamten Team übernommen wird.
Wünsche in Alltagssprache
Hellmann definiert seine Anforderungen an DISPONENTplus und gibt sie an die funktionalen Experten weiter. Diese werden hinsichtlich ihrer Relevanz für einen allgemeinen Produktstandard sowie den Auswirkungen auf die übrigen Kunden von Weber Data Service geprüft. Zusammen mit dem Product Owner legen die funktionalen Experten dann eine so genannte "User Story" fest. Dabei handelt es sich um eine Art „Anwender-Erzählung“, die in Alltagssprache ganz bestimmte Informationen enthalten muss. "Die User Story zeigt auf, wer was und zu welchem Zweck benötigt", erläutert van Lil und nennt ein Beispiel: „Ein Erfasser von Aufträgen möchte das Feld Auftragsart automatisch mit dem Begriff „Direct Load“ vorbelegen lassen, um Zeit zu sparen“. Die einzelnen User Stories umfassen in der Regel nicht mehr als zwei Sätze.
Alle User Stories bilden zusammen das Product Backlog, eine Art langfristigen Plan, den man am ehesten mit dem altbekannten Pflichtenheft vergleichen könnte. Am Ende wird gemeinsam priorisiert, was die Software können soll.
Selbstbestimmung motiviert
Zu Beginn jedes Sprints findet als Kick-Off das Sprint Planning Meeting statt. Dabei präsentiert der Product Owner dem Scrum-Team die nächsten Punkte des Product Backlogs. Gemeinsam wird festgelegt, wie das Product Backlog im kommenden Sprint umgesetzt wird. Das Scrum-Team schätzt den Aufwand und legt selber fest, wie viel es von der gewünschten Funktionalität im kommenden Sprint tatsächlich schaffen kann. Damit verpflichtet sich das Team in einem Commitment, diesen Meilenstein auch zu schaffen.
Ambitionierter Zeitplan
Jeden zweiten Montag - am Ende eines Sprint-Zeitraums - findet bei Weber Data Service ein "Sprint Review" mit Hellmann statt. Diese Treffen dauern etwa drei bis fünf Stunden. Dabei berichtet das Scrum-Team an den Product Owner die zwischenzeitlich entwickelten Funktionalitäten. Er entscheidet dann, ob er die Userstory abnimmt oder ob nachgebessert werden muss. Beim Sprint Review wird zudem geprüft, ob und inwiefern sich das Product Backlog innerhalb des vergangenen Sprints verändert hat.
„In der anschließenden Sprint-Retrospektive reflektiert unser Team, was im zurückliegenden Abschnitt gut und was weniger gut gelaufen ist" und überlegt sich, wie zukünftig effizienter und effektiver gearbeitet werden kann“, so Astrid Drexhage, Geschäftsführerin bei Weber Data Service. Für sie liegen die Vorteile auf der Hand. "Mit Scrum lassen sich auch ambitionierte Zeitpläne umsetzen", ist sie überzeugt.
Grundsätzlich erzeugt Scrum ein hohes Maß an Transparenz. Durch das iterative Vorgehen werden Hindernisse sichtbar und man könne im Zwei-Wochen-Rhythmus zeitnah, quasi just-in-time, auf jede Änderung reagieren. Alle sind aktiv in den Prozess eingebunden und kontinuierlich werden fertige Produktfunktionalitäten geliefert. Dazu sind auch die Entwickler sehr zufrieden. „Wir tragen zwar mehr Verantwortung, aber das hohe Maß an Selbstbestimmung, die klare Fokussierung auf das Team und nicht auf einzelne Entwickler führt zu deutlich mehr Motivation und Identifikation mit der Arbeit", stellt van Lil fest. Kein Wunder, dass inzwischen auch die Service-Abteilung von Weber Data Service Teile der Scrum-Methode übernommen hat. Täglich um 8.30 Uhr tauscht man sich darüber aus, welcher Kunde sich mit welcher Frage gemeldet hat, welche Kundenanforderungen bereits umgesetzt wurden und welcher Mitarbeiter wann zu welchem Kunden fährt. Scrum ist eben universell.
Hintergrund: Scrum
Ziel von Scrum ist die schnelle, kostengünstige und qualitativ hochwertige Entwicklung von Produkten entsprechend einer formulierten Vision. Das Umsetzen der Vision erfolgt dabei nicht mit Pflichtenheften, die dann phasenweise umgesetzt werden. Stattdessen werden in Scrum die Anforderungen in Form klarer Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen ist das Product Backlog. Diese Anforderungen werden Stück für Stück in zwei bis vier Wochen langen Intervallen, sogenannten Sprints, iterativ und inkrementell umgesetzt. Am Ende eines jeden Sprints steht bei Scrum die Lieferung eines fertigen Teilprodukts, das Product Increment. Dieses sollte in einem Zustand sein, dass es an den Kunden ausgeliefert werden kann. Im Anschluss an den Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.
Zwölf Uhr Mittags. Wie an jedem Arbeitstag trifft sich Jan van Lil mit seinen Kollegen zum täglichen Kurz-Meeting, dem so genannten "Daily Scrum". Jan van Lil ist Softwareentwickler beim Bielefelder Softwarehaus Weber Data Service und steckt in einem Großprojekt für Hellmann Worldwide Logistics. Die viertelstündigen Treffen sind für ihn als Scrum-Master wichtige Impulsgeber und fester Bestandteil des genutzten Scrum-Frameworks, mit der umfangreiche Projekte in kurze Planungs- und Entwicklungsphasen strukturiert werden. "Beim Daily Scrum berichten die Team-Mitglieder über die Veränderungen und Fortschritte der vergangenen 24 Stunden", sagt van Lil. Außerdem werde mitgeteilt, was bis zum nächsten Treffen erledigt werden soll und welche Hindernisse aufgetreten sind. Diese zu beseitigen ist u.a. Aufgabe des Scrum Masters.
Hellmann führt sukzessive an allen Standorten mit insgesamt mehr als 2.000 Anwendern die Speditionssoftware DISPONENTplus des IT-Dienstleisters Weber Data Service ein. Mit dem neuen Transport Management System löst Hellmann eine selbst entwickelte AS400-Lösung ab. Nachdem bereits der Bereich Teil- und Komplettladungen am Pilotstandort Crivitz bei Schwerin erfolgreich mit der neuen Lösung abwickelt wird, erfolgte im Februar 2016 die Umstellung des kompletten Sammelgutverkehrs auf DISPONENTplus. Im nächsten Schritt wird der deutschlandweite Rollout an weiteren Standorten starten.
Gerade für ambitionierte Projekte dieser Größenordnung empfiehlt sich der Einsatz von Scrum. Der Ansatz, mit der das Hellmann-Projekt zügig umgesetzt werden kann, bietet viele Vorteile gegenüber klassischen Entwicklungsmethoden und reduziert typische Schwierigkeiten von IT-Projekten: Nicht eingehaltene Zeitpläne, unklare Kundenwünsche, Missverständnisse zwischen Anwendern und Programmieren und unerwartete technische Hindernisse – aus diesen und anderen Gründen sind schon viele Projekte aus dem Budget- und Zeitrahmen gelaufen, manche gar ganz gescheitert. Auf diese Weise kann das Hellmann-Projekt zügig umgesetzt werden.
Anforderungen oft zu komplex
Der englische Begriff Scrum bedeutet so viel wie "Gedränge" und bezeichnet hier einen Handlungsrahmen für das Projektmanagement. Dieser beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um einen vollumfänglichen Plan erstellen zu können. "Derart umfangreiche Aufgaben zeichnen sich dadurch aus, dass ein wesentlicher Teil der Anforderungen und Lösungsansätze viel zu dynamisch sind, um zu Beginn des Projekts in einem Pflichtenheft für die nächsten Jahre festgeschrieben zu werden", erklärt der Scrum-Experte Jan van Lil von Weber Data Service.
Hohe Planungsdisziplin
Diese Dynamik und die daraus resultierende Unsicherheit lassen sich bei komplexen Aufgaben beseitigen, indem man sich in kleinen Schritten iterativ an die Lösung heranarbeitet. Anhand konkreter Zwischenergebnisse – den so genannten Increments – lassen sich die genauen Anforderungen und Lösungstechniken zeitnah und wirtschaftlicher klären, als durch eine abstrakte Spezifikationsphase ohne Zwischenergebnisse.
In Scrum wird neben dem Produkt deshalb auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan – das Product Backlog – wird kontinuierlich detailliert und verbessert. Statt einem vollumfänglichen Plan im Sinne eines Pflichtenheftes wird in Scrum ein Detailplan – das Sprint Backlog – nur für den jeweils nächsten Zyklus – dem Sprint – erstellt. Jeder Sprint ist zeitlich klar fixiert und wird, auch wenn die Funktionalität nicht fertig ist, nicht verlängert.
Kleine Häppchen
Scrum gehört damit zu den agilen Entwicklungsmethoden für Software. "Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist", sagt van Lil. Scrum kann die Komplexität der Aufgabe nicht reduzieren, strukturiert diese aber in kleinere und weniger komplexe „Häppchen“ und erfordert ein hohes Maß an Planungsdisziplin. Das Projekt ist in Sprints mit einer Dauer von jeweils zwei Wochen aufgeteilt. Danach wird das Product Increment ausgeliefert, von den Auftraggebern getestet und abgenommen oder mit Nachbesserungswünschen zurückgegeben.
Scrum ist nicht die einzige agile Methode, gilt jedoch aufgrund der geringen Zahl an Regeln als vergleichsweise einfach beherrschbar und universell einsetzbar. Regeln definieren für jedes Projekt drei Rollen, die den Kern von Scrum ausmachen. Es gibt den Product Owner, den Scrum Master und das Scrum-Team. Der Product Owner vertritt – vereinfacht beschrieben –die Interessen des Auftraggebers und seiner Anwender, der Scrum-Master ist zuständig für die Einhaltung bestimmter Spielregeln im Projekt. Das Scrum-Team schließlich übernimmt die tatsächliche Umsetzung. Der Product Owner trägt die Budget-Verantwortung, während die Projekt-Verantwortung vom gesamten Team übernommen wird.
Wünsche in Alltagssprache
Hellmann definiert seine Anforderungen an DISPONENTplus und gibt sie an die funktionalen Experten weiter. Diese werden hinsichtlich ihrer Relevanz für einen allgemeinen Produktstandard sowie den Auswirkungen auf die übrigen Kunden von Weber Data Service geprüft. Zusammen mit dem Product Owner legen die funktionalen Experten dann eine so genannte "User Story" fest. Dabei handelt es sich um eine Art „Anwender-Erzählung“, die in Alltagssprache ganz bestimmte Informationen enthalten muss. "Die User Story zeigt auf, wer was und zu welchem Zweck benötigt", erläutert van Lil und nennt ein Beispiel: „Ein Erfasser von Aufträgen möchte das Feld Auftragsart automatisch mit dem Begriff „Direct Load“ vorbelegen lassen, um Zeit zu sparen“. Die einzelnen User Stories umfassen in der Regel nicht mehr als zwei Sätze.
Alle User Stories bilden zusammen das Product Backlog, eine Art langfristigen Plan, den man am ehesten mit dem altbekannten Pflichtenheft vergleichen könnte. Am Ende wird gemeinsam priorisiert, was die Software können soll.
Selbstbestimmung motiviert
Zu Beginn jedes Sprints findet als Kick-Off das Sprint Planning Meeting statt. Dabei präsentiert der Product Owner dem Scrum-Team die nächsten Punkte des Product Backlogs. Gemeinsam wird festgelegt, wie das Product Backlog im kommenden Sprint umgesetzt wird. Das Scrum-Team schätzt den Aufwand und legt selber fest, wie viel es von der gewünschten Funktionalität im kommenden Sprint tatsächlich schaffen kann. Damit verpflichtet sich das Team in einem Commitment, diesen Meilenstein auch zu schaffen.
Ambitionierter Zeitplan
Jeden zweiten Montag - am Ende eines Sprint-Zeitraums - findet bei Weber Data Service ein "Sprint Review" mit Hellmann statt. Diese Treffen dauern etwa drei bis fünf Stunden. Dabei berichtet das Scrum-Team an den Product Owner die zwischenzeitlich entwickelten Funktionalitäten. Er entscheidet dann, ob er die Userstory abnimmt oder ob nachgebessert werden muss. Beim Sprint Review wird zudem geprüft, ob und inwiefern sich das Product Backlog innerhalb des vergangenen Sprints verändert hat.
„In der anschließenden Sprint-Retrospektive reflektiert unser Team, was im zurückliegenden Abschnitt gut und was weniger gut gelaufen ist" und überlegt sich, wie zukünftig effizienter und effektiver gearbeitet werden kann“, so Astrid Drexhage, Geschäftsführerin bei Weber Data Service. Für sie liegen die Vorteile auf der Hand. "Mit Scrum lassen sich auch ambitionierte Zeitpläne umsetzen", ist sie überzeugt.
Grundsätzlich erzeugt Scrum ein hohes Maß an Transparenz. Durch das iterative Vorgehen werden Hindernisse sichtbar und man könne im Zwei-Wochen-Rhythmus zeitnah, quasi just-in-time, auf jede Änderung reagieren. Alle sind aktiv in den Prozess eingebunden und kontinuierlich werden fertige Produktfunktionalitäten geliefert. Dazu sind auch die Entwickler sehr zufrieden. „Wir tragen zwar mehr Verantwortung, aber das hohe Maß an Selbstbestimmung, die klare Fokussierung auf das Team und nicht auf einzelne Entwickler führt zu deutlich mehr Motivation und Identifikation mit der Arbeit", stellt van Lil fest. Kein Wunder, dass inzwischen auch die Service-Abteilung von Weber Data Service Teile der Scrum-Methode übernommen hat. Täglich um 8.30 Uhr tauscht man sich darüber aus, welcher Kunde sich mit welcher Frage gemeldet hat, welche Kundenanforderungen bereits umgesetzt wurden und welcher Mitarbeiter wann zu welchem Kunden fährt. Scrum ist eben universell.
Hintergrund: Scrum
Ziel von Scrum ist die schnelle, kostengünstige und qualitativ hochwertige Entwicklung von Produkten entsprechend einer formulierten Vision. Das Umsetzen der Vision erfolgt dabei nicht mit Pflichtenheften, die dann phasenweise umgesetzt werden. Stattdessen werden in Scrum die Anforderungen in Form klarer Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen ist das Product Backlog. Diese Anforderungen werden Stück für Stück in zwei bis vier Wochen langen Intervallen, sogenannten Sprints, iterativ und inkrementell umgesetzt. Am Ende eines jeden Sprints steht bei Scrum die Lieferung eines fertigen Teilprodukts, das Product Increment. Dieses sollte in einem Zustand sein, dass es an den Kunden ausgeliefert werden kann. Im Anschluss an den Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.
