…Die Dinge laufen gut, da jeder aus reiner Leidenschaft tut, was getan werden muss, und zwar so nahtlos, dass ein Beobachter zu dem Schluss kommen könnte, dass jeder die Fähigkeit hat, die Gedanken des anderen zu lesen. Mit dem Wachstum des Unternehmens und des Produkts wächst jedoch auch die Menge an Informationen, die die Teams beherrschen, verwalten und austauschen müssen, um ihre Arbeit zu erledigen. Entscheidungen werden immer kontextabhängiger (sowohl für die Teams als auch für die Produkte), und die Komplexität erfordert eine Art von Struktur, damit die Dinge reibungslos ablaufen, während die Organisation reift. Sie suchen eine Organisationsstruktur, die die Fähigkeit des Teams optimiert, Dinge zu erledigen, um den größten Wert zu schaffen.

✥ ✥ ✥

Effektive Kommunikation und Feedback sind das Herzstück einer effektiven Entwicklung komplexer Systeme, und die Organisationsstruktur sollte für die wichtigsten Kommunikationswege optimiert sein. Kommunikation und regelmäßiges Feedback bilden zusammen mit der Selbstorganisation das agile Herzstück. Die Interaktion von Menschen mit unterschiedlichen, übergreifenden Anliegen ist das Herzstück der Innovation ().

Entwicklungsteams, die an komplexen Produkten arbeiten, kämpfen ständig mit der Dualität von Funktion und Form. Wir neigen dazu, Grenzen zwischen Entwicklungsaktivitäten und Organisationseinheiten entlang dieser Linien zu ziehen. Funktion und Form sind jedoch nur sozial konstruierte und etwas willkürliche Kategorien: Zuverlässigkeit kann für ein bestimmtes System ein ebenso zwingendes Anliegen sein, während Schönheit, Rückwärtskompatibilität oder ein anderes Anliegen eine bestimmte Entwicklungsarbeit dominieren kann. In jedem Fall ist dem Unternehmen am besten gedient, wenn sich das Entwicklungsteam um die wichtigsten geschäftlichen Belange herum organisiert – was auch immer das sein mag.

Wenn Ihr Team gerade in seinen Anfängen reift und sich auf den Aufbau eines Scrum-Teams zubewegt, haben Sie mehr Leute, die bequem als eine organisatorische Einheit arbeiten können, um alle Funktionen eines Unternehmens abzudecken (Release-Planung, Entwicklung und berufliches Wachstum). Aber Wachstum und Reife verursachen auch Unbehagen, da sich die Teams nach der unstrukturierten Effektivität der einfachen Tage der informellen Arbeit sehnen. Um jedoch zu wachsen und das Produkt auf dem Markt richtig zu managen, bedarf es einer einigermaßen disziplinierten Organisationsstruktur und einer leichtgewichtigen Führung.

Kulturen haben ein intrinsisches Bedürfnis nach Struktur für das effiziente Funktionieren des Ganzen. Die effektivste Kommunikation findet immer lokal im Bereich des Vertrauten statt, daher ist es entscheidend, den Entscheidungsprozess auf die wichtigsten organisatorischen Belange zu beschränken. In jeder nicht-trivialen sozialen Organisation ist es wichtig, dass die Menschen schnell in der Lage sind, jeden gegebenen Interessenbereich mit dem effizientesten „Anlaufpunkt“ in Verbindung zu bringen, wenn sie Informationen über diesen Bereich benötigen oder in diesem Bereich Maßnahmen ergreifen müssen.

Eine einfache organisatorische Partitionierung (d.h. eine Hierarchie) reicht in einfachen Bereichen aus, die sich nur mit einem Satz von trennbaren Anliegen befassen müssen. Der hierarchische Ansatz versagt jedoch in dem typischeren Fall von Entwicklungsbemühungen mit mehreren sich überschneidenden Anliegen. Dies drängt zu größeren, komplexeren Organisationseinheiten, die versuchen, das Problem durch Einsparungen beim Umfang zu beheben. Die effektivsten Arbeitsteams sind jedoch kleine Teams, und man muss die Arbeit irgendwie aufteilen.

