2.1 Einführung

Prominente Ansätze agiler Projektarbeit – aktuell insbesondere in der Softwareentwicklung relevant, aber zunehmend auch in anderen Branchen – betonen die Relevanz der gesteigerten Selbstorganisation agiler Teams, die maßgebliche Effizienz- und Effektivitätsvorteile gegenüber klassischen Projektmanagementansätzen forciere. Selbstorganisierte Teamarbeit ist also ein zentrales Moment agilen Arbeitens. Allerdings machen die häufig anzutreffende räumliche Verteilung von Teams, der ebenfalls zentrale Anspruch der Kundenintegration in den agilen Entwicklungsprozess und die sich überlappenden Organisationsprinzipien von agilen Teams und nicht agilen Organisationsumwelten eine eindeutige Teamabgrenzung in der Praxis oft schwer. Es zeigt sich eine Fluidität agiler Teams, in der weder die innere Struktur, noch die Zugehörigkeit und die Grenzen nach außen immer klar benannt werden können, weder von Externen noch von den Teammitgliedern selbst. Dies steht in direktem Zusammenhang mit der Selbstorganisation im Team, die durch Uneindeutigkeiten in Struktur, Zugehörigkeit und Abgrenzung unter Druck gerät. In diesem Zusammenhang nimmt die Digitalisierung eine maßgebliche Rolle ein. Sie gilt unter anderem als Treiber bzw. Garant für die Entwicklung agiler Ansätze in der Projektarbeit (Overby et al. 2006; Häusling 2018), Overby et al. (2006) betonen etwa die direkten und indirekten Möglichkeiten, die IT-Technologie bietet, agile Anpassungen an sich schnell verändernde Umweltbedingungen vorzunehmen. In unseren Untersuchungen zeigt sich jedoch, dass insbesondere die räumliche Verteilung von Teams auch durch digitale Tools nur begrenzt überbrückt werden kann.

Im Kontext dieser Entwicklungen stellen agile Teams weder eine klare Einheit dar, noch befinden sie sich in Auflösung. Im agilen Projektmanagement wird dem teambasierten Arbeiten im Vergleich zu klassischen Projektmanagementansätzen ein gesteigerter Wert für die Zielerreichung zugesprochen, indem das Team erweiterte Befugnisse zur Selbstorganisation erhält. Der genauere Blick zeigt, dass diese Befugnisse sich nicht nur auf die Arbeitsprozessebene und formale Fragen der Arbeitsorganisation beziehen, sondern auch die gleichsam konstituierenden Aspekte der Bestimmung von Teamgrenzen und der inneren Struktureinschließen. Die Etablierung und Aufrechterhaltung des Teams wird zur Daueraufgabe der Teammitglieder selbst. Grenzen und interne Struktur des agilen Teams werden im Zuge dessen prinzipiell kontingent und empirisch fluide. Dies bleibt in bisherigen Betrachtungen agiler Arbeitsorganisation sowie der Forschung zu Teamarbeit weitgehend unbeobachtet.

Agile Methoden und Arbeitsinstrumente (siehe Abschn. 1.2) liefern hier nicht per se „Lösungen“, sondern schaffen im besten Fall einen Rahmen zur Klärung. Die Frage ob und wie dieser Rahmen genutzt werden kann, ist maßgeblich abhängig davon, ob die erweiterten Aufgaben in Selbstorganisation auch mit entsprechenden Rahmenbedingungen, Ressourcen und Anerkennung einhergehen. Unseren Untersuchungen nach entstehen aus einem entsprechenden Mangel spezifische Belastungen für agile Teams (siehe Abschn. 1.4).

Ziel des Beitrags ist daher die genauere Bestimmung der Konstitution von fluiden Teams in agilen Arbeitskontexten ihrer Bedeutung für selbstorganisierte Arbeitsprozesse sowie die Betrachtung von Voraussetzungen zur Bewältigung resultierender Aufgaben in Selbstorganisation. Hierfür werden erhobene Daten aus zwei Fallunternehmen der Softwareentwicklung genutzt. Es zeigt sich, dass Selbstorganisation und Fluidität sich gegenseitig beeinflussen. Der Beitrag betrachtet dies mit einem kritischen Blick auf die Zusammenhänge von Teambeschaffenheit und Selbstorganisation im Kontext der Nutzung (digitale Kollaborationstools als Arbeitsmittel) und Entwicklung (Software als Arbeitsgegenstand) digitaler Technologien.

2.2 Zentrale Elemente der Selbstorganisation in agilen Teams

Unter agilem Kontext verstehen wir die Konstellation, bei der Teams sich in ihrer Arbeit auf das im Zusammenhang von Softwareentwicklung entstandene agile Manifest beziehen. Darin werden vier Grundprinzipien formuliert, die erklären, dass in der Softwareentwicklung Individuen und deren Interaktion wichtiger als vordefinierte Prozesse, funktionsfähige Software wichtiger als Dokumentation, Anpassung wichtiger als reine Vertragserfüllung, enge Kooperation mit dem Kunden wichtiger als detaillierte Verträge sein sollten. Selbstorganisierte Teams, ausgeprägte Kundenintegration, ein iteratives Vorgehen sowie kurzzyklische Entwicklung von Teilergebnissen können als die Basiselemente agilen Arbeitens betrachtet werden.

Der den Prinzipien und Basiselementen entsprechende und weltweit bei agiler Projektarbeit am häufigsten verwendete Projektmanagementansatz ist Scrum, auf diesen bezieht sich auch der vorliegende Beitrag. Die Selbstorganisation fußt hier auf spezifischen agilen Methoden, Instrumenten und Rollen. Vorgesehen sind die drei Rollen Product Owner (Arbeitsschwerpunkt Klärung und Integration der Kundenanforderungen), Scrum Master (Arbeitsschwerpunkt Moderation und Monitoring des Scrum Prozesses) und Developer (Arbeitsschwerpunkt Softwareentwicklung). Alle Rollenträger stehen in direkter Interaktion und begegnen sich dabei auf Augenhöhe, es gibt keine Projektleitungsfunktion. Zentrale Methoden sind etwa die Organisation von Entwicklungsaufgaben in kurzzyklischen „Sprints“ von zwei bis vier Wochen, an deren Ende jeweils ein Teilergebnis steht oder auch die Kommunikation in spezifischen Meetingformaten, im Kern: „Daily“ zum täglichen kurzen Austausch über Stand der Dinge und Unterstützungsbedarfe, „Review“ zur Diskussion von Teilergebnissen und „Retrospektive“ zur Diskussion von Problemen/Erfolgen im Verlauf des letzten Sprints. Zentrale Instrumente sind etwa das „Backlog“, in dem anstehende Entwicklungsaufgaben gesammelt und strukturiert werden oder auch das „burndown chart“ zur Betrachtung des aktuellen Fortschritts im laufenden Sprint. Diese und weitere agile Methoden und Instrumente sollen der teaminternen Koordinierung, Kooperation und Kommunikation aller Teammitglieder auf Augenhöhe dienen, also die teambasierte Selbstorganisation ermöglichen. Im Rahmen der folgenden Ausführungen wird deutlich werden, dass es sich hierbei um hilfreiche, aber allein nicht hinreichende Voraussetzungen für agile Selbstorganisation handelt. Zum einen müssen die formalen agilen Methoden, Instrumente und Rollen im Arbeitsalltag jeweils konkret gestaltet und interpretiert werden. Zum anderen, darauf liegt der Schwerpunkt dieses Beitrags, sind sie in jeweils betriebsspezifischen Zusammenhängen platziert, die maßgeblich auf sie zurückwirken.

2.3 Die Bestimmung des Teams im Kontext von Fluidität und Digitalisierung: Stand der Forschung

