Entwicklungsteam

Was macht ein Entwicklungsteam und wo liegen die Unterschiede von Entwicklungsteams in V-Modell XT und Scrum?

Wissen kompakt: Ein Entwicklungsteam implementiert als Gruppe von Menschen gemeinschaftlich ein Produkt. Je nach Vorgehen (bspw. Scrum oder V-Modell XT) variiert die Arbeitsweise.

Die gemeinschaftliche Implementierung von Software, Produkten oder Dienstleistungen

Ein Entwicklungsteam ist eine Gruppe von Menschen, die gemeinschaftlich eine Software, ein Produkt, in machen Fällen auch eine Dienstleistung implementiert.

Oftmals bestehen Entwicklungsteams aus Mitarbeiterinnen und Mitarbeitern eines Unternehmens. Handelt es sich um Kooperationen oder Joint Ventures können sie auch aus unterschiedlichen Organisationen stammen.

Wie ein Entwicklungsteam strukturiert ist und wie es miteinander arbeitet, ist kontextabhängig. Manche Organisation wählen sogenannte „reichhaltige“ Vorgehensmodelle wie bspw. das V-Modell XT, andere nutzen kleinere, agilere Frameworks wie bspw. Scrum, und dritte kombinieren Methoden, Vorgehensmodelle oder Workflows zu hybriden Arbeitsweisen. Kurzum: Organisation müssen sich entscheiden, welches Vorgehen und damit einhergehend auch welches Mindset zu Ihrer Entwicklung und ihrem Entwicklungsteam passt. 

Entwicklungsteam - verschiedene Ansätze je nach Vorgehensweise

Das Entwicklungsteam im V-Modell XT

Das V-Modell XT definiert zahlreiche Rollen innerhalb einer Entwicklung wie bspw.

  • Hardware-Architekt, Hardware-Entwickler, Software-Architekt und Software-Entwickler,
  • Konfigurationsmanagement-Administrator und Konfigurationsmanagement-Verantwortlicher,
  • Logistikentwickler, System-Architekt, System-Integrator und Prüfer.

Für jede Rolle gibt es eine formale Rollenbeschreibung, die maximal fünf Punkte umfasst:

  • Aufgaben und Befugnisse,
  • Fähigkeitsprofil,
  • Rollenbesetzung,
  • Verantwortlichkeit und
  • Mitwirkung.

Damit auch kleinere Projekte und Entwicklungen mit dem V-Modell XT durchgeführt werden können, dürfen Mitarbeiter auch mehr als eine Rolle übernehmen, sofern es keinen Interessenkonflikt gibt.

 

Das Entwicklungsteam in Scrum

Scrum hingegen verzichtet schon lange auf die Unterscheidung von Rollen im Entwicklungsteam. Der Scrum Guide 2020 geht sogar noch einen Schritt weiter und ersetzt den Begriff der Rolle durch Accountability (Verantwortlichkeit). Die Accountabilitys teilen sich in drei Gruppen:

  • Scrum Master,
  • Product Owner und
  • Developer (Entwickler).

Anstelle von Entwicklungsteam wird also „nur noch“ von Entwicklern gesprochen. Der Gedanke dahinter: es geht bei den Bezeichnungen in Scrum nicht um Stellenbeschreibungen, sondern um ein Minimum an Verantwortlichkeiten, die zur Ausführung von Scrum erforderlich sind.

Scrum kennt keinerlei Hierarchie, weder zwischen den Verantwortlichkeiten (Scrum Master, Product Owner und Developer), noch zwischen den Entwicklern. Damit werden im Wesentlichen zwei Ziele verfolgt: Entscheidungen sollen auf Basis fachlicher Kriterien getroffen werden. Und die Verantwortung liegt im Team und nicht bei einzelnen Teammitgliedern. Die Verantwortlichkeiten, die Entwickler in Scrum übernehmen, sind klar beschrieben. „Die Entwickler sind immer rechenschaftspflichtig für

  • die Erstellung eines Plans für den Sprint, das Sprint Backlog;
  • das Einbringen von Qualität durch die Einhaltung einer Definition of Done;
  • die tägliche Anpassung ihres Plans an das Sprint-Ziel; und,
  • das gegenseitige zur Rechenschaft ziehen als Fachleute.“

In der Praxis führt dies dazu, dass Entwickler (im Ganzen natürlich als Entwicklungsteam)

  • die Machbarkeit und den Aufwand von Backlog Items beim Sprint Planning beurteilen, über den Umfang des Sprint Backlogs entscheiden und sich auf ein gemeinsames Sprint-Ziel committen.
  • zum Ende eines jeden Sprints – unter Beachtung der Definition of Done – ein potentiell lieferfähiges Inkrement produzieren.
  • sich im Daily Scrum über den Fortschritt beim Sprinten untereinander sowie mit dem Scrum Master und ggf. dem Product Owner austauschen. Als Orientierung dient das Sprint-Ziel. Hindernisse – die sogenannten Impediments – auf dem Weg zum Sprint-Ziel werden kommuniziert und idealerweise (ggf. auch durch die Hilfe des Scrum Masters) beseitigt.
  • im Sprint Review die realisierten Backlog Items bzw. das Inkrement präsentieren.
  • in der Retrospektive versuchen, das gemeinsame Vorgehen für den nächsten Sprint zu optimieren.

Auch wenn Scrum für das Entwicklungsteam keine expliziten Rollen definiert, so besitzen die Teammitglieder im Idealfall dennoch unterschiedliche Fähigkeiten und Kenntnisse. Die Leistung des Teams hängt maßgeblich von der Kombination dieser Fähigkeiten ab. Verfügt eine Mitarbeiterin oder ein Mitarbeiter nicht über benötigte Kenntnisse, so ist das Team als Ganzes gefordert, sie oder ihn bei der Tätigkeit zu unterstützen und die Fähigkeiten zu erweitern. Das Sprint-Ziel lässt sich nur gemeinsam erreichen.

Impuls zum Diskutieren:

Können Entwicklungsteams effizient entwickeln, wenn sie je nach Vorhaben mit unterschiedlichen Frameworks arbeiten?

Hinweise:

Eine Liste der unterschiedlichen Rollen in V-Modell XT finden Sie hier  »

Bereits in der Scrum Guide Fassung vom November 2017 wurde klargestellt, dass sich Scrum nicht nur für die Softwareentwicklung, sondern generell auch für die Produktentwicklung eignet. Damit adressierte Scrum dieselben Gegenstände – Software, Hardware, Systeme – wie das V-Modell XT. Der wesentliche Unterschied lag in der Selbstorganisation und der Eigenverantwortung des Scrum Entwicklungsteams und einem idealerweise damit einhergehenden agilen Mindset. Auch wenn der Scrum Guide 2020 von Selbstmanagement anstelle von Selbstorganisation spricht und aus dem Entwicklungsteam Developer bzw. Entwickler macht, so ändert sich an der entsprechenden Ausrichtung nichts.

Hier finden Sie ergänzende Informationen aus unserem Blog:

t2informatik Blog: Das SWAT-Team in Scrum

Das SWAT-Team in Scrum

t2informatik Blog: Sinnvolle Grenzen für selbstverantwortliche Teams

Sinnvolle Grenzen für selbstverantwortliche Teams

Auftragsklärung - das Wichtigste zuerst - Blog - t2informatik

Auftragsklärung – das Wichtigste zuerst