Das Wissensportal für IT-Professionals. Entdecke die Tiefe und Breite unseres IT-Contents in exklusiven Themenchannels und Magazinmarken.

SIGS DATACOM GmbH

Lindlaustraße 2c, 53842 Troisdorf

Tel: +49 (0)2241/2341-100

kundenservice@sigs-datacom.de

Eine nachhaltige Verbesserung

Softwarequalität ist längst nicht mehr die Verantwortung eines dedizierten Teams. Ganz im Gegenteil lässt sich Qualität als Gemeinschaftsaufgabe definieren. Um diese Veränderung in der Organisation zu verankern, ist ein Umdenken entscheidend. Anstelle vertikaler, siloartiger Organisationsstrukturen rücken cross-funktionale Teamstrukturen in den Fokus. Nur mit der Ende-zu-Ende-Verantwortung eines Teams für eine Funktionalität gelingt es, die Softwarequalität nachhaltig zu steigern.
Author Image
Niklas Kirfel

Author


  • 27.11.2020
  • Lesezeit: 10 Minuten
  • 19 Views

Software ist integraler Bestandteil unseres Lebens. Selbst klassische, industrielle Produkte sind inzwischen mit integrierter Software ausgerüstet. Der Wertschöpfungsprozess jedes Unternehmens ist maßgeblich durch Software bestimmt. Nicht grundlos artikuliert Microsofts CEO Satya Nadella: „Every company is a software company“ [Mic18]. Doch die Art und Weise, wie Organisationen weltweit Software produzieren, variiert signifikant. Das hat unmittelbare Auswirkung auf die Softwarequalität.

Doch welche Charakteristika kennzeichnen eine bewährte Softwareorganisation und welche Elemente bieten neue Gestaltungsoptionen im Rahmen einer kundenzentrierten Organisation? Ein traditionelles, weitverbreitetes Muster ist eine funktionale Organisation der Softwareentwicklung. Im Sprachgebrauch wird bei dieser Aufstellung häufig von vertikalen Silos gesprochen (siehe Abbildung 1). Die Arbeitsorganisation erfolgt anhand des Aufgabenschwerpunkts eines Mitarbeiters. Mitarbeiter mit dem gleichen Aufgabenschwerpunkt bilden ein homogenes Team. Die Teams werden entlang des klassischen Wertschöpfungsprozesses der Softwareentwicklung, beginnend mit dem Anforderungsmanagement bis hin zum Betrieb und Service-Management, in der logischen Reihenfolge angeordnet.

Abb. 1: Arbeitsteilige, funktionale Softwareentwicklungsorganisation

Durch Homogenität und eine sequenzielle Arbeitsweise entstehen in sich geschlossene Systeme. Die Schnittstellen zum vor- und nachgelagerten Wertschöpfungsschritt werden verwaltet. Eine systemische Betrachtung des gesamten Wertschöpfungsprozesses entfällt hingegen für gewöhnlich. Folglich wird häufig ein Testmanagementoder Qualitätssicherungsteam mit der Verantwortung für die Qualität der bereitgestellten Software betraut. Es allein übernimmt die Verantwortung für eine Gemeinschaftsaufgabe, an der eine Vielzahl weiterer Beteiligter partizipiert.

Im Kontrast zu dem arbeitsteiligen, klassischen Vorgehen steht die Organisation der Softwareentwicklung entlang eines horizontalen Wertflusses in sogenannten Feature-Teams. Alle Mitarbeiter, die an der Wertschöpfung einer Funktionalität beteiligt sind, formen ein Team. Dieses ist folglich durch Interdisziplinarität gekennzeichnet. Es übernimmt die Ende-zu-Ende-Verantwortung für den Erfolg oder Misserfolg der Funktionalität.

Charakteristika eines erfolgreichen Feature-Teams

Doch welche Eigenschaften kennzeichnen ein erfolgreiches Feature-Team? Anhand von zehn charakterisierenden Attributen lässt sich dies kompakt beschreiben (siehe Abbildung 2).