Teamarbeit zeichnet sich aus durch einen Arbeitsauftrag an mindestens drei Arbeitspersonen, welcher von diesen als gemeinsame Arbeitsaufgabe verstanden und in Kooperation bearbeitet wird (Schlick et al. 2018). Teamarbeit kann demnach als aufgabenbezogener Kooperationszusammenhang verstanden warden (Schlick et al. 2018, S. 682), welcher real oder virtuell, projektförmig, auf Dauer angelegt oder temporär sein kann (Antoni 2000) und in seinem Autonomiegrad prinzipiell variieren kann (Grote 1997). Agile Teamarbeit geht mit einem eher hohen Autonomiegrad und mit einem eher „people-centered“ bzw. menschenzentrierten Ansatz (Cockburn and Highsmith 2001) einher. Zu identifizieren, was ein erfolgreiches Team ausmacht,ist Zweck des in Harvard und am Dartmouth College entwickelten Team Diagnostic Survey (TDS) (Wageman et al. 2005). Dieser definiert fünf Bedingungen, die erfüllt sein müssen, um von einem erfolgreichen Team sprechen zu können. Neben einem unterstützenden organisationalen Kontext, einer gemeinsamen Zielrichtung und entsprechendem Coaching sind dies auch eine die Arbeit des Teams ermöglichende (innere) Struktur sowie die Existenz eines „realen Teams“. Die beiden letzten Aspekte sind entsprechend der Autor*innen jeweils durch drei Merkmale gekennzeichnet. Das reale Team definiert sich durch klare Grenzziehung, Interdependenz in der Zweckerfüllung und Stabilität der Zusammensetzung. Operationalisiert wird das Merkmal der klaren Grenzziehung über die Frage, ob alle Mitgliedereindeutig benennen können, wer Mitglied des Teams ist und diese auch von Externen klar benannt werden können. Die Interdependenz wird operationalisiert mit Fragen zu der Notwendigkeit von Kommunikation und Koordination sowie der wechselseitigen Abhängigkeit bei der Generierung eines Outputs. Im Hinblick auf die Stabilität steht die Frage nach dem Wechsel der Mitgliedschaft im Mittelpunkt. Die ermöglichende innere Struktur des Teams bestimmt sich hingegen über die Aspekte Aufgabendesign, Teamzusammensetzung und Teamnormen. Teamzusammensetzung meint hierbei die Größe, ein entsprechendes Maß an Diversität sowie ausreichend Talent, Erfahrung und spezielle Fähigkeiten im Team. Das Aufgabendesign wird über die Fragen nach einer klar identifizierbaren, sinnvollen Tätigkeit, der autonomen Erfüllung dieser Aufgabe sowie Wissen über das zu erwartende Ergebnis operationalisiert. Die Teamnormen definieren sich über das Ausmaß, in dem die Verhaltenserwartungen im Team bekannt und akzeptables Verhalten klar kommuniziert sind.

Gerade die im TDS operationalisierten Aspekte des „realen Teams“ und der ermöglichenden inneren Struktur des Teams werden unseren Untersuchungen nach durch zunehmende Fluidität immer problematischer. In der Literatur zeigt sich indes keine einheitliche Definition fluider Teams. Was gemeint ist, variiert und wird jeweils mehr oder weniger weit gefasst. Zum Teil wird die Beschreibung von fluiden Teams recht eng formuliert, indem lediglich die Instabilität der Mitgliedschaft adressiert wird: „We call groups with unstable membership that organizations create and hold responsible for one or more outcomes fluid teams.“ (Bushe and Chu 2011, S. 181). Teils werden neben der Mitgliedschaft weitere Aspekte fluider Teams betont: „We define team fluidity as a team state characterized by team membership change, shorter team member tenure, unclear team boundary, and emergent team structure.“ (Chiu et al. 2017, S. 1). Mit Blick auf unsere empirischen Untersuchungen schließen wir uns dieser breiteren Beschreibung von Fluidität an und begreifen agile Teams als fluide Teams.

Obwohl der Aspekt auch im Kontext des TDS als besonders erfolgskritisch angesehen wird, ist die sich ständig verändernde Zusammensetzung bzw. die Fluidität von Teams nur selten Gegenstand der Forschung zu Teamarbeit (Summers et al. 2012; Bedwell et al. 2012). Dennoch wird Fluidität thematisiert, etwa bei Tannenbaum et al. (2012): „They [die Teams] change and adapt more frequently, operate with looser boundaries, and are more likely to be geographically dispersed. They experience more competing demands, are likely to be more heterogeneous in composition, and rely more on technology than did teams in prior generations.“ (Tannenbaum et al. 2012, S. 3).

Während Tannenbaum et al. (2012) digitale Technologie als veränderte Voraussetzung für Teamarbeit benennen, wird an anderer Stelle die direkte Einwirkung digitaler Technologie auf die Fluidität des Teams selbst betont (Chatterjee et al. 2017). Die Digitalisierung ermögliche vor allem Kommunikation und Koordination der Tätigkeiten, nehme allerdings auch Einfluss auf die Zusammensetzung und Struktur des Teams. Nicht zuletzt ermöglicht sie auch die Mitgliedschaft in unterschiedlichen Teams, in denen zeitgleich gearbeitet werden kann (Chatterjee et al. 2017). Dabei wird die Möglichkeit des persönlichen Austauschs hervorgehoben: „self-presentation [durch digitale Technologie] allows individuals to share their attributes with others (such as locations, knowledge, and connections to other individuals). Conversely, distant mobile copresence allows workers to engage in situations beyond theirimmediate physical environment. Thus, for example, with this practice, individuals at home canstill be contacted for, and can engage in, office-related work.“ (Chatterjee et al. 2017, S. 20). Das führe letztlich dazu, dass in durch digitale Technik geprägten Umgebungen die Fluidität zunehme, was von Chatterjee et al. (2017) nicht unbedingt negativ bewertet wird.

In der Literatur zu fluiden Teams lassen sich jedoch unterschiedliche Positionen ausmachen: Während einige Autor*innen in den wechselnden Team-Konstellationen positive Aspekte für die Performance des Teams erkennen (Tannenbaum et al. 2012; Bedwell et al. 2012), werden an anderer Stelle die erschwerten Bedingungen fluider Teams herausgearbeitet (Bushe and Chu 2011). Zentrale Gründe für Dysfunktionalitäten fluider Teams werden insbesondere in einem reduzierten Zugehörigkeitsgefühl (aufgrund geringem individuellem Commitment und wenig Zusammenhalt der Teammitglieder) sowie in der reduzierten Wirksamkeit der Teams (aufgrund des Verlorengehens individuellen Wissens und eines Mangels an gemeinsamen mentalen Modellen) gesehen (dazu auch Bedwell et al. 2012). Daher sei die Fluidität in Teams insgesamt zu reduzieren. Hierfür müsse insbesondere dem Prozess der Auswahl von Teammitgliedern mehr Aufmerksamkeit zuteilwerden (Bedwell et al. 2012). Darüber hinausgibt es Studien, die sich in der Bewertung eher zurückhalten und stattdessen Fluidität als eine neue Konstante betrieblicher Realität erachten, für die adäquate Umgangsweisen gefunden werden müssten (Bedwell et al. 2012).

Letztlich ist damit im Kontext agilen Arbeitens (insbesondere im nicht-agilen Unternehmensumfeld) und unter Bedingungen der Fluidität die Frage aufgeworfen, wer eigentlich das Team ist und wodurch es sich als solches auszeichnet? Unsere Untersuchungen zeigen, dass diese Fragen vor allem im Zusammenhang mit den Aspekten einer emergenten Teamstruktur und unklarer Teamgrenzen im Zusammenhang stehen. Die Entwicklung einer Teamstruktur wird sowohl zur (impliziten oder expliziten) Teamaufgabe gemacht – nämlich als Anforderung an Selbstorganisation – als auch infrage gestellt, insbesondere dadurch, dass Grenzen agiler Teams uneindeutig werden und räumliche Verteilung agiler Teams – entgegen der agilen Anforderung der direkten Interaktion und physischen Kopräsenz – mehr und mehr zur Regel wird.Footnote 1 Unser Vorschlag wäre daher, das Phänomen der fluiden Teams in agilen Arbeitskontexten anknüpfend an Wageman et al. als „team-like behavior over time and across projects“ zu begreifen (Wageman et al. 2012, S. 301). In diesem Sinne sind agile Teams durch eine spezifische Beschaffenheit gekennzeichnet, die sich von derjenigen klassischer Projektteams unterscheidet (siehe Kap. 3).

