Team Topologies (eBook)

Organisation von Business- und IT-Teams für einen schnellen Arbeitsfluss. Inkl. Interaktionen in verteilten Teams - Workbook. Team-Topologies-Patterns für eine produktivere Zusammenarbeit

Matthew Skelton, Manuel Pais (Autoren)

eBook Download: EPUB

2023 | 1. Auflage
323 Seiten
dpunkt (Verlag)
978-3-96010-837-5 (ISBN)

Infos

Mit gut geplanten Teamstrukturen die Softwareentwicklung nachhaltig beschleunigen - International richtungsweisende Methode, um leistungsfähige Teams zu formen - Anwendbares Praxiswissen: Wie Sie funktionierende Teamgrenzen bestimmen und Team-APIs entwerfen - Kombiband: Enthält neben dem Hauptwerk »Team Topologies« das Workbook zur Interaktion verteilt arbeitender Teams. Effektive Softwareteams sind für jedes Unternehmen unerlässlich, um kontinuierlich und nachhaltig Werte zu schaffen.  Team Topologies ist ein praktisches, schrittweise anpassbares Modell für die Gestaltung von Organisationen und die Interaktion von Teams. Es basiert auf vier Teamtypen und drei Formen der Teaminteraktion und versteht Teams als entscheidenden Faktor der Wertschöpfung. Mit der technologischen und organisatorischen Reife einer Organisation werden sich Teamstrukturen und Kommunikationswege kontinuierlich weiterentwickeln. Im Bestseller Team Topologies präsentieren die IT-Berater Matthew Skelton und Manuel Pais eine grundlegende Weiterentwicklung des Organisationsdesigns für die Entwicklung von Software. Anhand von Fallstudien und Beispielen aus der Industrie beschreiben sie eine klar definierte Vorgehensweise für die Interaktion und das Zusammenwirken von Teams. Ihre Methode trägt entscheidend dazu bei, die Architektur von Software klarer und nachhaltiger zu gestalten und Probleme zwischen Teams in wertvolle Signale für eine sich selbst lenkende Organisation zu verwandeln. - Verstehen Sie das Conway'sche Gesetz und seine Bedeutung - Vereinfachen Sie mit vier Teamtypen die Organisation moderner Softwareteams - Gestalten Sie Teamgrenzen - und -APIs und reduzieren Sie die kognitive Belastung Ihrer Entwicklungsteams - Verbessern Sie durch drei Formen der Interaktion die Bereitstellung von Software - Nutzen Sie den Betrieb der Software als sensorischen Input zur Selbststeuerung Ihrer Organisation

Matthew Skelton entwickelt, implementiert und betreibt seit 1998 kommerzielle Software-Systeme und hat für Unternehmen wie die London Stock Exchange, GlaxoSmithKline, FT.com, LexisNexis und die britische Regierung gearbeitet. Matthew ist Head of Consulting bei Conflux (confluxdigital.net) und Co-Autor der Bücher Continuous Delivery with Windows and .NET (2016) und Team Guide to Software Operability (2016). Matthew hat einen BSc in Computerwissenschaften und Kybernetik von der University of Reading, einen MSc in Neurowissenschaften von der University of Oxford und einen MA in Musik von der Open University. Er ist ein Chartered Engineer (CEng) in Großbritannien. In seiner Freizeit spielt Matthew Trompete, singt in Chören, schreibt Musik und genießt das Trailrunning.Manuel Pais ist ein unabhängiger DevOps- und Continuous Delivery-Berater, der sich auf Team-Design, Praktiken und Arbeitsfluss konzentriert. Er hilft Organisationen bei der Definition und Einführung von DevOps und Continuous Delivery (sowohl aus technischer als auch aus menschlicher Sicht) durch strategische Bewertungen, praktische Workshops und Coaching. Manuel ist Co-Autor von Team Guide to Software Releasability (2018).

Textauszug

1

Das Problem mit Organisationsdiagrammen

Organisationen sollten als komplexe und anpassungsfähige Organismen und nicht als mechanistische und lineare Systeme betrachtet werden.

– Naomi Stanford, Guide to Organisation Design

Mitarbeiterinnen und Mitarbeiter im Technologiebereich sind ständig in Aktion: Sie erstellen und aktualisieren Systeme in einem unglaublichen Tempo und kombinieren verschiedene Arten von Technologien, um ein überzeugendes Benutzererlebnis zu schaffen. Mobile Anwendungen, Cloud-basierte Dienste, Webanwendungen und eingebettete, tragbare oder industrielle IoT-Geräte müssen alle effektiv zusammenarbeiten, um die gewünschten Geschäftsergebnisse zu erzielen.

