.NET Works: Autonome Software-Teams

Unterschiede zwischen führungsorientierten und autonomen Teams

Klassische Entwickler-Teams, die eingebettet in reglementierte Prozesse sind, im Bestfall einen Team- oder Abteilungsleiter haben, der teamorientierte Führung praktiziert und hierarchische sowie fachgebundende Strukturen aufweisen verkommen zu einer altbackenen und "muffig"-konservativen Arbeitsweise.

Das ist in meinen Augen auch gut so, denn die Erfahrung mit den klassischen Team-Strukturen hat gezeigt, dass es viele Probleme amit sich bringt, die vor Allem in der Software-Entwicklung Risikofaktoren nach sich ziehen, die nur sehr schwer in den Griff zu bekommen sind. Doch bevor ich detailliert auf diesen alternativen Ansatz der selbstreflektierenden Autonomie von Software-Teams eingehe, lohnt es sich, die allgemeinen Charakteristika von "klassischen" führungsgesteuerten Software-Teams mit den "alternativen" autonomen Software-Teams gegenüberzustellen:

Vergleich Teamstrukturen
Führungsorientierte Teams	Autonome Teams
Haben einen Team-Leiter, der Gesamt-Verantwortung trägt, Kommunikation im Team fördert und reglementiert, Prozesse etabliert und kontrolliert, Informationen zu anderen Teams / Abteilungen transportiert	Sind ohne Führung, tragen als Team die Gesamt-Verantwortung, kommunizieren und reglementieren selbstbestimmt
Sind durch Architekten, Senior Entwickler, Backend- / Frontend-Entwickler und sog. "Code-Maintainer" hierarchisch und fachgebunden organisiert	Haben meist keine Hierarchie, tauschen und rotieren frequentiv ihre Rollen im Team
Haben meist ein organisatorisch abgestuftes, nach Arbeitsbereichen strukturiertes, komplexes "Regelwerk" zur teaminternen und teamübergreifenden Arbeitsgestaltung (Coding Guidelines, Issue Tracking Prozesse, Project Roundtables, Jour-Fixe, Monatliche Reports, Lessons Learned)	Haben für Prozesse keine Regeln sondern lediglich einen Satz von "Empfehlungen", etablieren Kontrolle und Qualität durch Rückkopplungen, einigen sich selbstständig auf eine gemeinsame Arbeitsplattform durch "Manifeste"

Das ähnelt im ersten Blick eher nach einer Gegenüberstellung der Software-Entwicklungs-Paradigmen, wie z.B. Wasserfall vs. Agile. Doch es steckt noch mehr dahinter.