In der heutigen Arbeitswelt kommen zunehmend Arbeits- und Organisationsmethoden zum Einsatz, die auf Selbstorganisation abzielen. Die Frage, in welchem Zusammenhang zunehmende Selbstorganisation und Fluidität stehen, ist in der Literatur jedoch noch ungeklärt. Vor allem Fragen von Grenzziehungen und (emergenten) Teamstrukturen erhalten unter Bedingungen von Selbstorganisation eine besondere Relevanz. Die bisherige Literatur thematisiert überwiegend die Mitgliederzusammensetzung. Doch gerade angesichts der zunehmenden Anwendung agiler Methoden und seiner konstitutiven Elemente, scheint dieses Begriffsverständnis verkürzt. Teamgrenzen und -strukturen müssen als zentrale Dimensionen fluider Teams betrachtet und in Beziehung zu Selbstorganisation gesetzt werden. Bedeutsam ist dies vor allem deshalb, weil die beschriebenen Veränderungen praktische Anforderungen darstellen, mit denen die Beschäftigten in Teamarbeit in ihrem Arbeitsalltag umgehen müssen. Allzu oft sind sie dabei mit der impliziten oder expliziten Annahme konfrontiert, dass diese Anforderungen gerade durch die erweiterten Handlungsspielräume in Selbstorganisation problemlos und ohne nennenswerten Mehraufwand bewältigt werden könnten. Die selbstorganisierte Bearbeitung von Fluidität ist jedoch eine zusätzliche Aufgabe, die entsprechende Ressourcen (Zeit, Kompetenzen, Geld) benötigt und daher als solche anerkannt werden muss. Selbstorganisation ist weder in klassischen Projektmanagementansätzen noch bei agilem Projektmanagement ein Selbstläufer. Sie bleibt auch hier voraussetzungsreich – umso mehr, je mehr Aufgaben und Befugnisse in Selbstorganisation bewältigt werden müssen. Unsere Untersuchungen zeigen, dass die agilen Methoden und Instrumente allein hierfür nicht ausreichen. Sie schaffen einen hilfreichen formalen Rahmen, der jedoch täglich mit praktischem Arbeitshandeln „gefüllt“ werden muss. Welche gesamtbetrieblichen Bedingungen hierfür vorhanden sind, ist entscheidend dafür, wie effektiv die Methoden und Instrumente genutzt werden können.

2.4 Agile Selbstorganisation in fluiden Strukturen: empirische Ergebnisse

Wie sich die Situation von selbstorganisierten Teams in fluiden Strukturen darstellt, wird in zwei Fallunternehmen der Softwareentwicklung qualitativ untersucht. Anhand der Auswertung von 30 problemzentrierten Interviews mit Beschäftigten und Führungskräften, drei partizipationsorientierten Workshops mit Mitgliedern agiler Teams sowie Beobachtungen und Videoanalysen von sechs agilen Meetings, wird die Frage der Teambeschaffenheit in agilen Kontexten und das Verhältnis zwischen Selbstorganisation und Fluidität beleuchtet.

Erhoben wurden die Daten zwischen 2017 und 2019 im Kontext des durch das BMBF geförderten Forschungsprojekts ‚diGAP – Gute agile Projektarbeit in einer digitalen Welt‘. Bei den beiden Softwareunternehmen handelt es sich einerseits um ein KMU mit 450 Beschäftigten, welches seine Projektarbeit bereits längerem nach agilen Maßstäben gestaltet, und andererseits um ein weltweit agierendes Unternehmen mit über 40.000 Beschäftigten, das sich derzeit in einem Wandlungsprozess befindet und im Zuge dessen punktuell bereits eingesetzte agile Methoden auf die Projekte im ganzen Unternehmen skalieren wollen. Beide Unternehmen haben hauptsächlich Geschäftskunden und Scrum ist das Mittel der Wahl, um ihre Projektarbeit zu gestalten. Ein zentraler Unterschied ist die nach wie vor eher bürokratisch-hierarchische Struktur im Falle des Großunternehmens, während im KMU die Zusammenarbeit viel stärker auf den Abbau von Hierarchie ausgelegt ist.

Im Ansatz folgt das Projekt der Idee partizipativer Forschung (Sauer 2017). Das bedeutet, dass nicht nur die Ist-Situation konkreter Arbeit und ihrer strukturellen wie kulturellen Einbettung erhoben wird, sondern es treten dezidiert angestoßene Veränderungsprozesse und deren Analyse im laufenden Prozess in den Vordergrund. Es wurden also nicht nur Problemszenarien in Bezug auf Teamarbeit in agilen Kontexten herausgestellt, sondern gleichermaßen bereits bestehende Praktiken im Umgang mit diesen Problemen herausgestellt oder neue Maßnahmen erarbeitet. Im Vordergrund stand bei allen Aktivitäten demnach der erfahrungsbasierte Einbezug der beteiligten Akteure und damit eine partizipative Gestaltung und Umsetzung der im Forschungsprojekt entwickelten Maßnahmen und Tools. Inwiefern sich im Hinblick auf die Teambeschaffenheit in agilen Kontexten Fragen zu Grenzen und Emergenz der Strukturen des Teams neu stellen,unterscheidet sich in den Teams der beiden Unternehmen nur unerheblich (so gibt es bisweilen größere Unterschiede zwischen Teams im eigenen Unternehmen als zwischen Teams der beiden Fallunternehmen) und so folgen wir in der weiteren Darstellungen auch keiner fallweisen Betrachtung. Vielmehr werden die Fragen zur Teambeschaffenheit im Folgenden beispielhaft an vier fallübergreifenden Problemszenarien illustriert, die im Kontext der Interviews und der Workshops mit den Teams in beiden Softwareunternehmen herausgearbeitet wurden: ausgeprägte Kundenintegration, Existenz eines Produktmanagers bei agilen Teams, Multi-Teamstrukturen und über mehrere Standorte verteilte Teams. Die auf den ersten Blick so unterschiedlichen Beispiele haben gemeinsam, dass hier jeweils die Beziehung zur Umwelt unmittelbar relevant ist und die betroffenen Beschäftigten den Begriff „Team“ ganz selbstverständlich für mehrere unterschiedliche arbeitsorganisatorische Konstellationen nutzen. Zudem zeigen alle Beispiele, mit welchen Herausforderungen und auch Belastungen agile Teams in den Fallunternehmen bei der Bewältigung der Selbstorganisationsaufgaben der Grenzziehung und der Entwicklung einer inneren Struktur konfrontiert sind. Für die Bewältigung reicht die Anwendung der oben beschriebenen agilen Methoden, Instrumente und Rollen allein nicht aus. Sie bedarf besonderer Voraussetzungen und Rahmenbedingungen, sollen Beschäftigte nicht in widersprüchliche Arbeitsanforderungen und Stress geraten.

2.4.1 Kundenintegration

Mit Blick auf die in agilen Ansätzen und insbesondere bei der Scrum-Methode starke Integration des Kunden in den Entwicklungsprozess zeigt sich empirisch, dass die Frage aufkommt, ob und inwiefern der Kunde auch zum agilen Team gehört. Im Scrum-Prozess leistet der Kunde zu den ganz konkreten alltäglichen Arbeitsabläufen und ineinandergreifenden Arbeitstätigkeiten der Softwareentwickler einen direkten Beitrag und ist dadurch sogar teilweise in den Produktionsprozess einbezogen. So arbeiten Product Owner und Kunde intensiv und kurztaktig inhaltlich zusammen, zudem nimmt der Kunde auch an definierten Teammeetings teil. Die Kundenintegration kann aber auch so weit gehen, dass Beschäftigte aus dem Kundenunternehmen als Product Owner in agilen Teams eingesetzt werden und somit eine definierte Rolle im Scrum-Team einnehmen oder dass der Kunde sich jederzeit mit spezifischen Anforderungen und Anfragen an einzelne Entwickler wenden kann. Obwohl insbesondere letzteres in den Lehrbüchern zu agilem Arbeiten nicht vorgesehen ist, findet ein solch „intensiver Durchgriff“ durch den Kunden in der Praxis immer wieder statt. In unseren Untersuchungen wurde ein enger Zusammenhang zwischen der Form der Kundenzusammenarbeit und dem Grad an Selbstorganisation agiler Teams sowie der Möglichkeit eines nachhaltigen, belastungsarmen Arbeitsfortschritts deutlich. So leiden Beschäftigte unter gesteigertem Zeit- und Leistungsdruck, je häufiger und unregulierter ein Kunde neue Wünsche, Informationen, Anfragen etc. in laufende Arbeitsprozesse des agilen Teams einbringt. Dies führt zudem zu permanenten Unterbrechungen, die den Arbeitsfluss stören und die Zielerreichung gefährden, was von den Beschäftigten ebenfalls als belastend empfunden wird. In starkem Kontrast zu dieser praktischen Relevanz wird das Thema in der Forschung kaum diskutiert. Vielmehr wird agilen Methoden „Kundenzentriertheit“ als Selbstverständlichkeit zugeschrieben, vor allem von den Führungskräften und Beschäftigten selbst.