Heutzutage beeinflussen diese Systeme fast jeden Aspekt unseres täglichen Lebens in einer Weise, die immer tiefgreifender ist. Wenn Software schlecht konzipiert ist – oder noch wichtiger, wenn die Interaktion zwischen der Software, dem Anbieter und den Kunden nicht übereinstimmt –, hat das negative Auswirkungen auf die Menschen. Sie können weit weg von zu Hause gestrandet sein, wenn eine Anwendung für Taxidienste ausfällt. Sie können möglicherweise ihre Miete nicht mehr bezahlen, wenn die Software oder die Prozesse für das Internetbanking ausfallen. Sie können sogar ihr Leben in Gefahr sehen, wenn ein medizinisches Gerät ausfällt. Noch nie war explizites sozio-technisches Design so wichtig wie heute.

Entwicklung und Betrieb dieser hochkomplexen, miteinander vernetzten Softwaresysteme sind Teamaktivitäten, die die gemeinsamen Anstrengungen von Menschen mit unterschiedlichen Fähigkeiten über verschiedene Plattformen hinweg erfordern. Darüber hinaus müssen moderne IT-Organisationen Softwaresysteme schnell und sicher bereitstellen und betreiben, während sie gleichzeitig wachsen und sich an Veränderungen und Zwänge im geschäftlichen oder gesetzlichen Umfeld anpassen müssen. Unternehmen können nicht mehr zwischen einer Optimierung der Stabilität und einer Optimierung der Geschwindigkeit wählen.

Doch trotz dieser Risiken und Anforderungen organisieren viele Unternehmen ihre Mitarbeiter und Teams immer noch auf eine Weise, die für die moderne Softwareentwicklung und den Betrieb kontraproduktiv ist. Unternehmen, die sich zu sehr auf Organigramme und Matrixstrukturen verlassen, um die Arbeit aufzuteilen und zu kontrollieren, schaffen oft nicht die notwendigen Voraussetzungen, um Innovationen zu fördern und gleichzeitig ein hohes Arbeitstempo zu erreichen. Um dies zu realisieren, brauchen Unternehmen stabile Teams, effektive Teamstrukturen und -interaktionen. Sie müssen in fähige, kompetente Teams investieren, die die Grundlage für Agilität und Anpassungsfähigkeit bilden. Um in einem immer härter umkämpften Markt bestehen zu können, brauchen Unternehmen Teams und Mitarbeiterinnen und Mitarbeiter, die in der Lage sind, zu erkennen, wann sich das Umfeld ändert, um sich entsprechend weiterzuentwickeln.

Die gute Nachricht ist, dass es möglich ist, gleichzeitig schnell und sicher zu sein – mit der richtigen Einstellung und mit Tools, die sowohl Anpassungsfähigkeit als auch Wiederholbarkeit fördern und die Teams und Menschen in den Mittelpunkt stellen. Wie Mark Schwartz und seine Mitautoren in ihrem 2016 erschienenen Buch Thinking Environments schreiben, »muss die Organisationsstruktur die Verantwortlichkeiten so koordinieren, dass das Ziel, qualitativ hochwertige und wirkungsvolle Software zu liefern, unterstützt wird.«1

Als Mitglieder der Technologieteams, die diese Schnittstellen betreuen, müssen wir unser Denken ändern. Wir müssen Teams nicht mehr als Ansammlung austauschbarer Individuen betrachten, die erfolgreich sind, solange sie den »richtigen« Prozess befolgen und die »richtigen« Werkzeuge verwenden, sondern wir müssen Menschen und Technologie als ein einziges sozio-technisches Mensch-Computer/ Kohlenstoff-Silizium-Ökosystem betrachten. Gleichzeitig müssen wir sicherstellen, dass die Teams intrinsisch motiviert sind und eine echte Chance haben, in einem solchen Gefüge ihre beste Arbeit zu leisten.

In diesem Kapitel wird Team Topologies als ein anpassungsfähiges Modell für die Gestaltung von Technologieorganisationen vorgestellt, mit dem Unternehmen Geschwindigkeit und Stabilität gleichermaßen erreichen können. Doch zunächst wollen wir uns ansehen, wie sich die realen Kommunikationsstrukturen in den meisten Organisationen oft von dem unterscheiden, was uns das Organigramm verrät, und welche Auswirkungen das hat.

Kommunikationsstrukturen einer Organisation

Die meisten Unternehmen möchten oder müssen eine genormte Sicht auf ihre Teams und Mitarbeiter haben, das sogenannte »Organigramm«. In diesem Diagramm werden die Teams, Abteilungen, Referate und andere Organisationseinheiten sowie ihre Beziehungen zueinander dargestellt. Es zeigt in der Regel hierarchische Berichtslinien, die Kommunikationswege »von oben nach unten« in der Organisation implizieren.