Abb. 2: Cross-funktionale Feature-Teams

Verantwortlich

Unter Ende-zu-Ende-Verantwortung versteht der Autor das Zusammenführen von Teilverantwortungen ehemals funktional getrennter Teams zu einem gemeinsamen Team, welches die Gesamtverantwortung für eine Software trägt.
Die Übernahme von Ende-zu-Ende-Verantwortung mit dem übergeordneten Ziel der Qualitätssteigerung setzt ein systemisches Denken voraus. Ein Vorreiter des systemischen Managementansatzes ist William E. Deming, der eine Organisation als System und damit als gesamtheitlichen Organismus versteht. Aus diesem Verständnis lässt sich ableiten, dass das Optimieren einzelner, funktionaler Silos niemals zu dem Gesamtoptimum des Systems führt. Es führt lediglich zu partiellen Verbesserungen.

In der Praxis ist es besonders herausfordernd, dass bislang vielerorts im funktionalen Maßstab gehandelt wird, sodass ein radikales Umdenken notwendig ist. Ein System und damit die Qualität seiner Erzeugnisse lässt sich schließlich nur dann optimieren, wenn wahrlich gesamtheitlich gehandelt wird und keine funktionalen Organisationsbarrieren einem systemischen Management im Wege stehen. Ein Feature-Team übernimmt die Verantwortung und setzt sich für die gesamtheitliche Systemverbesserung ein.

Divers

Inzwischen ist es eine anerkannte Tatsache, dass diverse, interdisziplinäre Teams die besseren Teams sind. Dabei entsteht die Vielseitigkeit des Teams in vielerlei Dimensionen. Zunächst sind hierbei die personenbezogenen Attribute, wie das Alter und das Geschlecht, zu nennen.

Interdisziplinär

Darüber hinaus ist ein diverses Team nachweislich leistungsstärker, wenn es zusätzlich über eine vielseitige Wissensbasis verfügt. Liang et al. haben diesen Performanzeffekt in Softwareprojekten empirisch nachgewiesen [Lia07]. Folglich ist in Feature-Teams die Diversität auch im Hinblick auf das jeweilige Fachgebiet ein Erfolgsfaktor. Die Zusammenarbeit von Experten mehrerer Disziplinen ist äußerst ratsam. Schließlich sind Feature-Teams in der Softwareentwicklung mit komplexen Herausforderungen betraut. Hierfür ist ein kreativer Problemlösungsansatz zu wählen, der die Expertise aus zahlreichen Disziplinen erfordert.

Cross - funktional

Ein entscheidender Vorteil hierbei ist, dass die einzig wahre Übergabe (engl. handover) zwischen dem Feature-Team und dem Kunden stattfindet. Übergaben zwischen funktionalen Silos und damit potenzielle Nadelöhre (engl. bottlenecks) und Risiken entfallen. Dies minimiert die Gefahr, im Rahmen unternehmensinterner Übergaben Qualitätseinbußen zu verursachen. Auslöser hierfür können beispielsweise eine unzureichende Kommunikation, eine wenig ausgeprägte Zusammenarbeitskultur oder unabgestimmte Zielparameter und -vereinbarungen sein.

Das cross-funktionale Team hingegen verantwortet die Software entlang des gesamten Produktlebenszyklus. Es inkludiert sämtliche notwendigen Fähigkeiten, um das gewünschte Produkt zu entwickeln. Im Idealzustand sitzen metaphorisch gesprochen Anforderungsmanager, Architekten, Softwareentwickler, Testmanager, Operations Engineers, IT-Service-Manager und weitere erforderliche Rollen im gleichen Boot. Sie bilden ein Team (siehe Abbildung 3) mit der Ambition, den Kunden zu begeistern. Denn nur daran wird das Team gemessen.

Abb. 3: Zehn Charakteristika eines erfolgreichen Feature-Teams