Sowohl die formale als auch die informelle Grenze eines agilen Teams werden durch die starke Kundenintegration schwammig und zum Gegenstand von impliziten und expliziten Aushandlungen durch alle Beteiligten. Selbst die formale Grenze der Organisation kann unter solchen Bedingungen letztlich nicht mehr zur Bestimmung der Teamgrenze herangezogen werden. Schwierig werden Fragen der Grenzziehung in Richtung Kunde vor allem in Bezug auf zwei Aspekte: 1) Der Kunde repräsentiert den Geld- und Auftraggeber und verfolgt damit in vielerlei Hinsicht grundlegend andere Interessen als die Beschäftigten des auftragnehmenden Unternehmens. Dies gilt bspw. hinsichtlich Geschwindigkeit des Entwicklungsprozesses und der Qualität von (Teil)Ergebnissen. Wohingegen Softwareentwickler ein ausgeprägtes Interesse an „sauberen“ Codes und den dafür notwendigen Zeithorizonten im Entwicklungsprozess zeigen, sind Kunden (auch aus mangelndem softwaretechnischen Verständnis heraus) im Schwerpunkt daran interessiert, ein funktionierendes (Teil)Ergebnis in möglichst kurzer Zeit zu erhalten. Die Folgeaufwände durch unsauber programmierte Software werden dabei in der Regel kundenseitig unterschätzt. 2) Der Kunde arbeitet im agilen Entwicklungsprozess bis zu einem gewissen Grad immer auch am eigentlichen Produkt mit. Dies wirft jedoch zum Teil sehr komplexe Fragen hinsichtlich des geistigen Eigentums von technischen Entwicklungen auf. Es ist daher für das Softwareunternehmen und dessen Beschäftigte von besonderer Wichtigkeit, eine möglichst klare Abgrenzung zwischen Kernprodukt und dem entsprechenden Entwicklungsknowhow einerseits und der Nutzerperspektive und Kundenexpertise andererseits zu erzeugen. Derlei Aspekte sind Gegenstand permanenter impliziter und expliziter Aushandlungen in agilen Teams. Das formale und informelle Ausmaß der Integration des Kunden in das agile Team muss je nach Interessenlage und technischen Anforderungen (beides variiert im Lauf des Entwicklungsprozesses) bestimmt werden.

Gleichzeitig ist die Integration des Kunden auch für die Selbstorganisation agiler Teams höchst ambivalent. Der direkte Kontakt zum Kunden kann die Selbstorganisation vereinfachen und effizienter machen, indem das Team Kundenwünsche direkt aufgreifen, angemessen und schnell reagieren und evtl. Missverständnisse kurzfristig klären kann. Durch eine starke Kundenintegration kann die Selbstorganisation jedoch auch unterminiert werden, wenn der Kunde dominant, kontrollierend oder sprunghaft auftritt und damit die kurz- und mittelfristigen Planungen im agilen Team und die einzelnen Arbeitsabläufe immer wieder konterkariert. Nicht nur zu Beginn eines Projekts bestehen zwischen Team und Kunden oft unterschiedliche Vorstellungen von Agilität sowie Erwartungen an die agile Zusammenarbeit. Das gilt zumal, wenn Akteure mit unterschiedlichem Agilitätsgrad an einem Projekt beteiligt sind. Werden die Voraussetzungen für die agile Zusammenarbeit nicht nach allen Seiten hin geklärt, gerät die Arbeitsweise der agilen Teams leicht unter Druck, insbesondere dann, wenn das Team in diesem Klärungsprozess von Führungsseite keine Unterstützung zur Wahrung ihrer arbeitsinhaltlichen Interessen erhält. Empirisch bewährt hat sich eine systematische Integration des Kunden, bei der dessen direkter Einfluss durch eine „Pufferfunktion“ (z. B. Product Owner) gemindert wird oder der Einbezug nur in bestimmten Meetings erfolgt. Durch einen solchermaßen direkten aber zeitlich und situativ beschränkten Einbezug des Kunden kann die Selbstorganisation geschützt werden bei gleichzeitig systematischer Grenzziehung, was von den betroffenen Beschäftigten als positiv und entlastend erfahren wird.

2.4.2 Agile Teams in klassischen Führungsstrukturen

In der Regel sind agile Teams derzeit und mit hoher Wahrscheinlichkeit auch zukünftig in nicht-agilen oder hybriden (also nur zum Teil agilen) Gesamtorganisationen eingebettet. Der dem eigenen Anspruch nach durch Hierarchiefreiheit und Selbstorganisation geprägte Arbeitszusammenhang in agilen Teams muss also in hierarchische und fremdorganisiert geprägte Umwelten eingebettet werden. Dies sieht zumeist so aus, dass „oberhalb“ der Teamebene ein klassischer Projektleiter, Produktmanager oder eine andere Funktion als Führungskraft fungiert. Diese Führungskraft muss Einblicke in die Arbeit des Teams gewinnen und verfügt über je spezifische Weisungsbefugnisse. Sollen die Prinzipien agiler Projektarbeit (insb. Selbstorganisation und hierarchielose Interaktion auf Augenhöhe) jedoch nicht unterminiert werden, erfordert dies von der entsprechenden Führungskraft eine besondere Form der Zusammenarbeit mit und Positionierung zu einem agilen Team. Empirisch beobachtbar ist hingegen, dass agile Teams oftmals mit Führungsstrukturen konfrontiert sind, die einem eher klassischen Verständnis von Weisungsbefugnis und Kontrolle verbunden sind, sodass letztlich doch eine de-facto-Projektleitungsfunktion installiert wird. Dabei werden dann führungsseitig die mit agiler Selbstorganisation verbundenen gesteigerten Effizienz- und Effektivitätseffekte erwartet, die hierfür notwendigen Voraussetzungen jedoch nicht geschaffen. Dies führt zu widersprüchlichen Arbeitsanforderungen aufseiten der Teammitglieder und enttäuschten Erwartungen sowohl führungs- als auch beschäftigtenseitig.

Dies zu vermeiden, erfordert einen gewissen Aushandlungs- und Gestaltungsaufwand. Im konkreten empirischen Positivbeispiel ist der vorhandene Produktmanager formaler Vorgesetzter des Product Owners. Product Owner und Produktmanager definieren sich aber als Arbeitstandem, das mit unterschiedlichen Verantwortungsbereichen auf Augenhöhe zusammenarbeitet. Der Produktmanager nimmt bewusst keine direktive Haltung gegenüber dem Product Owner oder dem weiteren agilen Team ein. Er schränkt seine Weisungsbefugnisse selbst soweit ein, dass er möglichst keinen direkten Einfluss auf die selbstorganisierten Prozesse im Team ausübt und bleibt in vielerlei Hinsicht bewusst in Unkenntnis darüber, welche Entscheidungen das Team auf der Arbeitsprozessebene in welcher Form trifft. Stattdessen begreift er sich als eine Art eng gekoppelten „Teamsatellit“, dessen Aufgabe es ist, das agile Team von bestimmten, sich zu Agilität widersprüchlich oder konflikthaft verhaltenden organisatorischen und finanztechnischen Aspekten der nicht-agilen Unternehmensorganisation „abzupuffern“, sodass die interne Selbstorganisation des Teams von externen Ansprüchen möglichst unbelastet bleibt. So klärt und erläutert er die Voraussetzungen und Besonderheiten der agilen Arbeitsweise in Richtung oberes Management und handelt mit diesem verlässliche Rahmenbedingungen aus, er leistet „Vermittlungs- und Übersetzungsarbeit“ in Richtung nicht-agil arbeitender Unternehmensbereiche (z. B. Vertrieb, Rechtsabteilung) und schafft in neuen Kundenkontakten erste grundlegende Übereinkünfte zur agilen Zusammenarbeit. Er nimmt somit also zum einen eine hochfunktionale Rolle für die Selbstorganisation des Teams ein, indem er essenzielle Voraussetzungen hierfür in der Gesamtorganisation und in Richtung Kunde schafft. Zum anderen schafft er dadurch für das Team die Möglichkeit, sich gegenüber spezifischen Ansprüchen einer nicht-agilen Organisation inhaltlich, prozessual und personell abzugrenzen. Gleichzeitig steht er in einem direkten intensiven Arbeitszusammenhang mit dem Product Owner und kann selbst die Teamgrenze nach innen und außen nach eigenem Ermessen überschreiten bspw. indem er situativ über den Product Owner mehr oder weniger starken Einfluss auf die teaminternen Arbeitsprozesse nimmt (insbesondere hinsichtlich der Formulierung von Zielen und deren Dringlichkeit). Der Produktmanager nimmt also keine klassische Führungsrolle ein, sondern agiert eher als erweitertes Teammitglied mit funktionaler Rolle für die teaminterne Selbstorganisation und die Grenzziehungsprozesse zur umgebenden Organisation, kann aber prinzipiell jederzeit in seinem Verhalten einen stärkeren Fokus auf klassische Führungsansätze legen. Diese besondere Konstellation beruht auf einem etablierten Vertrauensverhältnis zwischen dem operativen Team und dem Produktmanager als Teamsatellit. Sie ist in keiner Weise formal festgehalten, sondern Ergebnis informeller Vereinbarungen und impliziter Übereinkünfte, die im Zweifelsfall jeweils aktualisiert oder gar neu ausgehandelt werden müssen.