Das Organigramm hat im Zusammenhang mit der Entwicklung von Softwaresystemen durchaus seine Berechtigung, insbesondere im Hinblick auf die Einhaltung von Vorschriften und gesetzlichen Bestimmungen. In einem hochgradig kollaborativen Kontext mit Ungewissheit über die Resultate führt es jedoch zu unrealistischen Erwartungshaltungen, wenn man sich auf das Organigramm als zentralen Mechanismus für das Aufteilen der zu erledigenden Arbeit verlässt. Wir müssen uns stattdessen auf entkoppelte, langlebige Teams verlassen, die effektiv zusammenarbeiten können, um die Herausforderung zu meistern, ein Gleichgewicht zwischen Geschwindigkeit und Verlässlichkeit herzustellen.

Das Problem, wenn wir das Organigramm für bare Münze nehmen, besteht darin, dass wir versuchen, Menschen so zu strukturieren, als wären sie eine Software, die ihre Kommunikation ordentlich innerhalb der vorgegebenen Leitlinien hält. Aber die Menschen beschränken ihre Kommunikation nicht nur auf die Linien im Organigramm. Wir wenden uns an diejenigen, auf die wir angewiesen sind, um unsere Arbeit zu erledigen. Wir weichen die Regeln auf, wenn es nötig ist, um unsere Ziele zu erreichen. Deshalb sehen die tatsächlichen Kommunikationslinien ganz anders aus als im Organigramm, wie in Abbildung 1-1 dargestellt.

Das Denken in Organigrammen ist das Problem

Wie in Abbildung 1-1 dargestellt, helfen uns herkömmliche Organigramme nicht beim Verständnis der tatsächlichen Kommunikationsmuster in unserer Organisation. Stattdessen müssen Unternehmen ein realistischeres Bild von der erwarteten und der tatsächlich stattfindenden Kommunikation zwischen Einzelpersonen und Teams entwickeln. Diese Diskrepanzen geben Aufschluss darüber, welche Arten von Systemen für das Unternehmen besser geeignet sind.

Darüber hinaus neigen Entscheidungen, die auf der Struktur von Organigrammen basieren, dazu, nur für einen Teil des Unternehmens zu optimieren und die vor- und nachgelagerten Auswirkungen zu ignorieren. Lokale Optimierungen helfen den direkt involvierten Teams, aber sie tragen nicht unbedingt dazu bei, die Wertschöpfung für die Kunden insgesamt zu verbessern. Ihre Auswirkungen sind möglicherweise vernachlässigbar, wenn es größere Engpässe im Arbeitsablauf gibt. Wenn beispielsweise Teams Cloud as Code und Infrastructure as Code einsetzen, kann sich die Zeit für die Bereitstellung einer neuen Infrastruktur von Wochen oder Monaten auf Minuten oder Stunden verkürzen. Wenn jedoch jede Änderung von einem Gremium, das sich einmal pro Woche trifft, genehmigt werden muss, dann wird die Geschwindigkeit der Bereitstellung bestenfalls wöchentlich sein.

Systems Thinking konzentriert sich darauf, ganzheitlich zu optimieren, den gesamten Arbeitsfluss zu betrachten, festzustellen, was heute der größte Engpass ist, und ihn zu beseitigen. Dann wiederholen Sie das. Team Topologies konzentriert sich darauf, wie man dynamische Teamstrukturen und Interaktionsmodi einrichtet, die den Teams helfen, sich schnell an neue Bedingungen anzupassen und eine schnelle und sichere Softwareauslieferung zu erreichen. Vielleicht ist das heute noch nicht Ihr größter Engpass, aber irgendwann werden Sie mit dem Problem starrer Teamstrukturen mit schlechter Kommunikation und/oder unzureichenden Prozessen konfrontiert sein, die die Auslieferung verlangsamen.

Abbildung 1-1: Organigramm mit tatsächlichen Kommunikationslinien

In der Praxis kommunizieren Menschen seitwärts oder »horizontal« mit Menschen aus anderen Berichtslinien, um ihre Arbeit zu erledigen. Diese Kreativität und Problemlösungsfähigkeit müssen zum Wohle des Unternehmens gefördert werden und dürfen nicht darauf beschränkt sein, die Kommunikation und das Berichtswesen von oben nach unten und von unten nach oben zu optimieren.

Die...

Produkt-Details

• Erscheint lt. Verlag: 28.11.2023
• Übersetzer: Michael Plöd
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Software Entwicklung
• Schlagworte: Conway’s Law • DevOps • Kognitive Belastung • Monolithen • Softwarearchitektur • Team-APIs • Teamgrenzen • Team-Kommunikation • Teams
• ISBN-10: 3-96010-837-0 / 3960108370
• ISBN-13: 978-3-96010-837-5 / 9783960108375