SCRUM bei Lean Projekten

Die methodischen Grundlagen von Scrum habe ich in Yokoten 06/2014 (S. 15 ff) erläutert. Bezüglich der Einführung von Scrum gibt es eine gute Nachricht und eine schlechte: Die gute Nachricht ist, dass die Einführung von Scrum der Einführung von Lean sehr ähnelt; dies ist zugleich auch die schlechte Nachricht.

Der Start mit SCRUM

Wir haben damit begonnen, in der Hornbach Unternehmensentwicklung die Scrum-Methodik eins zu eins aus der IT zu übernehmen (s. Abb.). So starteten wir ein Projekt mit einem Product Backlog, in dem die einzelnen großen und testbaren Meilensteine ("Epics") definiert wurden. Innerhalb von Sprintplanungen verfeinerten wir diese in einer Granularität, dass eine "Story" von einem Mitarbeiter in maximal zwei Tagen erledigt werden konnte. In den täglichen, viertelstündigen Scrum-Meetings zwischen Projektleiter und Entwicklungsteam wurden die klassischen Fragen besprochen:

Die ersten Erfahrungen

• Was habe ich gestern getan, um das Ziel des Sprints zu erreichen? • Was werde ich heute tun, um das Ziel des Sprints zu erreichen? • Sehe ich irgendein Hindernis, welches uns davon abhält, das Ziel des Sprints zu erreichen?

Am Ende eines Sprints wurde in einem Sprint Review das erreichte Ziel vorgestellt und in einer Retrospektive die Zusammenarbeit innerhalb des Scrum Teams sowie die Zusammenarbeit mit externen Kollegen einem Feedback unterzogen. Hier wurde beschlossen, welche Änderungen man im nächsten Sprint einfließen lassen wollte. Danach startete mit einer weiteren Sprint-Planung der Prozess von vorne. leiter. Letzterer übergibt gewöhnlicherweise das Projekt an den Product Owner, wenn es im besten Falle beendet ist und die Entwicklungen operativ umgesetzt werden können. Die Folge ist, dass ein Projektleiter zwar sehr fundierte Erfahrungen zum Thema Projektmanagement hat. Allerdings ist er kein Spezialist, und er kann sich mit dem zu entwickelnden Projektergebnis nicht von Anfang an auskennen. Ein weiteres Problem in diesem Zusammenhang ist oft, dass während des Projektes noch gar nicht klar ist, wer es am Ende operativ betreuen soll.

Eingangs hatte ich erwähnt, dass die gute und die schlechte Nachricht die ist, dass die Einführung von neuen Methoden sich ähnelt. Nach einer anfänglichen Euphorie haben sich nach und nach wieder alte Gewohnheiten im Projektteam eingeschlichen.

Das tägliche Scrum Meeting stellt ein kurzes informelles Planungstreffen dar. Jeder informiert jeden über den aktuellen Stand der einzelnen Stories, die bereits in Arbeit sind, oder am Vortag abgearbeitet wurden. Sehr schnell wandelte sich dies in die Richtung, dass hier im großen Kreis Diskussionen geführt wurden. Weiterhin nahm der Projektleiter sehr schnell wieder seine "klassische" Rolle ein und ließ sich den Status zu den einzelnen Arbeitspaketen berichten. Die einzelnen Arbeitspakete wurden schnell wieder vom Projektleiter zugeteilt. Dadurch wurde jedoch die Freiheit von Scrum eingeengt. Scrum lebt davon, dass die Mitglieder des Entwicklungsteams in einem Freiraum miteinander agieren können,

Ein Product Owner ist im klassischen Scrum derjenige, der nach der Entwicklung das Ergebnis als operativer Träger übernimmt. Dies stellt zum einen sicher, dass er entscheiden kann, wann ein Projekt wirklich beendet ist und er zugleich auch gegenüber seinen Stakeholdern das Ergebnis vertreten muss, hat er doch die Anforderungen gestellt und das Projekt die gesamte Zeit über begleitet. Dadurch ist ein Product Owner eben gerade nicht der klassische Projektohne Einwirkungen von außen. Sie sind die Spezialisten, die am besten wissen, was sie können und wo sie besonders effizient und effektiv sein können. Der Projektleiter ist im Themenfeld Scrum eine "dienende Führungskraft", der dem Entwicklungsteam genau diesen Freiraum ermöglichen muss.