2.4.3 Agile Multi-Teams

Als besonders komplex zeigen sich Konstellationen von Multi-Teams, also große Scrum-Teams in denen mehrere agile Teilteams arbeitsteilig an einem gemeinsamen Produkt arbeiten. Multi-Teams können personell so umfangreich und arbeitsteilig so ausdifferenziert sein, dass es selbst für die Teammitglieder schwierig ist, den Überblick zu behalten. Empirisches Beispiel ist ein größeres Produktentwicklungsprojekt, in dem teilproduktspezifische Kundenaufträge im Verbund mehrerer funktionaler Teilteams bearbeitet werden. So werden beispielsweise die Kundenanforderungen von einem Vertriebsteam aufgenommen und an ein Entwicklungsteam weitergegeben. Hierfür ist es notwendig, dass das Vertriebsteam die agile Arbeitsweise des Entwicklerteams grundlegend versteht und auch entsprechend in der Auftragsvorbereitung berücksichtigen kann (dies geht bis hin zur agilen Vertragsgestaltung). Dabei stößt man jedoch an Grenzen. So ist es dem Vertriebsteam bspw. nicht möglich, das Prozedere der agilen Aufwandsschätzung im Rahmen eines Sprints durch das Entwicklerteam zu antizipieren. Das agile Entwicklungsteam wiederum steht immer wieder vor dem Problem, dass ihm das „Gesamtbild“ fehlt, sowohl was die Kundenanforderungen betrifft, denn der Kontakt findet nur vermittelt über das Vertriebsteam und später den Product Owner statt, als auch bezüglich der übergreifenden Entwicklung des Gesamtprodukts (etwa: In welche Richtung soll es grundsätzlich weiterentwickelt werden? Was sind wichtige nächste strategische Schritte? Welches Teilteam arbeitet gerade woran?). Die Beschäftigten empfinden dies durchaus als belastend, da sie in Selbstorganisation gesteigerte Verantwortung übernehmen sollen, ihnen jedoch relevante Kontextinformationen für adäquat aufeinander abgestimmte Arbeitsprozesse fehlen. Im Zusammenspiel dieser Herausforderungen kommt es damit laufend zu dem Phänomen des „Eisberg“-Problems: Ein zu Sprintbeginn geschätzter Aufwand stellt sich im Sprintverlauf als deutlich größer heraus, weil viele grundlegende Anforderungen nicht von vornherein klar sind.

Trotz der komplexen Struktur kann bei diesem Beispiel keine Rede davon sein, dass die differenzierte Arbeitsteilung zu einer de facto Silo-Struktur führt und sich das agile Multi-Team und deren einzelne Mitglieder folglich nicht als ein Gesamtteam begreifen. Im Gegenteil sorgt gerade die besondere Organisationsform des agilen Arbeitens dafür, dass die Teilteams sich verhältnismäßig stark aufeinander beziehen und sich sehr wohl als zusammengehörig definieren. Gleichzeitig sind sie mit besonderen Herausforderungen bezüglich Selbstorganisation und Grenzziehung konfrontiert.

In Multi-Teams sind die Grenzziehungen zwischen den Teilteams mitunter nicht eindeutig und werden auch situativ neu bestimmt. So gibt es immer wieder Projektphasen, in denen es notwendig ist, dass das Entwicklerteam und das Testteam intensiv zusammenarbeiten und daher zeitweise neue Kooperationsstrukturen etabliert werden. Auch in Planungsphasen müssen Multiteams sich insgesamt deutlich stärker integrieren, um sich dann in einer anschließenden Arbeitsphase wieder mehr auf einzelne Aufgabenbereiche hin zu differenzieren. Die notwendige situative Bestimmung und Gestaltung von internen Grenzziehungen und Kooperationsformen führt also zu einer permanenten Arbeit an der inneren Teamstruktur, die laufend aktuellen Anforderungen angepasst werden muss. Dies ist gleichermaßen eine Aufgabe, die die Teilteams und das Gesamtteam in Selbstorganisation bewältigen müssen. Die Lösungen hierfür liegen nicht immer auf der Hand, insbesondere da das Tagesgeschäft die Kapazitäten in der Regel bindet und wenig Raum zur Klärung übergreifender Organisationsfragen bleibt. Im empirischen Beispiel versuchen die Teilteams sich gegenseitige Einblicke zu ermöglichen, indem Vertreter wechselseitig an bestimmten agilen Meetings und weiteren Besprechungen teilnehmen. Allerdings geraten die Beschäftigten auch hier schnell ihre Grenzen, da schon im regulären Tagesgeschäft viel Zeit für Besprechungen aufgewandt werden muss.

2.4.4 Verteilte agile Teams

Eine große Herausforderung für die Integration eines agilen Teams stellt die räumliche Verteilung über zwei oder mehrere Standorte hinweg dar.Footnote 2 Die räumliche Distanz erschwert die direkte Kommunikation und Kooperation. Dieses Problem wird vor allem mithilfe von digitalen Kollaborationstools (angefangen bei Videotelefonie bis hin zu komplexen Kooperationsplattformen) zu lösen versucht. Die Analyse der Beobachtungen von agilen Meetings hat jedoch gezeigt, dass diese Tools nur bis zu einem gewissen Grad die persönliche Interaktion vor Ort ersetzen können. Dies hängt insbesondere damit zusammen, dass in verteilten Teams auch starke sozialstrukturelle und arbeitsorganisatorische Differenzen bestehen: angefangen bei Sprache und Kultur, über unterschiedliche organisationale Einbettung, Gehaltsstrukturen und Ungleichverteilung von agilen Rollen, bis hin zu völlig unterschiedlicher Stellung im unternehmensinternen Macht- und Hierarchiegefüge. Beispielsweise befindet sich der Product Owner in der Regel im Teilteam am Hauptstandort, dieses Teilteam hat dadurch einen Vorteil hinsichtlich Informationslage und Kontakt zum Kunden und steht in der Regel in einem besseren Kontakt mit Führungskräften und oberem Management. Dies führt außerdem oftmals dazu, dass die inhaltlich interessanten und prestigeträchtigen Arbeitsaufgaben überwiegend im Teilteam am Hauptstandort bearbeitet werden. Derlei Differenzen manifestieren sich in spezifischen Anforderungen und Problemen der selbstorganisierten Zusammenarbeit. Die räumliche Distanz führt jedoch dazu, dass diese vielschichtige Ungleichheit im Arbeitsalltag in der Regel nicht adressiert, geschweige denn kooperativ bearbeitet werden kann. Die Teilteams empfinden dann eine deutliche Zäsur zwischeneinander, die Teammitglieder betrachten die direkten Kolleg*innen am eigenen Standort als die jeweils „eigentlichen“ Teamkolleg*innen. An Nebenstandorten empfinden die Beschäftigten einen Mangel an Anerkennung ihrer Expertise und Leistungsfähigkeit, insbesondere dann, wenn sie sich auf arbeitsinhaltlicher Ebene in die Rolle einer „verlängerten Werkbank“ gedrängt sehen.

Unter diesen Bedingungen gerät Selbstorganisation unter massiven Druck. Unseren Untersuchungen nach liegt dies vor allem daran, dass verteilte Teams nur sehr begrenzte Möglichkeiten haben, sich zentrale Voraussetzungen für Selbstorganisation zu erarbeiten. Diese sind a) der teamweite Austausch und Erwerb von Erfahrungswissen über agiles Arbeiten („Was verstehen wir darunter?“) sowie über das jeweilige agilitätsbezogene Erfahrungswissen, die fachliche Expertise und die Persönlichkeit der Teamkolleg*innen, b) die Entwicklung einer gemeinsamen Sprache im Sinne geteilter Interpretationen von Begriffen und Aussagen und c) die laufende inhaltliche und zeitliche Synchronisation in laufenden Arbeitsprozessen, also über funktionale Arbeitsteilung und formale Integration von Teilergebnissen hinaus. Die räumliche Verteilung macht es schwierig, diese Voraussetzungen zu schaffen. Hierfür gibt es relativ offensichtliche Gründe, wie z. B. technische Probleme mit digitalen Kommunikations- und Kollaborationstools wie Skype, JIRA etc. oder deren eingeschränkte Flexibilität gegenüber physischen Zusammenarbeitsmethoden. Die sprachliche Vermittlung kann eine Herausforderung darstellen, wenn Teile des Teams nicht in der Muttersprache kommunizieren, z. B. bei der Übersetzung von Fachbegriffen oder auch bei der Vermittlung von Kundenanforderungen. Zudem erschweren unterschiedliche Arbeitsrhythmen die standortübergreifende Koordinierung von Meetings, Calls usw.

