Agilität ausweiten

Viele Teams agil aufsetzen

Wie für den agilen Piloten gelten für weitere Teams im Grunde dieselben Kriterien. Aber je mehr Teams agil Arbeiten sollen, umso schwieriger wird es, für jedes Team Lösungen zu finden, die dem „idealen“ Scrum möglichst nahekommen.

In der Praxis haben sich dabei besonders häufig zwei Herausforderungen gezeigt:

Teamgröße – Viele Mitarbeiter arbeiten an mehreren Projekten

Es liegt nahe, als Lösungsansatz für große Teams eine systematische Skalierung vorzunehmen. Aber auch dieser Ansatz bringt Herausforderungen mit sich, die oft nicht zu erfüllen sind. Zum Beispiel braucht man für jedes skalierte Team einen Product Owner (Ausnahme LeSS) und einen Scrum Master, beides qualifizierte Ressourcen, die gerade zu Beginn einer umfassenden Agilisierung rar sind. Daneben ist die Fulltime-Teilnahme an einem agilen Team in der Anfangsphase einer agilen Transformation eine echte Herausforderung, da viele Mitarbeiter an mehreren Projekten mitarbeiten.

Fehlende Freiwilligkeit – Innerer Widerstand gegen Agilität

Widerstand gegen agiles Arbeiten bei den Teammitgliedern kann durchaus ein relevantes Problem sein, wenn Mitarbeiter gegen ihre innere Überzeugung in einem Scrum-Team mitarbeiten sollen. Es gibt zwar zahlreiche „Lehrbuchansätze“, wie solche Teammitglieder „abgeholt werden können“, aber oft ist unklar, wer welche Rolle in so einer agilen Organisation hat, wo die erforderliche Qualifikation liegt und welche Optionen vorhanden sind, wenn die Ansätze aus den Lehrbüchern erschöpft sind.

Alle Teams unter eine agile Führungs- und Koordinationsstruktur setzen

Eine systematische Skalierung ist immer erforderlich. Selbst wenn alle Teams an eigenen Produkten arbeiten, müssen gemeinsame Ressourcen koordiniert und ggfs. priorisiert werden. Oft kann auch bei mechatronischen Produkten nicht die volle Entscheidungskompetenz ins Team verlagert werden und darum müssen übergeordnete Instanzen einbezogen werden. Ergänzend zu den einzelnen agilen Teams werden in den verschiedenen Skalierungsframeworks weitere Rollen, Artefacte sowie Ereignisse beschrieben, die diese übergeordnete Koordination und Führung sicherstellen sollen.

Diese Skalierungsframeworks unterscheiden sich erheblich darin, wie die Ebenen oberhalb des agilen Teams organisiert und gesteuert werden. Manche Frameworks sind dabei sehr umfassend und detailliert in ihrer Beschreibung, d.h. sie sind sehr präskriptiv, andere fokussieren sich stärker auf eine prinzipientreue Lösungsfindung, d.h. sie sind eher deskriptiv. Die am weitesten verbreiteten Frameworks sind:

• SAFe®
• Less®
• Scrum@Scale®
• Nexus®

Um den speziellen Bedürfnissen in der Entwicklung mechatronischer Produkte gerecht zu werden, kommen oft individuell angepasste Frameworks zum Einsatz. Daneben werden insbesondere in Unternehmen, wo die Produktentwicklungsvorhaben dezidierte Teams für hybride Produkte (reine Hardware-Produkte sind sehr selten geworden) und reine Software-Produkte (oft geht es dabei im Cloud-basierte oder App-Lösungen, die übergreifend für mehrere mechatronische Produkte bereitgestellt werden sollen) aufstellen, auch kombinierte Frameworks eingesetzt. Prozesse zur Software-Entwicklung brauchen meist andere Koordinations- bzw. Führungsstrukturen als für die Mechatronikentwicklung.

Eine besondere Herausforderung bei der Einführung des, auf den individuellen Bedarf eines Unternehmens, ausgewählte und angepasste Skalierungsframework ist dann auch die Transformation der Rollen auf Führungsebene. Gruppen-, Abteilungs- und Bereichsleiter gehen über in Product Owner und Scrum Master bzw. Agile Coaches auf verschiedenen Ebenen oder aber auch zu Stakeholdern mit Technologiefokus. Es ist von entscheidender Bedeutung, dass diese Rollen klar beschrieben sind und die betroffenen Führungskräfte bei der Veränderung begleitet werden. Insbesondere dann, wenn es darum geht Agilität organisatorisch zu verankern.