Zu Beginn der Einführung von Scrum nahm die Geschwindigkeit, mit der das Projekt voran ging, deutlich zu. Schnell war der Punkt erreicht, an dem die dem Projekt zuarbeitenden Organisationsteile (IT, Rechtsabteilung, etc.) der Geschwindigkeit nicht folgen konnten. Ziel von Scrum ist nicht das Verkürzen der Dauer von Projekten, sondern die Verbesserung der Qualität, dennoch wird meist durch die Freiheit des Entwicklungsteams eine Verkürzung der Projektdauer erreicht. Wir mussten uns mit dem Problem auseinandersetzen, wie man andere Abteilungen ins Boot holen kann.

Das Besinnen auf die Vision

Aufgrund der Agilität, der höheren Geschwindigkeit und der steten Veränderung ist eine Dokumentation, die diesen Anforderungen gerecht werden muss, sehr schwer. Es gibt softwarebasierte Unterstützung wie beispielsweise das von Altlassian entwickelte Programm Jira. Es handelt sich dabei um ein Ticketsystem, das zwischen den Teilnehmern ein Zuweisen von Aufgaben ermöglicht. Durch Kommentierungen hat man eine Art Dokumentation, die jedoch eher untypisch ist. Wir haben besonders gute Erfahrungen mit One Note (Microsoft Windows) gemacht. Beides zusammen bietet eine gute Dokumentationsgrundlage. Da sehr schnell die Projektleiter wieder in die klassische Rolle verfielen, tauchten auch die Wasserfalldiagramme wieder auf. Zudem kam es zu Statuslisten mit Viertel-/Halb-/ Dreiviertel-Kreisen. Am Ende wurden Jira, One Note, eine Excelliste mit To

Scrum Team

Daily Scrum

Do’s und eine Powerpoint mit Wasserfalldiagrammen geführt. Keine der Listen stimmte mit einer anderen überein.

• Wo hilft mir die Scrum-Methodik, wo wird sie angenommen und wo lebt sie gerade nicht? (Auch wir mussten lernen, dass nicht jeder Teil von Scrum für uns das Richtige ist. Man muss den Mut haben, seinen eigenen, der Unternehmenskultur angepassten, Agilitätsbegriffzu finden). • Was kann ich besser machen? (Scrum lebt auch von der Retrospektive. Nutzen sie diese Form des Feedbacks und Coachings um ihren eigenen Weg zur Agilität zu finden).

Trotz all dieser Punkte werden die in der Unternehmensentwicklung gemachten Erfahrungen als sehr positiv gewertet, und wir treiben die Anwendung der Scrum Methode weiter voran.

Nach einem Jahr mit Scrum hatten wir uns zusammengesetzt und oben dargelegte Punkte für uns formuliert. Ich bin davon überzeugt, dass der bis dahin genommene Weg der richtige war. Zum Start hatten wir überlegt, ob die Einführung von "ein bisschen" Scrum eine Option wäre. Ich glaube, dass gerade die große Veränderung zu Beginn und das von heute auf morgen "mit Scrum leben müssen" dazu geführt hat, dass die Beteiligten viel intensiver spürten, an welcher Stelle die Veränderung passierte. Man muss dann allerdings den Mut haben, sich selbst zu hinterfragen und sich immer wieder folgende Fragen zu stellen:

Anpassungen

Nachdem wir uns die Abweichungen zum methodischen Scrum-Framework bewusst gemacht haben, überlegten wir, ob wir in den jeweiligen Punkten Anpassungen vornehmen müssen, oder ob wir nicht wieder zur Methodik zurückkehren, die uns Scrum bietet.