Besonders schwer wiegen jedoch zwei Herausforderungen, die nicht auf den ersten Blick erkennbar sind. Digital vermittelte Kommunikation (Skype, Chat, Mail etc.) ist in verteilten Teams unerlässlich, sie eröffnet enorme Möglichkeiten der Zusammenarbeit und die entsprechenden Anwendungen werden von den Beschäftigten in der Regel gerne genutzt. Dennoch stellt sie keinen Ersatz für die unmittelbare und persönliche Kommunikation dar, sondern kann diese immer nur ergänzen. So fehlen unseren Erhebungen nach bei ausschließlich digital vermittelter Kommunikation, die permanenten situativen Gelegenheiten für den Austausch expliziter und impliziter Informationen sowie für explizite und implizite Klärungsprozesse quasi ‚nebenbei‘. Diese Klärungsprozesse finden bei Weitem nicht nur im Rahmen der formalen Scrum-Meetings statt, sondern vor allem auch in laufenden Arbeitsprozessen und informellem Austausch. Fehlen diese situativen Gelegenheiten, passiert es, dass Missverständnisse nicht geklärt werden, sondern lange Zeit bestehen bleiben und sich evtl. sogar potenzieren. Als Folge entwickelt sich eine entsprechende Unzufriedenheit im Team. Zudem ist es äußerst schwierig, in ausschließlich digital vermittelter Kommunikation ein Gespür für die anderen Teammitglieder, deren Aussagen und Handlungen zu entwickeln.

Die zweite besonders schwierige Herausforderung liegt darin, über die Standorte hinweg eine Interaktion auf Augenhöhe zu etablieren. Neben dem zweifelsohne wichtigen Aspekt unterschiedlicher Arbeitskulturen und -mentalitäten wiegen unseren Untersuchungen nach die oben bereits angesprochenen strukturellen Aspekte deutlich schwerer, die mit expliziten und impliziten Macht- und Interessensungleichgewichten zwischen Haupt- und Nebenstandorten im Zusammenhang stehen, welche wiederum in den konkreten Arbeitsprozessen latent oder manifest eine Rolle spielen und die für gelungene Selbstorganisation notwendige Kooperation und Kommunikation negativ beeinflussen.

Verteilte agile Teams, denen es gelingt, solchen Problemen entgegenzuwirken tun dies, indem sie aktiv und dauerhaft an ihrer inneren Teamstruktur arbeiten. Im Kern steht dabei die Etablierung und dauerhafte Pflege des persönlichen Kontakts unter allen Teammitgliedern durch wiederkehrende wechselseitige individuelle Besuche vor Ort und durch regelmäßige übergreifende Teamzusammenkünfte. Der persönliche direkte Kontakt schafft die Voraussetzungen dafür, dass das Team eine gemeinsame Vorstellung von agilem Arbeiten entwickeln kann, dass man die Denkweise der Kolleg*innen kennenlernen kann, dass man gemeinsame Interpretationen finden kann und über den formalen Rahmen hinaus, also jenseits von agilen Meetings kommuniziert sowie über Anwendungen in Kollaborationstools hinaus kooperiert. Das persönliche Kennenlernen befördert damit die notwendige Synchronisierung über die Standorte hinweg in besonderem Maß, man stimmt sich auch zusätzlich zu und zwischen offiziellen Meetings und der Nutzung agiler Tools informell und situativ ab. Erst dann gelingt es, sich als Team mit einer gemeinsamen Aufgabe zu begreifen und zur erfolgreichen Bearbeitung dieser Aufgabe eine selbstorganisierte interne Verteilung von Aufgaben und Verantwortlichkeiten sowie gemeinsam entwickelte und akzeptierte Kommunikations- und Kooperationspraktiken zu etablieren – also eine tragfähige Teamstruktur auszuhandeln, aufrecht zu erhalten und bei Bedarf anzupassen. Damit wird auch die räumlich und organisationsstrukturell induzierte Grenzziehung innerhalb des Teams aufgelöst und das gesamte Team als definierte Einheit an den einzelnen Standorten stärker repräsentiert.

2.4.5 Grenzziehung und interne Strukturierung als permanente Aufgabe in Selbstorganisation

Die empirischen Beispiele machen deutlich, dass über agile Teamarbeit isoliert von Fragen der Grenzziehung und Herausbildung von Teamstrukturen nicht nachgedacht werden kann. Beides muss außerdem als spezifische Aufgaben der Selbstorganisation in entsprechenden agilen Teams betrachtet werden, die nicht allein durch die lehrbuchgetreue Anwendung von Scrum bewältigt werden können. Die betrieblich-organisationale Einbettung dessen, was als agiles Team betrachtet werden kann, stellt hierbei einen zentralen Aspekt dar, der die Frage der Grenzziehung erst bedeutsam macht. Die Selbstorganisation agiler Teams findet in bestehenden organisationalen Strukturen statt und muss entsprechend mit bestehenden Bedingungen in Einklang gebracht werden, insbesondere mit hierarchischen und Führungsverhältnissen sowie internationalisierten Unternehmensstrukturen. Der Blick auf die formale Zugehörigkeit zu einer definierten Gruppe reicht nicht aus, um die besonderen Anforderungen an agile Selbstorganisation in fluiden Strukturen zu erfassen. Notwendig ist vielmehr die Betrachtung der alltäglichen Arbeitsprozessebene, auf der ganz konkrete Fragen von Inklusion und Exklusion, von Einbindung und Abgrenzung in alltäglichen Kooperations- und Kommunikationsprozessen zwischen Standorten, zwischen Hierarchieebenen und mit Kunden bearbeitet werden müssen. Dies erfolgt eben nicht nur über formale Regelungen von Zugehörigkeit und Weisungsbefugnissen, sondern vor allem auch im Rahmen informeller Zusammenarbeit und Aushandlungen. Dies bedeutet auch, dass sowohl die Grenzen als auch die interne Struktur agiler Teams immer nur vorläufig sind und sich verändern können oder auch müssen, sobald sich die Umweltbedingungen in der Gesamtorganisation oder auch bezüglich des Kunden verändern (Reorganisation, Standortwechsel/-neuerungen, neue Ansprechpartner beim Kunden, veränderte Anforderungen oder Vorgehensweisen beim Kunden etc.). In solchen Konstellationen kann das Team nicht zu jedem Zeitpunkt eindeutig bestimmt und formal definiert werden. Im Gegenteil sind vergleichsweise lange Phasen oder sogar dauerhafte Konstellationen der latenten oder manifesten Uneindeutigkeit beobachtbar.Footnote 3 Dennoch besitzt die Idee des Teams als Bezugseinheit besondere Relevanz für die zusammenarbeitenden Personen und die umgebende Organisation.

Projektteams, ob agil oder nicht-agil, stellen mehrschichtige und komplexe soziale Arbeitsgefüge dar, innerhalb derer mitunter Sub- und Teilteams auch organisationsübergreifend eingebettet sind und in denen die Formen und Strukturen der Selbstorganisation als gemeinsamer Bezugspunkt jeweils von aktuellen inhaltlichen Aufgaben und organisatorischen Herausforderungen geprägt sind. Mehr als in klassischen Projektmanagementansätzen sehen sich agile Teams jedoch mit der besonderen Herausforderung konfrontiert, diese Formen und Strukturen der Selbstorganisation auch selbst herzustellen. Die Frage „Wer ist das Team und wie arbeiten wir zusammen?“ muss das Team maßgeblich selbst bearbeiten und beantworten. Dies kann unter den skizzierten Umständen jedoch nur jeweils situativ sowie oftmals auch nur uneindeutig erfolgen und wird zum Kristallisationspunkt: Die Klärung der Team-Frage ist gleichermaßen Voraussetzung und Gegenstand agiler Selbstorganisation. Dass dies kein reibungsloser Prozess sein kann, der im Gegenteil auch Belastungen für die betroffenen Beschäftigten mit sich bringt, wurde in den empirischen Beispielen bereits angesprochen und wird an anderer Stelle weiter vertieft.Footnote 4 Im Rahmen der vorliegenden Untersuchungen wurden Gestaltungsempfehlungen entwickelt, die solchen Belastungen vorbeugen können und die gleichermaßen die Selbstorganisation in agilen Teams stärken, indem Wege zur konstruktiven Grenzziehung und zur tragfähigen internen Strukturierung aufgezeigt werden. Im Folgenden wird ein knapper Überblick gegeben.Footnote 5