Doch kein Team ist eine Insel, und eine Entwicklungsnation ist mehr als eine Ansammlung von Inseln. Teams entwickeln individuell ihre eigene Identität, wobei ein natürlicher Sinn für Fremdenfeindlichkeit (Bedürfnis nach Vertrautem) dazu führt, dass Teams Anliegen, die von außerhalb ihres sozialen Umfelds kommen, nur eine untergeordnete Bedeutung beimessen. Wenn Sie das Unternehmen auf eine Reihe von sozialen Interaktionen beschränken, die auf einer einzigen einfachen Unterteilung beruhen, schalten Sie die grenzüberschreitenden Ideen aus, die die Innovation vorantreiben.

Die Geschwindigkeit der Entscheidungsfindung ist von größter Bedeutung. Einige Fragen sind dringend („Wir werden von einem anderen Stamm angegriffen und müssen uns dagegen verteidigen“), während andere, obwohl sie wichtig sind, längere Überlegungen zulassen oder sogar erfordern („Welcher Standort ist der beste für den neuen Sitzungssaal?“). Der Begriff Scherschichten beschreibt verwandte Prozesse, die sich mit unterschiedlichen Geschwindigkeiten bewegen, in Anlehnung an tektonische Platten, die sich übereinander schieben, wie z. B. im Vorfeld eines Erdbebens. Sowohl Gebäudearchitekten () als auch der Bereich der Softwarearchitektur (siehe ) haben den Begriff übernommen, um Strukturen oder Belange mit unterschiedlichen Änderungsgeschwindigkeiten in einem eng gekoppelten System zu beschreiben. Ein Unternehmen sollte seine Organisation so strukturieren, dass es in der Lage ist, schnell auf Probleme der ersten Kategorie zu reagieren, ohne seine Effektivität für Probleme der zweiten Kategorie zu zerstören.

Ein weiteres agiles Prinzip ist, dass wir nach außen gerichtet sind: Das heißt, unser Fokus und unsere Sorge gelten dem Endbenutzer, dem Markt und den Kunden und nicht den Werkzeugen und Technologien, die wir für unsere Arbeit verwenden. Die Organisation sollte dieses Anliegen ebenfalls widerspiegeln, da es der Schlüssel zum Wertangebot und zum Aufbau des gesamten Wertstroms der Entwicklung ist.

Letztendlich sollte die Struktur der Organisation genauso viel mit der Struktur des Prozesses zu tun haben wie mit der Struktur des Produkts.

Organisieren Sie daher die Belegschaft in kleinen Teams von mehr oder weniger fünf Personen, die nach den wichtigsten Anliegen für die Wertschöpfung des Unternehmens aufgeteilt sind. Ergänzen Sie diese Struktur mit einer kleinen Anzahl von Querschnittsstrukturen für sekundäre, aber wichtige Belange, wobei Sie nie vergessen dürfen, dass diese Strukturen nur Optimierungen in einem ansonsten offenen Umfeld der uneingeschränkten Zusammenarbeit sind.

Betrachten Sie ein Unternehmen, das ein Mobiltelefon baut. Sie könnten ihre Scrum-Teams um die wichtigsten Lieferobjekte oder kaufbaren Optionen herum organisieren. So gibt es vielleicht ein Team für das Adressbuch, ein anderes für den Kalender und ein weiteres für die eher traditionellen Telefonfunktionen: siehe Wertbereich. Dies sind die Hauptanliegen des Unternehmens. Es kann aber auch Gruppen geben, die zusammenkommen, um Praktiken, Richtlinien und Unternehmensstandards (z. B. das Erscheinungsbild der Benutzeroberfläche) zu definieren, und die sich aus Vertretern der einzelnen Scrum-Teams zusammensetzen. Diese Gruppen stellen keine Produkte her, sondern dienen dem Informationsaustausch und als Quelle für Standards, die die Entwicklung leiten. In gesunden Organisationen überschneiden sich die Mitglieder der letztgenannten Gruppen fast vollständig mit den Mitgliedern der Entwicklungsteams.

