top of page
synetz-cc

Design Thinking oder SCRUM: Es braucht einen passenden strukturellen Rahmen!


"This way"
Bildquelle: Jamie Templeton, 428883, Unsplash

#Transformation - Teil 4

Bei der Einführung agiler Arbeitsweisen, wie z.B. Design Thinking oder SCRUM, ist es notwendig auch die Strukturen zu überprüfen, in denen die agilen Teams arbeiten sollen. Damit agile Maßnahmen ihre Wirkung entfalten können, braucht es einen Rahmen, in dem das auch gelingen kann.

Rollenkonflikte und Gerangel um MitarbeiterInnen vermeiden

Wir in Artikel 3 der Reihe #Transformation bereits dargestellt, ist es gerade bei agilen Methoden ein zentrales Prinzip, die Teams in bestimmten Phasen ihrer Arbeit nicht auseinanderzureißen und sie selbstorganisiert arbeiten zu lassen. In diesen Phasen ist es notwendig, dass die disziplinarischen Vorgesetzten der einzelnen Teammitglieder diese arbeiten lassen, ohne deren Fluss zu unterbrechen. Die Team-Master und Product Owner sind verantwortlich für den Arbeitsrhythmus und die erfolgreiche Arbeit in den Teams und müssen in dieser Rolle von allen Beteiligten akzeptiert und unterstützt werden. Gerangel um MitarbeiterInnen („Ich soll nur kurz in eine Telko mit einem wichtigen Kunden!“, „Mein Teamleiter sagt, ich muss an dem Meeting teilnehmen, weil nur ich im Thema bin!“) und Einmischungen stören die Teams und nehmen ihnen viel von ihrer Dynamik. Hier kommt es gerade bei Piloten immer wieder zu Problemen. Zum einen ist es dann die Aufgabe der Team-Master, als Change-Agent zu agieren und diese Themen immer wieder zu adressieren und Vorschläge zur Verbesserung zu machen. Darüber hinaus ist es aber auch die Aufgabe der Führungskräfte, besonders der Auftraggeber, einen Rahmen zu schaffen, in dem die agilen Teams arbeiten können. Vertretungsregeln oder Qualifizierungsmaßnahmen und Wissensmanagement zur Verbreiterung der Wissensbasis sind nur zwei Beispiele für Maßnahmen, die helfen, Engpässe und Kompetenzgerangel zu vermeiden.


Entscheidungsprozesse

Eine Stärke agiler Methoden ist die Geschwindigkeit, in der Prototypen und Produkt-Versionen entstehen können. Das Zauberwort heißt „Sprint“. Hierin steckt implizit das Wort Geschwindigkeit. Ein Sprint ist ein fest definierter Zeitraum von Tagen oder Wochen, in dem Teams mit Hochdruck an der Weiterentwicklung bestimmter Produkte arbeiten und sie immer wieder mit den Erwartungen und Bedürfnissen ihrer Kunden abgleichen. Nicht selten werden hier kurzfristig Entscheidungen notwendig, z.B. die Einbindung weiterer MitarbeiterInnen im Team, die Freigabe von Testformaten mit dem Kunden, die Entscheidung über den Punkt, an dem sich eine Weiterentwicklung nicht mehr lohnt etc. Damit die Geschwindigkeit an dieser Stelle nicht verloren geht, ist es notwendig, die vorhandenen Entscheidungsstrukturen zu überprüfen. „Dafür haben wir erst in 4 Wochen wieder einen Slot auf der Agenda der Geschäftsführung“ ist sicherlich keine Aussage, die zu agilem Arbeiten passt. Hier macht es eher Sinn, im Rahmen einer Pilotierung die Team-Master oder Product Owner als festen Punkt auf die Agenda zu setzen und ggf. sogar Ad hoc-Meetings mit der Geschäftsführung oder dem Auftraggeber zu ermöglichen, um die Geschwindigkeit des Teams zu unterstützen.


Vorhandene Prozesse

Ein weiterer Punkt, an dem Geschwindigkeit verloren gehen kann, sind die Demand- und Change-Prozesse in IT-Abteilungen. Auch hier ist es sinnvoll, dass sich Prozess Owner, Release Management und Product Owner in regelmäßigen Abständen abstimmen, um Hindernisse früh genug zu erkennen und die Release-Planung und den Arbeitsrhythmus der agilen Teams zu harmonisieren. Denn die Prozesse sind meist an die Arbeitsweisen und der Geschwindigkeit der „alten Welt“ angepasst. Change-Boards tagen nur alle 4 oder 6 Wochen, die Pausen zwischen Releases sind relativ lang. Hier gilt es zu intervenieren, z.B. indem wöchentliche Wartungsreleases auch für die Ergebnisse der agilen Teams genutzt werden können oder aber, was sicher sinnvoll ist, in dem der Gesamtprozess überarbeitet wird. Sonst produzieren die agilen Teams in kürzester Zeit funktionsfähige Produkte und Produkterweiterungen, die aber nicht schneller beim Kunden sind, als die Ergebnisse der nicht agilen Teams.


Fazit

Bevor agile Methoden ihre Wirkung voll entfalten können, gilt es, einen Rahmen zu schaffen, in dem dies auch möglich ist. Rollen und Prozesse bilden hier sicherlich einen sinnvollen und wichtigen ersten Ansatzpunkt.

0 Kommentare

Aktuelle Beiträge

Alle ansehen

Comments


bottom of page