Jedoch erweist sich Cross-Funktionalität in der Realität oftmals als herausfordernd. Gewisse Fachexperten stehen womöglich nicht in ausreichender Anzahl je Team zur Verfügung, sodass alternative Kollaborationsmöglichkeiten zu formen sind. Ihr Know-how muss anteilsmäßig mehreren Teams parallel zur Verfügung stehen, womit die Aufgabenverteilung für diese Fachexperten geschäftskritisch ist.

Kundenzentriert

Ein signifikanter Vorteil der Organisation in Feature-Teams ist die explizite Ausrichtung am Endkunden. Schließlich beginnt die Wertschöpfung initial mit der Anforderungserhebung des Kunden und erstreckt sich bis hin zu einem Release und dem anschließenden Betrieb der Software. Eine qualitativ hochwertige Entwicklung ist durch die enge und kontinuierliche Einbindung des Endkunden sichergestellt.
Diese (Neu-)Ausrichtung am Kunden wird jedoch aus unterschiedlichsten Gründen nicht allen Feature-Teams gelingen. In diesen Fällen ist über stellvertretende Lösungen wie die Repräsentation durch einen Product Owner nachzudenken.

Qualitätsbewusst

Um das Bewusstsein für Qualität nachhaltig aufrechtzuerhalten, empfiehlt sich die bewusste Anpassung des Zielsystems. Ehemals galten für die funktionalen Silos Teamziele, die ein lokales Optimum erzeugten. Diese sind im Rahmen einer Organisation entlang von Wertströmen anzupassen. Dabei ist eine Akzentuierung von kundenzentrierten Parametern ratsam. Dazu zählen insbesondere die Kundenzufriedenheit und die Kundenbindung (engl. customer retention). Diese drücken die wahrgenommene Qualität aus Sicht des Kunden aus und entscheiden über den Markterfolg der Software. Damit sind kundenzentrierte Kennzahlen erfolgsentscheidender als die technischen Key Performance Indicators zur Qualität der Software.

Autonom

Eine Herausforderung bei der Gestaltung von Feature-Teams stellt deren Freiheitsgrad dar. Aufgrund manifestierter Hierarchien und Machtstrukturen in Organisationen ist es ein komplexes Unterfangen, weitestgehend autonome Feature-Teams zu formen. Die Autonomie eines Feature-Teams sorgt derweil für zweierlei Vorteile. Zuerst ist hervorzuheben, dass Entscheidungen stets in dem Personenkreis getroffen werden, der sich mit der Problemstellung am besten auskennt und daher die Implikationen der Entscheidung am treffendsten überblicken kann.

Motiviert

Ferner steigt mit der Übernahme von Entscheidungsverantwortung in der Regel auch das Maß an Motivation. In wenigen Fällen wird Eigenverantwortung zwar auch als Last und Bürde wahrgenommen, jedoch handelt es sich de facto um die Aufwertung der eigenen Rolle, was von einer Vielzahl an Mitarbeitern als ausgesprochen positiv und motivierend bewertet wird. Schließlich ist das Team für sämtliche Entwicklungen eigenverantwortlich und steckt entsprechend viel Engagement in die optimale Entwicklung der eigenen Lösung. Es herrscht eine ausgeprägte Identifikation des Feature-Teams mit ihrem eigenen Produkt.

Wissenshungrig

Im Rahmen des intensiven Wissensaustauschs innerhalb eines Feature-Teams besteht die Ambition, die Teammitglieder langfristig zu sogenannten „T-shaped-Knowhow-Trägern“ zu entwickeln. Die waagerechte Linie des Buchstabens „T“ symbolisiert das breit aufgestellte Wissen in einer Vielzahl an angrenzenden Fachgebieten, während die senkrechte Linie die tiefgreifende Expertise in dem persönlichen Spezialgebiet abbildet. Insbesondere die horizontale Achse profitiert von dem Wissensaustausch im Feature-Team, sodass langfristig Generalisten ausgebildet werden, die notfalls einen ausfallenden Kollegen kompensieren können.