In den meisten Umgebungen spiegelt die primäre Organisationsstruktur die primäre Stakeholder-Struktur wider, die normalerweise der Markt ist. Aus diesem Grund organisieren wir Scrum-Teams nicht nach der Aufteilung interner Artefakte und auch nicht nach dem Ort der Domänenexpertise, sondern eher nach Marktleistungen wie Features. Die Organisation nach Features oder anderen Marktleistungen ist auch ein Segen für die Reaktionsfähigkeit auf den Markt und die Verkürzung der Markteinführungszeit, da das Team der Ort ist, an dem alle für die Implementierung eines Features erforderlichen Arbeiten durchgeführt werden. Dadurch bleibt die Koordination innerhalb einer organisatorischen Grenze. Wenn die Organisationsstruktur von Arbeitsuntergruppen oder Kernkompetenzen bestimmt wird, dann werden Änderungen auf dem Markt oder in der Art der zu liefernden Ergebnisse wahrscheinlich eine Koordinierung zwischen mehreren Teams oder Organisationen nach sich ziehen, was die Reaktionsfähigkeit verringert und die Entscheidungszeit erhöht.

Wenn dies die einzige Struktur ist, unterstützt sie nur die Marktsicht und lässt eine Vielzahl anderer berechtigter geschäftlicher Belange außer Acht. Damit diese Struktur funktioniert, muss sie durch bereichsübergreifende Strukturen ergänzt werden, die eine zweite Ebene der Kommunikationseffizienz unterstützen, z.B. solche, die mit den Kernkompetenzen zusammenhängen. Daher tritt dieses Muster fast immer zusammen mit einem Muster wie Birds of a Feather und dem in Domain Expertise in Roles beschriebenen Muster auf. Die organisatorische Rollenstruktur durchbricht die Mauern, die sich natürlicherweise zwischen Teams bilden. Das MetaScrum sorgt dafür, dass sich die Produktteams innerhalb eines Unternehmens untereinander und mit der Geschäftsleitung vernetzen. Teams, die ein gewisses Maß an Teamstolz entwickelt haben (siehe Teamstolz), werden effektiver sein, da diese oder eine andere gleichwertige Kraft die Verantwortung fördert. Dies trägt dazu bei, dass diese Strukturen trotz der fremdenfeindlichen Auswirkungen der Teammitgliedschaft erhalten bleiben.

Binden Sie alles zusammen mit einer offenen Umgebung ohne Wände und Türen. Entwicklungsteams sind nur Einheiten des Entwicklungsengagements, und es sollte keine Einmischung geben, die die freie Zusammenarbeit zwischen den Entwicklern in den Teams einschränkt. Fügen Sie kleine Räume in der Nähe für kurze Perioden der Ruhe, des ernsthaften Nachdenkens und für kleine Besprechungen hinzu.

Jede Komponente des Wertes ist ein faires Spiel als Ordnungskriterium. Scrum legt zum Beispiel großen Wert auf die Kollokation von Teammitgliedern, so dass die grundlegendsten organisatorischen Grenzen wahrscheinlich kollokierten Teams entsprechen.

✥ ✥ ✥

Beachten Sie, dass es in einem guten Scrum zwei Ebenen des Conway’schen Gesetzes gibt: eine, die durch den Fokus auf das Produkt angetrieben wird, und eine andere, die durch den Fokus auf Kompetenzbereiche angetrieben wird. Auf der oberflächlichen Ebene organisieren wir das Team nach dem Prozess; das ist das Hauptanliegen sowohl für die nach innen als auch nach außen gerichteten Aspekte des Prozesses. Die drei Sphären der Prozessherrschaft sind also:

• das Entwicklungsteam, das für die Entscheidungen über den geeigneten Einsatz von Technologie und Technik bei der Erstellung des Produkts verantwortlich ist;
• der Product Owner, der für die Definition und Ausrichtung des Produkts verantwortlich ist; und,
• der ScrumMaster, der dafür verantwortlich ist, dass der Prozess die regelmäßige Lieferung des Entwicklungsteams unterstützt.

Scrum-Entwicklungsteams sind Feature-(Produkt-)Teams. Das heißt, das primäre Organisationsprinzip eines Scrum-Teams ist, dass es sich an einem Zug von Feature-Lieferungen entlang eines Wertstroms ausrichtet. Es gibt eine schwache, flache hierarchische Organisation innerhalb von Scrum, die mehrere Entwicklungsteams innerhalb jeder Produktentwicklung beherbergt, die sich einen gemeinsamen Product Owner teilen, in einer Organisation, die Scrum of Scrums genannt wird. Jedes Entwicklungsteam innerhalb einer einzelnen Produktentwicklung baut jeweils eine Reihe von Funktionen auf. Im Laufe der Zeit werden diese Funktionen durch wichtige Geschäftsfaktoren, gemeinsames Geschäftswissen und Wertstromartefakte miteinander verbunden. Es gibt keine anerkannten Titel oder Unterabteilungen innerhalb des Entwicklungsteams.

Es gibt viele Möglichkeiten, die Arbeit in Feature-Teams aufzuteilen. Ein Entwicklungsteam kann Funktionen für einen bestimmten Markt liefern (siehe Organisation folgt dem Markt) oder ein Produkt für eine Teilmenge des Technologiespektrums des Unternehmens entwickeln (ein Team für Telefone und ein anderes für Tablets, obwohl beide einen Großteil der gleichen Software verwenden). Im Allgemeinen sollte jedes Team um ein Produkt herum gebildet werden, das eine Komponente des Unternehmenswertes ausmacht: siehe auch Wertstromgabel. Scrum rät jedoch von einer Entwicklungsteam-Struktur ab, bei der jedes Team nur einen Teil des Produkts oder nur eine Unterbaugruppe des Produkts besitzt. Wenn die Mitglieder eines einzelnen Teams nur einen Teil des Systems entwickeln können, müssen sie mehr Entwicklungsentscheidungen mit anderen Teams koordinieren. Es wird für die Teams schwierig, Entscheidungen auf lokaler Ebene zu treffen, und das Ergebnis sind verzögerte Rückmeldungen und Übergaben.

Auf der zweiten Ebene des Conway’schen Gesetzes innerhalb von Scrum organisieren sich die Mitarbeiter um Kompetenzbereiche, in denen ihre Fähigkeiten den Wert steigern. Diese „Birds of a Feather“ helfen den Mitgliedern, ihre Fähigkeiten in einem beruflichen oder technischen Bereich zu vertiefen, indem sie Ideen austauschen oder Schulungen besuchen. Die meisten Menschen haben einen angeborenen Wunsch, sich zu verbessern (siehe ), und diese Gruppen nähren den individuellen Stolz, während die Teammitglieder lernen und wachsen. Aber auch diese Gruppen bilden keine Berichtsstruktur, und jedes Teammitglied kann sowohl zu mehreren Birds of a Feather als auch zu seinem eigenen Scrum-Team gehören. Siehe auch Domain Expertise in Roles.