2.5 Empfehlungen für die Stärkung von agiler Selbstorganisation unter Bedingungen von Fluidität

Im Folgenden werden formale generalisierte Modelle zur Stärkung agiler Selbstorganisation skizziert. Diese sind weder für alle Kontexte in gleicher Weise anwendbar, noch lösen sie alle beschriebenen Herausforderungen. Zum einen wird es bei der Anwendung immer darum gehen, das gegebene Modell mit Blick auf die konkreten Umstände anzupassen. Zum anderen können die Modelle selbst nur Bausteine auf dem Weg zur Verbesserung der Rahmenbedingungen und Abläufe agiler Selbstorganisation sein. Sie müssen jeweils insbesondere durch den Blick auf informelle Formen, Möglichkeiten und Bedarfe zur Unterstützung agiler Selbstorganisation ergänzt werden.

Praktisch gesehen, stellt sich jedoch die Frage, wann die jeweiligen Modelle zum Einsatz kommen sollen. Allgemein gesprochen, müssen die oben genannten Aspekte einer ständigen Überprüfung unterzogen werden. Konkret wurde im Kontext des diGAP-Projekts zur Unterstützung dieser Frage ein Selbstcheck entwickelt, der agil arbeitenden Teams die Reflexion der eigenen Arbeit ermöglicht.Footnote 6 Der Selbstcheck kann von den agilen Teams durchgeführt werden und liefert differenzierte Informationen hinsichtlich welcher eng mit den oben genannten Problemszenarien verbundenen Dimensionen ein Nachbesserungsbedarf besteht. Damit werden sowohl konkrete Schwellenwerte für die Anwendung der Modelle geboten als auch der formale sowie informelle Austausch zu Fragen bezüglich der Teilaspekte agiler Projektarbeit angestoßen. Der Selbstcheck dient also auch als Initiierung zur aktiven Grenzziehung und internen Strukturierung auf Teamebene.

2.5.1 Modell der dauerhaften Teamentwicklung zur Stärkung agiler Selbstorganisation

Gelungene agile Selbstorganisation auf Basis funktionierender Kommunikation,Kooperation und Koordination zeichnet sich dadurch aus, dass die arbeitsbezogenen Bedarfe aller Teammitglieder berücksichtigt und Einzelaufgaben funktional und effektiv integriert werden, adäquater formaler und informeller Austausch stattfindet, teamspezifische explizite und implizite Arbeitsnormen und -regeln etabliert werden, auf deren Basis Perspektivenwechsel stattfinden, wechselseitiges Vertrauen entstehen und Verantwortung für die eigene und die Teamaufgabe übernommen werden kann. Tragfähige und funktionale Kommunikation, Kooperation und Koordination sind jedoch kein automatisches Nebenprodukt der Implementierung agiler Methoden, sondern müssen durch dauerhafte Teamentwicklung nachhaltig etabliert werden. Die Anwendung des Modells bietet sich insbesondere dann an, wenn im Zuge des Selbstchecks die Werte für „Teamkultur“ sowie der „organisationalen Einbettung des Teams“ als kritisch angezeigt wird.

Konkret zielt das Modell zur Teamentwicklung nicht zuletzt auf die Problemszenarien der „verteilten Teams“ sowie der „agilen Multi-Teams“ und unterstützt die interne Strukturierung, insofern ein Verständigungsprozess über Agilität und die konkreten Anforderungen und Bedarfe im Arbeitsprozess geschaffen wird. Zentrale Themen sind:

  • die Anwendung theoretischen Wissens über Agilität in der Arbeitspraxis (z. B. Interpretation von Rollen, Aufgaben, Besprechungsformaten, Artefakten),

  • Aspekte, die die agile Methode selbst offenlässt (z. B. Herstellung einer gerechten Arbeitsteilung, Umgang mit technischen Schulden),

  • der Blick auf den gemeinsamen Arbeitsgegenstand (bzw. das übergreifende Produkt) und

  • die Wahrnehmung unterschiedlicher beruflicher Hintergründe, arbeitsinhaltlicher Interessen und individueller Entwicklungsperspektiven.

Zur Teamentwicklung kommt ein agiles Team regelmäßig zusammen und wendet mindestens zwei der folgend dargestellten themenzentrierten Workshopformate („Bausteine“) aus dem „Baukasten Teamentwicklung“ an:

  • Technics: Hierbei handelt es sich um einen obligatorischen Baustein aus dem Baukasten Teamentwicklung. In diesem Workshopformat werden technisch-fachliche Aspekte und Fragestellungen im Team erörtert.

  • Agility: Hierbei handelt es sich um einen obligatorischen Baustein. Das Team vergegenwärtigt sich und diskutiert die teamspezifische agile Arbeitsweise.

  • Business Operations: Hierbei handelt es sich um einen optionalen Baustein. Das Team diskutiert seine betrieblich-strukturelle Einbettung und evtl. diesbezügliche neue Anforderungen.

  • Work Mob: Hierbei handelt es sich um einen optionalen Baustein. Das gesamte Team arbeitet für einen definierten Zeitraum gemeinsam vor Ort.

  • Beyond Work: Hierbei handelt es sich um einen optionalen Baustein. Das Team verbringt gemeinsame Zeit jenseits der Arbeit.

Das Team bestimmt über Zusammensetzung der Bausteine und zeitliche Abstände, zu denen der Baukasten zum Einsatz kommt. Es bestimmt auch darüber, wer an dieser Form der Teamentwicklung teilnimmt. Die Frage, wer Teil des Entwicklungsprozesses ist bzw. sein soll, ist selbst eine Frage der Teamentwicklung und muss im Vorfeld diskutiert werden und/oder kann bspw. explizit zum Thema in den Bausteinen Agility oder Business Operations gemacht werden. Es schafft sich damit Gelegenheiten für direkte Interaktion und Austausch zwischen allen Mitgliedern sowie für gemeinsame Reflexion über agiles Arbeiten. Es tritt so in einen Prozess der internen Strukturierung ein und stabilisiert dadurch die agile Selbstorganisation. In bestimmten Situationen ist der Einsatz des Baukastens besonders angezeigt (z. B. neue Teammitglieder, veränderte technische/organisationale Rahmenbedingungen, Unzufriedenheit/Konflikte im Team, verteilte Teamstandorte).

2.5.2 Modell der Hospitation zur Qualifizierung für Gutes agiles Arbeiten

Gerade das auf Vertrauen, Selbstorganisation und Zusammenarbeit ausgerichtete agile Arbeiten macht einen unmittelbaren Erfahrungsaustausch im Team notwendig. Es ist daher wichtig, bei der Qualifizierung für agiles Arbeiten über rein formale Ansätze hinauszudenken. Hierfür kann das Hospitations-Modell eingesetzt werden: Statt den Versuch zu unternehmen, Wissen lediglich über einen vorstrukturierten Input zu transferieren, werden im Zeitraum der Hospitation über die unmittelbare Erfahrung agilen Arbeitens Fragen aufgeworfen, die sich erst in der direkten Beschäftigung mit dem Thema ergeben. Zugleich wird die Möglichkeit geboten, sich problemspezifischen Rat einzuholen. Vorteil dieser Form des Wissensaustauschs ist, dass sie nicht an eine von Coaches durchgeführte Veranstaltung gebunden ist, sondern Kolleg*innen mit gleichen oder ähnlichen Erfahrungen zu Rate gezogen werden und damit ein auf Augenhöhe gelagertes Austauschverhältnis angestoßen wird. Mit dem Modell können unterschiedliche Problemszenarien bearbeitet werden, von eher explorativen Ansätzen – etwa bei Neu-Einführung agiler Methoden – bis zur reaktiven Bearbeitung spezifischer Fragen. Dabei sind es gerade die dargestellten Problemszenarien der „verteilten Teams“, der „agilen Multi-Teams“ sowie der „agilen Teams in klassischen Führungsstrukturen“, die mit dem Modell adressiert werden können. Dies sollte insbesondere dann geschehen, wenn der Selbstcheck in den Dimensionen „Förderung methodischer Kompetenzen“, „Führungs- und Governancestrukturen“, „Teamkultur“ und/oder „organisationale Einbettung des Teams“ kritische Werte aufweist.

