Das Team des Bereichs Architektur und Projekte im Systembetrieb zeigt, wie Scrumban im Alltag funktionieren kann. Doch wie ändert man jahrelang praktizierte Verhaltensweisen? Roland Spitzer hat eine Antwort darauf gefunden.
Ein Funktionsbereichsleiter, der wie ein Product Owner agiert und innerhalb der Strukturen der REWE Systems sein Team agil führt – geht das? Ja, das geht, sagt Roland Spitzer von der REWE Systems, und es sorgt sogar für mehr Zufriedenheit und Effizienz im Team.
Der Bereich TIBA entscheidet im Team über Nachfolgekandidaten, macht gemeinsam die Budgetplanung und verbringt jeden Freitag vier Stunden gemeinsam, um zusammen zu arbeiten. Und alle vier Wochen ist dann auch Sprintwechsel: mit Review, Retrospektive und Planung des nächsten vierwöchigen Entwicklungszyklus, kurz Sprint genannt. Die Mitarbeiter der Abteilung Architektur und Projekte im Systembetrieb der REWE Systems sind ein Paradebeispiel dafür, dass agiles Arbeiten nicht nur in Projekten, sondern auch im ganz normalen Arbeitsalltag funktioniert.
„Ich mache alles gemeinsam mit meinem Team, von der Kostenplanung bis zum Recruiting, denn mir ist wichtig, dass die Mitarbeiter wissen, wie ihre Projekte entstanden sind und ein Mitspracherecht haben, wenn es um Personalentscheidungen geht. Ich möchte die Aufgaben des Product Owners – denn das ist meine Rolle im Team – transparent für alle gestalten.“ Der das sagt, hat den offiziellen Titel Funktionsbereichsleiter, lebt jedoch in der täglichen Arbeit eine im Team entwickelte Scrumban-Variante. Die Methode ist eine sinnvolle Kombination von Elementen aus Kanban und Scrum, um in einem agilen Team Projekt- und Serviceaufgaben zu erledigen.
„Wichtig ist, dass man sich über die eigene Arbeit im Klaren wird“Roland Spitzer
Dass mit etwas kreativem Potenzial und einem offenen Mindset diese Regeln problemlos für ein kleines Team im Arbeitsalltag funktionieren, beweisen Roland Spitzer und seine achtköpfige Mannschaft seit zwei Jahren. Ausgangspunkt war die Überlegung des agilen Transitionsteams der REWE Systems, den Teilnehmerkreis über IT-Entwickler hinaus auf den Bereich IT-Betrieb zu erweitern. Das bedeutete aber auch, dass Agilität nicht mehr ausschließlich in Software-Entwicklungsprojekten angewendet werden sollte, sondern auch in Projekten, die sich mit der Infrastruktur beispielsweise in den Märkten beschäftigen.
Bei Roland Spitzer stieß die Product Ownerin des Transitionsteams, Isabel Müller, auf offene Ohren. Agiles Arbeiten „in der Linie“ zu etablieren, eine Scrumban-Methodik zu erarbeiten, die über Projektarbeit hinaus auch auf die Linienarbeit übertragbar ist, schien ihm ein lohnendes Projekt.
Doch wie ändert man jahrelang praktizierte Verhaltensweisen? Das geht nicht ohne zunächst die eigene Arbeit genau zu analysieren. Welche Aufgaben gibt es? In welche Teilschritte können sie zerlegt werden? Das Team Architektur und Projekte im Systembetrieb ging noch einen Schritt weiter: „Mein Team wollte zunächst eine Skill-Matrix erstellen, um ein Bild davon zu erhalten, wo wessen Stärken liegen und bei wem es eventuell noch Weiterentwicklungsbedarf gibt – mich als Funktionsbereichsleiter inklusive.“ Erst danach ging es an die Aufgaben. Dies alles erarbeitete das neunköpfige Team im Rahmen eines Workshops mit einem agilen Coach. „Wichtig ist, dass man sich über die eigene Arbeit im Klaren wird und die Arbeit visualisiert“, erklärt Spitzer.
„Das Team ist enger zusammengewachsen und sehr viel selbstbewusster geworden.“Roland Spitzer
Im Workshop legte das Team auch gemeinsam die Rollen, wie Scrum sie vorsieht, fest: Den Part des Product Owners und damit die Verantwortung für den wirtschaftlichen Erfolg übernahm Roland Spitzer. Als Scrum Master sorgt seine Assistentin Daniela Baum dafür, dass sich alle an die neuen Regeln halten. „Ihr kommt damit eine sehr wichtige Rolle zu, denn sie achtet darauf, dass wir alle uns an die vereinbarte Transparenz halten. Dazu gehört auch, dass ich als Product Owner Vertrauen in mein Team setze und es nicht ständig kontrolliere.“
Die Skill-Matrix und eine klare Strukturierung der Arbeitsprozesse befähigen das Team, sich weitgehend selbstständig zu organisieren. Roland Spitzer schreibt die Anforderung – im Scrum Vokabular „User Story“ genannt. Der Product Owner legt damit die Arbeitsgrundlage und gibt dem Team die Informationen, die es braucht, um den Auftrag zu bearbeiten. Wie das Team diese Anforderung umsetzt, entscheidet es unter sich. Ab jetzt arbeiten die Mitarbeiter in höchstem Maße selbstständig, bis hin zur Berichterstattung an Vorgesetzte und die Teilnahme in Lenkungsausschüssen.
Das Ergebnis begeistert Roland Spitzer immer noch: „Das Team ist enger zusammengewachsen und sehr viel selbstbewusster geworden. Kollegen, die sehr zurückhaltend waren, haben Selbstvertrauen gewonnen. Das Vertrauen, das ich in das Team setze, hilft dabei.“
Das Team verwendet Scrum-Methoden zur Abarbeitung der Aufgaben und Kanban-Methodiken zur Visualisierung der Arbeit. Ein sichtbares Ergebnis der agilen Arbeit ist die Visualisierung des von TIBA geführten und betreuten Projekt-Portfolios durch ein Kanban-Board. Es nimmt den Kanban-Gedanken auf, einen Vorgang – in diesem Fall ein Projekt – in einzelne Schritte – in diesem Fall Projektphasen – zu gliedern und eine eindeutige Abfolge festzulegen, die durchlaufen werden muss. Als Umsetzung wurde ein Holzboard entwickelt, das am oberen Ende in der Horizontalen die einzelnen Projektphasen abbildet.
Darunter sind Drähte gespannt, an die Klemmbretter gehängt werden. Dort finden sich unter anderem übergeordnete Projektinformationen und eine Dokumentation der erreichten und noch offenen Ergebnisse. Die Farbe des Klemmbretts zeigt den Projektstatus an, die Verortung des Bretts auf dem Board entspricht der Projektphase. Eine Wäscheklammer signalisiert dem Team eine aktuelle Änderung in der Bearbeitung.
Jeden Freitag trifft sich das Team am Board, stellt den aktuellen Status aller Projekte kurz vor und bringt das Board auf den neuesten Stand. So werden die Fortschritte für alle nachvollziehbar visualisiert. Gibt es neue Anforderungen, entscheidet das Team, wie es diese aufteilt.
Das Team lädt freitags auch interne Auftraggeber aus anderen Bereichen zu Reviews ein. Da bekommt das Team hilfreiches Feedback zu den Arbeitsergebnissen des vergangenen Sprints. Danach wird Manöverkritik in der teaminternen Retrospektive geübt: Was hat gut funktioniert? Was hätte besser laufen können? Wo besteht Verbesserungspotenzial? Entscheidend ist auch hier: Im Zentrum steht die Lösung, nicht das Problem.
Hallo Frau Morgenschweis,
könnten Sie die Farbe des Klemmbretts und die Bedeutung der Wäscheklammer genauer erläutern, z.B. mit einem Beispiel?
Herzlichen Dank,
Markus Busch
gerne beantworte ich ihre Frage :
In der REWE Systems nutzen wir die Ampelfarben zur Darstellung der Kritikalität eines Projektes. Diesen Status bilden wir auch mit den Farben der Klemmbretter ab, was zu einer umgehenden Fokussierung führt.
Uns fehlte noch eine Farbe für Themen, die im Bearbeitungs-Eingang stehen wie z.B. geplante Projekte, die aber noch nicht gestartet wurden. Die Blauen hatten wir im Bestand und wurden kurzerhand genommen.
Da das Board öffentlich ist, deuten wir mit Wäscheklammern auf Änderungen zur Vorwoche hin (nächste Projektphase, Punkt auf der ToDo-Liste abgearbeitet, Status-Änderung, usw.). So schaffen wir mehr Transparenz für Außenstehende.
Rot : Projekt kritisch
Gelb : im Auge behalten
Grün : in Zeit und Budget
Blau : noch nicht in Umsetzung