Die Grenzen und die Identität von Entwicklungsteams und Scrum Teams sind explizit. Der Begriff der Teamidentität ist der Schlüssel zum Teamstolz und zum effizienten Funktionieren der Organisation, da die Teamidentität den sozialen Kontext liefert, der zur Optimierung der Entscheidungsfindung beiträgt. Jede Vorstellung von organisatorischer Identität, die über diese beiden hinausgeht, sollte eher stillschweigend als explizit oder verwaltet sein. Auch innerhalb des Entwicklungsteams gibt es keine anderen formalen Titel als „Entwickler“. Wenn es nur eine unumstößliche Regel gibt, dann die, dass kein Einzelner seine stillschweigende Sachkenntnis dazu benutzen darf, einen Teamkonsens außer Kraft zu setzen oder auf irgendeine andere Weise den Geist der Teamarbeit zu beeinträchtigen, wie in The Spirit of the Game. Eine gemeinsam entwickelte Verhaltensnorm ist ein starker Vorbote für die Teamidentität.

Es kann Fachwissen in Rollen auf der individuellen Ebene geben, aber es ist wichtig, dieses Muster mit funktionsübergreifenden Teams zu vervollständigen, wo immer dies möglich ist, um die Möglichkeit der lokalen Entscheidungsfindung zu optimieren.

Das ursprüngliche Conway’s Law stammt aus der Softwarebranche (siehe , S. 28-31). Es gibt viele Mythen, die mit dem Ursprung und der Praxis von Conway’s Law verbunden sind. Lange Zeit wurde behauptet, dass die Objektorientierung das Conway’sche Gesetz unterstützt, indem sie Marktbelange innerhalb von Klassen lokalisiert. Das ist nur zur Hälfte wahr; Klassen neigen dazu, die langfristigen Belange der organisatorischen Kernkompetenz zu kapseln. Dennoch scheint sich die Objektorientierung eher auf die Verbindung zwischen dem Fachwissen der Entwickler und den von ihnen entwickelten Artefakten zu konzentrieren als auf eine Verbindung zum Markt oder zu Anwendungsfällen. Die Sorge um die Anpassung an die Marktstruktur sollte die Sorge um die Weltsicht der Entwickler über ihren Prozess und ihr Produkt übertrumpfen.

Der Wasserfallstil der Entwicklung hatte seine Blütezeit. In Wasserfall-Organisationen folgte die primäre Organisationsstruktur den Prozessstufen: Anforderungsanalyse, Design, Implementierung und Test (, S. 1-9). Gemäß dem Conway’schen Gesetz spiegelte die Organisationsstruktur diese Prozessbelange wider. Auch die Software könnte diese Phasen widerspiegeln: Eine serviceorientierte Architektur (SOA) weist beispielsweise die meisten Mehrwertanforderungen in der Dienstintegrationsschicht auf, während die einzelnen Dienste in einer anderen Schicht zu finden sind. Bei der Wasserfallmethode werden den Entwicklern alle Funktionen auf einmal in die Hand gegeben, was das Nachdenken über die Wechselwirkungen zwischen den Funktionen unterstützt. Während die Softwareentwicklungsansätze der Wasserfall-Ära versuchten, die Belange des Marktes (Anwendungsfälle) mit der Architektur in Einklang zu bringen, durchbrach die Organisationsstruktur diese Taxonomie. Dasselbe lässt sich über die Fließbandorganisation in Fabriken sagen.

Da Entwicklungsteams Feature-Teams sind, sollten sie sich auf jeweils ein Feature konzentrieren (wie bei Swarming). Die primäre Marktleistung von Scrum ist ein Feature, und in diesem Sinne besteht eine gute Übereinstimmung zwischen der Teamstruktur und dem Markt. Scrum schweigt sich über die Form der Produktarchitektur aus, aber im Sinne des agilen Ansatzes neigt es dazu, individuellem Codebesitz entgegenzuwirken. Jedes Entwicklungsteam hat die Lizenz, an jedem Teil des Produkts zu arbeiten. Wir können sagen, dass Scrum die organisatorischen Vorteile der Kapselung mit den Vorteilen der Ausrichtung des Teams auf die Marktleistung ausgleicht. Der Product Owner kümmert sich mit Unterstützung des Entwicklungsteams darum, wie mit den im Laufe der Zeit entstehenden Wechselwirkungen zwischen den Funktionen umgegangen wird.