Durch das Hospitations-Modell rückt die Übertragung von (implizitem) Wissen in den Fokus. Ziel kann es sein, durch Kurzaufenthalte (mind. eine Woche) Außenstehender in agil arbeitenden Teams das Verständnis von Agilität in betroffenen Bereichen, aber auch in der Gesamtorganisation zu entwickeln, um so die Rahmenbedingungen für agile Selbstorganisation zu stärken. Ziel einer Hospitation kann es aber auch sein, die eigene agile Arbeitsweise zu reflektieren und weiterzuentwickeln, insbesondere in Fragen des Umgangs mit Grenzziehungs-Problematiken und bei Herausforderungen bezüglich der internen Strukturierung, die zu einem großen Anteil in informellen Praktiken und Aushandlungen geklärt werden müssen. Die Verbreitung der Praktiken und des Wissens um Sinn und Nutzen, aber auch komplexe Herausforderungen von agiler Selbstorganisation soll durch Einsichten in den Alltag dieser Teams unterstützt werden. Durch die Mitarbeit im agil arbeitenden Team werden die eigenen Aufgaben, Fähigkeiten und Potenziale reflektiert und in Beziehung zu agilen Methoden gesetzt. Gerade das gemeinsame Arbeiten stärkt das Verständnis der Rollen, Prozesse und Möglichkeiten, aber auch der Schwierigkeiten und Grenzen agiler Projektmethoden. Mit Blick auf diese Zielsetzung bietet sich etwa auch der Einbezug von Führungskräften an, welche die agilen Prinzipien bisher nur bedingt verinnerlicht haben.

Es lassen sich drei Schritte differenzieren, in denen die Hospitation abläuft. Vor der eigentlichen Durchführung (Phase II) kommt die genauso wichtige Phase der Vorbereitung (Phase I), danach die Reflexion (Phase III). In Phase I wird sondiert, ob sich das Hospitations-Modell für das eigene Team eignet, und dasjenige Team ausgewählt, das ein gutes Beispiel darstellt und in dem hospitiert werden kann. Die beteiligten Teams einigen sich über eine sinnvolle Zeitspanne, in der die Hospitation stattfinden soll. Dies kann eine Woche sein, sich aber auch über einen Sprint erstrecken. Die Personen, die an der Hospitation teilgenommen haben, fungieren schließlich als Multiplikatoren. Damit diese Multiplikation gelingt, ist die Reflexionsphase notwendig.

2.5.3 Modell zur Gestaltung der Kundeninteraktion

Als typische Probleme bei der Zusammenarbeit mit Kunden beschreiben agile Teams, dass Kunden sich „sprunghaft“ verhalten, statt sachgetrieben zusammenzuarbeiten; oder dass sie ihre Rolle in einer Weise auslegen, die nicht mit der Arbeitsweise des Teams kompatibel ist – z. B. in die Teamplanung hinein regieren und damit die Selbstorganisation des Teams untergraben. Eine im agilen Sinne fruchtbare Kundeninteraktion muss demnach aktiv durch das Team und die Organisation hergestellt und gestaltet werden. Dafür wird ein „Zusammenarbeitsmodell“ mit dem Kunden vorgeschlagen, welches insbesondere das Problemszenario der „Kundenintegration“ adressiert. Gerade Selbstcheck-Kriterium der „Kundeninteraktion“ muss in diesem Kontext Beachtung finden, Aufgrund der abhängigen Stellung des Teams zwischen Kunden und dem durch die Organisation gesetzten Rahmen ist es notwendig, dass dieses Modell von den Führungskräften und dem Teamumfeld unterstützt wird. Es stellt einen Gestaltungsvorschlag für die Kundenschnittstelle dar und ist dem konkreten „Aushandeln“ der Kundeninteraktion vorgeschaltet.

Aus der Sicht der Teams geht es darum, den Sprintzeitraum realistisch zu planen und während des Sprints fokussiert und ohne Überlastung arbeiten zu können. Es muss die unterschiedlichen Perspektiven und „Geschwindigkeiten“ von Kunden, Stakeholdern und Nutzern immer wieder einholen, um das eigene Vorgehen und die eigenen Kapazitäten planen und anpassen zu können. Das Modell „Kundeninteraktion gestalten“ stellt dafür Bausteine zur Verfügung:

Auf der Ebene der Strukturen und der Governance ist es notwendig, eine zur agilen Arbeitsweise passende Ressourcenplanung und Vertragsgestaltung sicherzustellen. Projekt- und Budgetverantwortliche müssen sich abstimmen und realistische Kalkulationen zugrunde legen, die möglichst früh mit Schätzungen des Teams zusammengebracht werden. Diese Ressourcenplanung muss vom strategischen Management mitgetragen werden und erfordert ggf. auch auf übergreifenden Steuerungsebenen Anpassungen, z. B. bei Kennziffern oder Freigabeprozessen. In einem Netzwerk gegenseitiger Beratung mit agilen Teams und Expert*innen können z. B. Budget- und Personalentscheidungen beraten, Schnittstellen und Prozesse zwischen Teams mit unterschiedlichem Agilitätsgrad oder mit den Funktionsbereichen (wie Finance oder Qualifizierung) angepasst werden. So werden wichtige Voraussetzungen für das Gelingen agiler Selbstorganisation in der Gesamtorganisation geschaffen.

Auf der Ebene der agilen Rollen sollte der Product Owner in seiner Vermittlungsfunktion gestärkt werden. Er muss die Wünsche des Kunden aktiv mitgestalten und Eingriffe des Kunden in den Sprint abwehren oder zumindest abpuffern können und braucht dazu eine „Grenzsetzungs-Kompetenz“, die auf allen Führungsebenen als Teil seiner Rolle anerkannt ist. Er – ebenso wie der Scrum Master – ist auch gefragt, um dem Kunden Orientierung und Grundregeln für die Zusammenarbeit mit selbstorganisierten Teams zu vermitteln, etwa durch Klärung, wie und wann Änderungen eingebracht werden können, ohne die Schätzungen des Teams auszuhebeln.

Das agile Review-Meeting dient als „regulierte Interaktion“. Dabei werden Kunden und Stakeholder konsequent und systematisch eingebunden, damit das Team ungefiltert Informationen, Rückmeldung und Verbesserungsvorschläge erhält und seinerseits Transparenz über die Arbeitsfortschritte herstellen und weiteren Klärungsbedarf adressieren kann. In dem agilen Meeting der Retrospektive hingegen sollte das Team in Abwesenheit des Kunden der Reflexion über die Kundenbeziehung Raum geben, z. B. mit der Frage, ob die Kundeninteraktion so gestaltet ist, dass Anforderungen und Entwicklungsrichtung klar werden. Fragen der Integration des und Interaktion mit dem Kunden können in gemeinsamen „Envisioning Workshops“ mit dem Kunden weiter ausgestaltet werden.

Agile Teams unterscheiden sich aufgrund ihrer besonderen Arbeitsorganisationsweise deutlich von klassisch organisierten Projektteams. Dies hat nicht nur Auswirkungen nach innen, also im Team selbst, sondern auch in besonderer Weise nach außen, also in Richtung kooperierender Bereiche, der Gesamtorganisation und sogar über diese hinaus in Richtung des Kunden. Agile Selbstorganisation umfasst mehr als selbstständige Verteilung und Abarbeitung von Aufgaben und erweiterte Handlungsspielräume zur Lösung von Herausforderungen und Innovation. Sie bezieht sich in besonderer Weise auch auf die Konstituierung des agilen Teams selbst, sowohl was dessen innere Struktur (Kooperation, Kommunikation, Koordination) als auch was dessen Grenzziehung nach außen anbelangt. Diese Anforderungen an Selbstorganisation sind nicht final lösbar, sondern erfordern eine laufende Bearbeitung, da sich die Kontextbedingungen hierfür immer wieder verändern. Die Selbstorganisation agiler Teams ist also von einer besonderen Fluidität geprägt und damit wird das Team selbst zu einer fluiden Einheit, in der Konstitution, Mitgliedschaft und Grenzen uneindeutig werden. Agile Selbstorganisation ist teamförmig, „wer“ und „wie“ das Team ist, ist dabei grundlegend offen und muss immer wieder – bspw. unter Nutzung der vorgestellten Modelle – bestimmt werden.