Agilität ist in den Unternehmen angekommen. Sei es mit Scrum oder Kanban auf der Ebene einzelner Teams oder mit SAFe (Scaled Agile Framework) auf übergreifender Organisationsebene. Doch gerade bei der Skalierung von agilen Teams birgt deren Zusammenstellung eine latente Problematik. Es mag zu Beginn nicht sichtbar sein, doch stellen suboptimal zusammengesetzte Teams eine der grössten Herausforderungen in der Adaption und erfolgreichen Implementierung von skalierter Agilität dar.
Auf der tiefsten Ebene ist die Zusammenstellung eines Teams eher naheliegend und unkompliziert. Gemäss agilen Prinzipien muss ein Team cross-functional sein. Also alle Fähigkeiten und Kompetenzen haben, um sowohl Anforderungen in Produkte umzusetzen, als auch die Qualität, Integration und Bereitstellung des Produktes gewährleisten zu können. In den meisten Fällen werden die Teams um eine einzelne Applikation oder Service zusammengestellt. Entschliesst sich die Organisation, Agilität zu skalieren und die Teams in einem grösseren Kontext zu integrieren, wird die Teamzusammenstellung meist beibehalten. Dies ist zum Beispiel häufig bei der Bildung von Agile Release Trains (ART) im Kontext von SAFe zu beobachten. Als Konsequenz entsteht ein skaliertes Teamkonstrukt, welches eine organisatorische Abbildung der Service- oder Applikationslandschaft des Unternehmens darstellt.
Applikationsteams werden bei der Skalierung und Adaption von agilen Frameworks eins zu eins übernommen und integriert.
Organisation der <Agile Teams> in Applikationsteams (Quelle und Copyright: SwissQ)
Die Zusammenstellung der Teams anhand der betroffenen Applikationen ist naheliegend, wenn diese schon zuvor auf Teamebene agile Methoden verwendet haben. Teams mit einem Fokus auf eine einzelne Applikation können durchaus erfolgreich und effizient in agilen, skalierten Konstrukten funktionieren. Häufig ergibt sich jedoch die Problematik, dass sich die einzelnen Teams nicht für das übergreifende Produkt oder Service verantwortlich fühlen, sondern nur für ihre Applikation, bzw. ihren Teil. Diese Problematik ist gewiss nicht auf den agilen Kontext beschränkt, wird aber durch das schneller Erstellen von Lieferobjekten in agilen Methoden früh sichtbar. Typische Symptome dafür sind:
- Ineffiziente oder Probleme in der team-übergreifenden Kommunikation
- Unnötige oder vermeidbare Komplexität bei den Schnittstellen
- Unvorhergesehene Komplikationen bei der Integration der einzelnen Komponenten, bzw. Services
- Ein Team wird in der Erstellung der Lieferobjekte zum kritischen Flaschenhals
Funktioniert die skalierte Agilität mit Applikationsteams nicht, hat dies zur Folge, dass man als Endresultat nicht so schnell ein funktionierendes Gesamtprodukt hat, wie man es eigentlich wollte. Dies kann zu überbordenden Kosten oder signifikanten Zeitverzögerungen führen, was niemand brauchen kann.
Das Bilden von Featureteams hilft, einen End-zu-End Fokus zu etablieren, birgt aber ein Umdenken in der Systemorganisation.
Bei der Skalierung von Agilität ändern sich zwar nicht die zugrundeliegenden Prinzipien, hingegen der einzelne Bedeutungskontext. In grösseren Organisationskonstrukten impliziert cross-functional zusätzlich, von A bis Z alle Ablaufschritte des Services oder der Customer-Journey abdecken zu können. Die einzelnen agilen Teams sind optimalerweise anders zusammenzustellen als bei Agilität auf der reinen Teamebene. Soll der Fokus auf den end-zu-end Wertschöpfungsfluss gelegt und die bestmögliche Flexibilität skalierter Agilität ausgeschöpft werden, sind Feature-Teams unausweichlich. Werden diese korrekt zusammengestellt, können einzelne Produkt- oder Servicefeatures von verschiedenen Teams end-zu-end umgesetzt werden. Dadurch erhöht sich nicht nur die Flexibilität in der Umsetzungsplanung, sondern es können durch vielseitig einsetzbare Mitarbeitenden auch Kapazitätsengpässe vermieden werden. Jedes Team kann austauschbar und selbstständig einen Mehrwert für den Kunden liefern.
Organisation der <Agile Teams> in Featureteams (Quelle und Copyright: SwissQ)
Bei der Zusammenstellung von Feature- oder Produkt-Teams ist es wichtig, dass Knowhow und Kompetenzen von allen betroffenen Applikationen oder Service-Komponenten im Team vorhanden sind - idealerweise durch mehrere Personen. Ein Team muss jeden Prozessschritt zur Erbringung eines Mehrwerts für den Kunden abdecken. Dadurch wird der Problematik von komplexen Schnittstellenproblemen vorgebeugt. Als Gegenstück muss allerdings gewährleistet sein, dass dem Wissensaustausch zu den einzelnen Komponenten über die Teams hinaus genügend Zeit eingeräumt wird. Ansonsten besteht die Gefahr, dass die Teams einander in den einzelnen Komponenten behindern und technische Schulden oder unnötige Komplexität einbauen. Zu Beginn mag dieses grundlegende Umdenken und Umstrukturierung der Teams einen Verlust an Effizient bedeuten. Auf lange Sicht hingegen führt der gezwungenermassen stattfindenden Wissensaustausch durch die enge Zusammenarbeit innerhalb des Teams dazu, dass die einzelnen Personen ein breiteres Wissen in den anderen Komponenten aufbauen und flexibler arbeiten können (T-Shaped Professional). Feature- oder Produkt-Teams sind zwar nicht zwingend schneller als Applikationsteams, reduzieren aber das Risiko von Schnittstellen- und Integrationsproblemen und liefern dadurch eben meist doch früher den erwünschten Mehrwert.
Für skalierte agile Vorhaben gibt es nicht die goldene Regel zur Teamzusammenstellung. Dennoch lohnt es sich diesem Thema genügend Zeit und Aufmerksamkeit einzuräumen.
Es gibt schon viele Unternehmen, welche in der Implementation von skalierter Agilität die für sie richtige Organisation und Zusammenstellung von agilen Teams erfolgreich umgesetzt haben. Weil jeder Kontext unterschiedlich ist und seine ganz eigeneren Herausforderungen mit sich bringt, gibt es keine goldene Regel die immer und überall anwendbar ist. Trotzdem hat sich gezeigt, dass wenn sich ein Unternehmen konsequent auf das Kundenerlebnis und dessen Journey ausrichtet, eine Organisation der beteiligten Mitarbeitenden in Featureteams den grösseren Erfolg verspricht. Was denken Sie über dieses Thema? Kommt Ihnen das Problem bekannt vor oder hab Sie gute oder negative Erfahrung diesbezüglich gemacht? Uns interessiert Ihre Meinung und wir würden uns über Kommentare oder eine Kontaktaufnahme freuen.