Betrachten Sie zum Beispiel, dass ein Team die Funktion „Anklopfen“ für ein Telekommunikationssystem implementiert, während ein anderes die Anrufweiterleitung implementiert. Aufgrund der Emergenz können Sie die Kosten für die Lösung von Abhängigkeiten zwischen zwei bestimmten Product Backlog Items (PBIs) nicht immer vorhersehen, so dass es im Allgemeinen unmöglich ist, dieses Problem durch die Zuweisung von PBIs an Teams zu lösen. In jedem Fall kann eine verfrühte Zuweisung von Arbeit an Teams dazu führen, dass die Mitarbeiter nicht mehr effektiv an den schwierigen Teilen arbeiten können (insbesondere an denen, die mit der Interaktion zwischen den Teilen zusammenhängen) und die Selbstorganisation auf der Ebene des Scrum-Teams eingeschränkt wird. Die beiden Funktionen können in hohem Maße voneinander abhängig sein, aber die Scrum-Struktur gibt diesen Interaktionen keinen erstklassigen Stellenwert. In diesem Fall wäre es wahrscheinlich besser, wenn ein einziges Team beide Funktionen entwickeln würde. Die Aufteilung der Arbeit auf die Teams basiert auf einer kontinuierlichen Planung und gemeinsamen Entscheidungsfindung, beginnend mit der Sprint-Planung. Ein gutes Scrum-Team ist bestrebt, die Arbeit auf die Entwicklungsteams aufzuteilen, und zwar durch enge, aber zeitlich begrenzte Interaktionen zwischen dem Product Owner und dem Entwicklungsteam, wie z. B. bei Veranstaltungen zur kontinuierlichen Wiederherstellung eines verfeinerten Product Backlogs sowie durch die Sprint-Planung.

Management ist in der Regel ein Bestandteil des Organisationsmixes, obwohl es einige Scrum-Entwicklungen gibt, die ohne Manager ablaufen (siehe z. B. das aktuelle Video über die agile Transformation bei Bosch Software Innovations. ) Das Scrum-Ethos konzentriert sich tendenziell auf die Menschen und das Produkt, und dieser Fokus wird durch die Scrum-Rollen und die Organisationen (wie das Entwicklungsteam und das Product Owner Team), die sie repräsentieren, verkörpert. Wenn eine Organisation mit bereits existierenden Managern Scrum einführen will, ist es für die Scrum-Bemühungen zu einfach, den Managementteil der Organisation als weltfremd abzutun. In solchen Situationen, in denen eine managementfreie Organisation keine Option ist, ist es entscheidend, die Manager einzubeziehen.

Steven Johnson. Where Good Ideas Come From. New York: Riverhead Trade, 2011.

Stewart Brand. How Buildings Learn: What Happens After They’re Built. New York: Penguin, 1995.

Brian Foote und Joseph Yoder. „Big Ball of Mud.ˮ In Pattern Languages of Program Design 4, Brian Foote et al, eds. London: Pearson, 2000.

Daniel Pink. Drive: Die erstaunliche Wahrheit darüber, was uns motiviert. New York: Riverhead Books, 2011.

Melvin E. Conway. „How do committees invent?ˮ In Datamation 14(4), April, 1968, S. 28-31.

Dr. Winston W. Royce. „Managing the Development of Large Software Systems.“ In Proceedings IEEE WESCON, August 1970, S. 1-9. (Ursprünglich veröffentlicht von TRW.)

Bosch Software Innovations. „Lessons learned“: Agile Organisation bei Bosch Software Innovations.ˮ YouTube.com, 15 June 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Bildnachweis: Bilder zur Verfügung gestellt von PresenterMedia.com.