Agile TeamBildung (Teil 1) – Eine Frage der Kompetenz: Von spezialisierten Generalisten in interdisziplinären Scrum-Teams

Gerade einmal zarte 16 Seiten [1] waren und sind Ausgangspunkt für zahlreiche Veröffentlichungen, Forumsbeiträge, Diskussionen und Irrtümer in der agilen Szene [2]. Das mag neben der Begeisterung für die agile Softwareentwicklung auch daran liegen, dass der Scrum-Guide neben korrekten Antworten viele Fragen offen lässt und sich so auch Gerüchte in der agilen Szene verbreiten. Drei dieser Fragen bzw. Mythen gehen wir in einer dreiteiligen Blogserie auf die Spur.

Im ersten Teil thematisieren wir folgenden Mythos:

Scrum-Teammitglieder müssen Generalisten sein. Alle müssen alles können. Sonst wird das nichts mit dem erfolgreichen Projektabschluss.

Stimmt das? Wie ein Blick auf Seite 5 des Scrum-Guides beweist, kann hier nur ein klares Nein die Antwort sein:

„Scrum-Teams sind selbstorganisiert und interdisziplinär. […] Interdisziplinäre Teams verfügen über alle Kompetenzen, ihr Arbeitsergebnis zu erreichen, ohne dabei von anderen abhängig zu sein, die nicht Teil des Teams sind.“[3]

Auch Mike Cohn ist davon überzeugt, dass „ein gängiger Irrglaube [darin besteht], dass jedes Teammitglied eines Scrum-Teams ein Generalist sein müsste“. [4] Dieser Irrglaube ist laut Cohn ein hausgemachter der Softwarebranche. Er verdeutlicht das an einem Beispiel aus der Gastronomie. In einem Imbiss gibt es folgende Angestellte: Bediener, Sandwichzubereiter (beides Spezialisten) und Springer (Generalist). Als Generalist kann der Springer Aufgaben seiner spezialisierten Kollegen übernehmen. Er mag zur Erfüllung der Aufgaben mehr Zeit brauchen, doch er ist glücklicherweise überhaupt in der Lage, seinen Kollegen aushelfen.

Die Vermutung liegt nahe, dass sprachliche Ungenauigkeit die Wurzel des Generalistenanspruchs in der Softwarebranche ist. Somit ist eine kurze Begriffsklärung nötig.

Ein Generalist ist jemand, der in mehreren Gebieten über Kompetenzen verfügt.

Ein Spezialist hingegen verfügt über besondere Kenntnisse und Fähigkeiten auf einem Gebiet. [5]

Interdisziplinär meint, dass Menschen aus unterschiedlichen Teilbereichen mit unterschiedlichem Wissen zusammenarbeiten. Das können Mathematiker, Biologen oder Kunsthistoriker (allesamt Spezialisten auf ihrem Gebiet) sein. Genauso kann aber auch ein Absolvent eines dualen Studiengangs (Germanistik und Informatik), der nach seinem Studium in der Versicherungsbrache gearbeitet hat, als Generalist zu diesem Scrum-Team gehören.

Mit diesen Begriffsklärungen im Hinterkopf wenden wir uns noch einmal dem Scrum-Guide zu.

„Einzelne Mitglieder eines Entwicklungs-Teams können spezialisierte Fertigkeiten und Kenntnisse haben, die zu einer Fokussierung auf spezifische Arbeitsbereiche führen.“ [6]

Der Scrum-Guide kennt demnach die Spezialisierung einiger, jedoch nicht aller Teammitglieder. Dennoch

„liegt die Verantwortlichkeit für das Arbeitsergebnis beim Entwicklungs-Team als Ganzes [und eben nicht beim Einzelnen, Anm. d. Verf.].“ [7]

Im Vordergrund steht das Entwicklungsteam, das die Kompetenzen haben muss, um sein gemeinsames Sprintziel zu erreichen. Welche Kompetenzen das im Einzelfall sind, ist in Vorbereitung auf ein Projekt zu prüfen und jeweils für den Einzelfall festzulegen. Dieser Anspruch fordert das Entwicklungsteam gleichzeitig auf, während der Sprints über ihren eigenen Tellerrand zu schauen. Sie müssen ihr Wissen mit ihrem Team teilen sowie Wissensaustausch und Kommunikation im Team fördern.

Sucht man an dem Mythos, dass jeder im Scrum-Team ein Generalist sein müsse, das berühmte Fünkchen Wahrheit, könnte man es wie folgt formulieren: Ein interdisziplinäres Team sollte sich im Idealfall aus Generalisten und Spezialisten zusammensetzen, die es gemeinsam schaffen, das Sprintziel zu erreichen. [8]

Im Idealfall warten Sie gespannt auf den nächsten Blogeintrag dieser Serie. In der Zwischenzeit freuen wir uns, wenn Sie Ihre Erfahrungen bezüglich Spezialisten und Generalisten in Scrum mit uns teilen.

 

———————————————–

Quellen:
[1] Richtig, die Rede ist vom Scrum-Guide.

[2] Einen Einblick in agile Vorgehen, u. a. Scrum, finden Sie in der neuen Auflage unseres Bestsellers: Requirements Engineering und -Management. Aus der Praxis von klassisch bis agil. Hanser 2014.

[3] https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf. (02.07.2014). S. 5.

[4] Cohn, Mike (2010): Agile Softwareentwicklung. Mit Scrum zum Erfolg. S. 234f.

[5] Vgl. http://www.duden.de/rechtschreibung/Spezialist, http://www.duden.de/rechtschreibung/Generalist

[6] https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20DE.pdf. (02.07.2014). S.6.

[7] Ebd.

[8] Vgl. u. a. Arndt, Nils (2013): Der agile Architekt. http://entwickler.de/artikel/Der-agile-Architekt. (02.07.2014)., Roock, Arne und Roock, Stefan: Wie cross-funktional sollte mein Team sein? http://stefanroock.files.wordpress.com/2013/08/crossfunktionaleteams_roocks.pdf (02.07.2014). S. 2., http://alphanodes.de/scrum-team-mitglied

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


× eins = 4

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>