Gerade das Problemfeld Product Owner und Projektleiter versuchen wir dadurch zu lösen, dass wir von Projektstart an operative Einheiten regelmäßig einbinden, um Etappenergebnisse zu präsentieren und uns Feedback einzuholen.

• Was will ich durch Agilität erreichen? (Unsere Antwort: Geschwindigkeit und eine bessere Qualität des der operativen Einheit übergebenen Projektergebnisses).

Um die Geschwindigkeit aufrechterhalten zu können, informieren wir beteiligte Abteilungen und schulen Mitarbeiter, die mit unseren Scrum-Teams arbeiten. Das hat dazu geführt, dass inzwischen auch andere Unternehmenseinheiten Scrum Master ausbilden und wir so zugleich noch einen Multiplikator-Effekt erreichen konnten. Offene Punkte haben wir derzeit bei dem Thema Projektleiter als "dienende Führungskraft". Des Weiteren ist die Dokumentation noch nicht zufriedenstellend gelöst.

Lessons Learned

Jochen Wenz arbeitet seit 2007 in den Themenfeldern Lean und Six Sigma. Durch seine Tätigkeiten bei Daimler, BASF, Roche und nunmehr als Projektleiter Lean Management bei der Hornbach Baumarkt AG konnte er in vielen verschiedenen Anwendungsbereichen sein Wissen vertiefen. Neben der Arbeit leitet er den Lean Stammtisch Mannheim und moderiert die größte Lean-bezogene Gruppe auf Xing „Lean for Professionals“ mit mehr als 4.800 Mitgliedern. mit einem großen Knall. Machen Sie sich die Vision klar, was Sie durch Scrum erreichen wollen. Hinterfragen Sie regelmäßig, ob der Rahmen der richtige ist oder ob Sie Änderungen vornehmen müssen. Haben Sie den Mut, Änderungen da vorzunehmen, wo sie notwendig sind. Allerdings muss diese Notwendigkeit kritisch betrachtet werden, da man sonst Gefahr läuft, zu schnell etwas ändern zu wollen.

Wenn Sie Scrum einführen wollen, führen sie es nicht Stück für Stück ein, sondern

Ausblick

Im nächsten Heft werde ich auf eine weitere agile Projektmethode eingehen. Vielfach wird inzwischen auch Kanban als Projektmanagement-Methode genutzt. Neben einer Beschreibung werde ich auch eine Abgrenzung, sowie die Vor- und Nachteile darlegen.

Kompetenzentwicklung im Vordergrund

Abschied von Alibi-, Ersatz- und Ausweichhandlungen

Was müssten Manager unternehmen, um wieder wertvolle Führungsfunktionen in Verbesserungsprozessen zu erfüllen? Es gibt eine ebenso einfache wie unbequeme Antwort: Wieder mehr in die Kompetenzentwicklung statt in Managementsysteme investieren.

Wenn Manager kritisiert werden, dann vorzugsweise wegen ihres kurzfristigen Gewinnstrebens. Dass die aktuell in vielen Unternehmen zu beobachtenden Führungsprobleme auch auf Know-how-Defizite zurückzuführen sind, scheint weniger plausibel. Schließlich war noch keine Managergeneration zuvor so gut ausgebildet wie die derzeitigen (Nachwuchs-)Führungskräfte. Was beim Blick in die Abteilungen von Profit- wie Non-Profit-Organisationen jedoch bereits auffällt, bestätigt nun eine vom Bundesministerium für Bildung und Forschung (BMBF) geförderte Studie zur Mitarbeiter aktivierenden Produktivitätsförderung: Das Wissen über die Möglichkeiten der Unterstützung von kontinuierlichen Verbesserungsprozessen ist bei vielen nach Tipps und Tools zur Produktivitätssteigerung suchenden Managern ebenso begehrt wie rar. Begriffe wie "Lean Production", "Continuous Improvement" oder "Working Smarter" haben sie zwar fast alle schon einmal gehört. Wie man seine Mitarbeiter dafür gewinnen kann, die alltäglichen Arbeitsabläufe immer wieder