Unternehmerisch

Aus diesem Grund lässt sich ein Feature-Team in gewisser Weise als Unternehmen im Unternehmen charakterisieren. Die Teammitglieder treffen Entscheidungen, die für den Fortbestand der Software von existenzieller Bedeutung sind. In der Konsequenz daraus resultiert unmittelbar auch der betriebswirtschaftliche Erfolg. Die unternehmerische Gewinnerzielungsabsicht dient dabei als geeigneter Gradmesser. Einem Feature-Team sollte es entsprechend gelingen, mithilfe ihrer entwickelten Software ein langfristig rentables Geschäft aufzubauen, dessen Erfolg anhand von Finanzkennzahlen nachweisbar ist. Dies gilt im Erfolgsfall. Umgekehrt ist das Feature-Team unmittelbar für den Misserfolg und das Scheitern eines Service verantwortlich und muss im Zweifel die eigenen Versäumnisse aufarbeiten.

Weitere organisatorische Verbesserungsmaßnahmen

Doch im Zuge einer umfassenden Transformation gilt es, Herausforderungen des Changemanagements nicht außer acht zu lassen.

Die Veränderung, fortan in Wertströmen anstelle in funktionalen Verantwortungsbereichen zu denken und handeln, kommt einer Zeitenwende gleich. Vieles, was bisher als selbstverständlich angesehen wurde, wird durch die neue Ausrichtung obsolet. Ein solch gravierender Eingriff in die bisherige Organisation und Ordnung bedeutet eine massive Veränderung für jeden Mitarbeiter. Es bedarf Zeit und Muße, sich der neuen Philosophie anzupassen und Hürden der Transformation zu überspringen.

Weiterhin ist die Ausgangssituation für die Reorganisation entscheidend. Hierbei lässt sich zwischen einem Greenfield- und einem Brownfield-Ansatz differenzieren. Während die grüne Wiese die perfekte Möglichkeit bietet, die Funktionalität, die Architektur und damit auch das Feature-Team zu gestalten, so steigt der Komplexitätsgrad der Transformation bei einem Brownfield-Ansatz. Die Etablierung von Feature-Teams muss in Einklang mit der bestehenden Organisation und Prozess- und IT-Landschaft geschehen, wodurch diverse Abhängigkeiten und Herausforderungen vorbestimmt sind.

Doch ganz gleich, welche Herausforderungen die Transformation begleiten und ob der Greenfield- oder Brownfield-Ansatz verfolgt wird: Die Transformation zu autonomen und kundenzentrierten Feature-Teams mit Ende-zu-Ende-Verantwortung ist erstrebenswert. Sie sind anpassungsfähig und flexibel und liefern nicht zuletzt qualitativ hochwertige Software aus. Der Kunde wird dies honorieren.

Referenzen

[Lia07]
T.-P. Liang et al., Effect of team diversity on software project performance, in: Industrial Management & Data Systems, 2007, Vol. 107, No. 5, pp. 636 ff., siehe:
https://www.researchgate.net/profile/Ting-Peng_Liang/publication/220672188_Effect_of_team_diversity_on_software_project_performance/links/09e4150ae64316ccb4000000.pdf

[Mic18]
Microsoft Inc., Microsoft CEO Satya Nadella on fueling ‘tech intensity’ in the UK, 2018, siehe:
https://news.microsoft.com/en-gb/2018/11/07/microsoft-ceo-satya-nadella-on-fuelling-tech-intensity-in-the-uk/

. . .

Author Image

Niklas Kirfel

Author
Zu Inhalten
ist Senior Consultant bei der Cassini Consulting AG. Als zertifizierter SAFe Program Consultant gestaltet er agile Organisations-, Transformations- und Softwareprojekte seiner Klienten.

Artikel teilen

Nächster Artikel
Sammlung von Meta-Papers