Lean Development

Teamorganisation nach dem Scrum-Prinzip

| Autor / Redakteur: Christian Rentrop / Stephan Augsten

Eine klare Definition der Rollen ist unabdingbar für ein Team, das nach dem Scrum-Prinzip organisiert wird.
Eine klare Definition der Rollen ist unabdingbar für ein Team, das nach dem Scrum-Prinzip organisiert wird. (Bild: Olga Guryanova - Unsplash.com)

Nicht nur die Software-Entwicklung kann nach dem Scrum-Prinzip ablaufen, sondern auch die Teamorganisation. Das Resultat sind schlanke und effiziente Entwicklerteams, die schnell auf Änderungen bei den Anforderungen reagieren können. Doch wie werden solche Scrum-Teams organisiert?

Scrum (Englisch „Gedränge“) gehört zu den Buzz-Wörtern in der Software-Entwicklung. Eigentlich erleichtert die agile Projektmanagement-Technik die Vorgehensweise bei komplexen Software-Projekten. Die Philosophie hinter Scrum besagt, dass viele Entwicklungsprojekte schlicht zu komplex sind, um von vorne bis hinten durchgeplant werden zu können.

Statt mit komplexen Lasten- und Pflichtenheften wird deshalb inkrementell gearbeitet: Die Lösungsansätze sind zunächst unklar, stattdessen wird eine „Vision“ vorgegeben, die als Ziel der Entwicklung dient. Im Rahmen sogenannter Sprints werden regelmäßig Zwischenergebnisse fertiggestellt und geprüft. Aufgrund der darin enthaltenen Lösungsansätze kann dann zum nächsten Schritt übergegangen werden.

Das gibt Entwicklern die größtmögliche Freiheit bei maximaler Qualität – und sorgt damit für eine deutlich schnellere, effizientere und kostengünstigere Softwareentwicklung bei gleichzeitig höherer Qualität. Wichtig dabei sind allerdings die drei Säulen von Scrum: Transparenz, Prüfung in kurzen Intervallen und darauf basierend die regelmäßige Anpassung der Vorgaben und Pläne an den Status Quo.

Scrum im Team nutzen

Dieses Prinzip lässt sich frei vom Software-Engineering auf beliebige Management-Projekte – also auch die Organisation von Entwicklerteams – übertragen, da es sich beim Scrum-Prinzip um ein Management-Framework handelt. Der Vorteil liegt auf der Hand.

In dynamischen Umgebungen kann schneller auf Änderungen in den Projektzielen oder auf Probleme im Ablauf reagiert werden, da der Ablauf empirisch, inkrementell und iterativ ist. Kleine Einzelpakete statt eines großen Gesamtpakets werden geschnürt, wodurch an Stellen, an denen Probleme auftreten, schnell reagiert werden kann. Angelehnt an dieses Prinzip können Entwicklerteams als sogenannte „Scrum Teams“ aufgestellt werden.

Das Scrum-Team in der Praxis

Das Scrum-Team sollte aus fünf bis zehn Personen bestehen. Zu wenige Personen hindern den kreativen Prozess, weil zu wenig Austausch erfolgt. Zu viele Personen erfordern zu viel Koordination zwischen den Teammitgliedern, wodurch es ebenfalls zu Reibungsverlusten kommen kann.

Innerhalb des Teams werden außerdem drei Rollen vergeben. Diese werden nicht zugewiesen, sondern basierend auf Kenntnissen, Fähigkeiten und Erfahrung im Idealfall freiwillig eingenommen. Diese drei Rollen sind:

  • Scrum Master
  • Product Owner
  • Entwickler

Der Scrum Master ist dabei der Experte und verantwortlich für sein Scrum-Team. Er ist dabei idealerweise eine „natürliche“ Führungskraft, sprich kein eingesetzter Chef, sondern jemand, der gerne Verantwortung für das Gesamtteam übernimmt und von den anderen Mitarbeitern des Teams respektiert wird. Er ist für die Leitung seiner (Teil-)Einheit zuständig und vor allem damit betraut, Störungen im Ablauf zu beseitigen, Probleme im Team zu lösen und so die Agilität des Scrum-Teams aufrecht zu erhalten.

Der Product Owner – per Definition ein Vertreter des (internen oder externen) Auftraggebers – ist für das Produkt an sich zuständig und hält die Fäden zusammen: Er kennt nicht nur die Vision des Software-Produkts sondern auch den Markt, die angepeilte Kundschaft, zwingende Anforderungen und die zu verwendenden Technologien. Gleichzeitig kommuniziert er mit den Hierarchie-Ebenen oberhalb des Scrum-Teams und hält die Fäden mit anderen Teams zusammen. Er muss ich gegebenenfalls gegen Entscheidungen aus dem höheren Management durchsetzen können, indem er Aufwand und Machbarkeit kommuniziert.

Die Entwickler sind die eigentlichen „Macher“ des Scrum-Teams und selbstorganisiert: Als Team planen sie die notwendige Vorgehensweise für ihr Teilpaket oder ihren Teilschritt und sorgen dafür, dass die gewünschte Beschaffenheit des Produkts-Inkrements im Rahmen eines Sprints zustande kommt. Gleichzeitig helfen Sie dem Product Owner, das Projekt in sinnvolle Teile zu untergliedern. Die Entwickler sind eher virtuell zu verstehen; es kann sich auch um Produktmanager handeln, die zum Beispiel mit freien Programmierern oder weiteren Unter-Scrum-Teams zusammenarbeiten.

Weitere Rollen außerhalb des Scrum-Teams

Zusätzlich gibt es „außerhalb“ des Teams noch drei weitere Rollen: Den Manager, den Kunden und den Nutzer. Während der „Manager“ sich in der Hierarchie oberhalb von Scrum-Master und Product-Owner befindet und mit diesen im Austausch steht, ist der „Kunde“ im Grunde der Finanzier des (Teil-)Projekts, der die Kosten im Auge behält. Der „Nutzer“ ist letztlich ein Produkttester, der die einzelnen Teile oder das Gesamtprodukt auf Probleme und Fehler überprüft.

Diese drei Bezeichnungen sind metaphorisch zu verstehen: So kann der „Kunde“ auch die Controlling-Abteilung eines Unternehmens sein, das das Scrum-Team beherbergt. Und der Manager kann natürlich ein Entwickler eines Scrum-Teams auf höherer Hierarchieebene sein. Der Kunde könnte auch jemand aus dem internen Qualitätsmanagement sein.

Die Arbeitsweise eine Scrum-Teams

Sind die Rollen erst einmal vergeben, kann es an die eigentliche Arbeit gehen: Das Scrum-Team arbeitet in Sprints, die das Ziel haben, das gewünschte Anforderungsprofil der gesetzten Aufgabe zu erfüllen. Damit das möglichst effektiv abläuft, nutzt es dabei die vier Schritte des sogenannten Deming-Zyklus, der in den 1930er Jahren von dem US-amerikanischen Physiker William Edwards Deming für die Qualitätssicherung entwickelt wurde.

Ein Deming-Zyklus besteht aus den Phasen „Plan – Do – Check – Act“, also „Planen – Umsetzen – Überprüfen – Handeln“ innerhalb eines gesetzten Zeitrahmens. Dieser Zeitrahmen sollte dabei abhängig von der Größe des zu erreichenden Ziels und der Komplexität des Projekts kürzer oder länger gesetzt werden. Fünf Meetings geben dabei den Takt an:

1. Sprint-Planning 1

Hier wird das Gesamtziel des Sprints festgelegt. Der Product-Owner „moderiert“ dieses Meeting mit einem klaren Anforderungsprofil, das jedoch abhängig von der Einschätzung der Entwickler angepasst werden sollte. Sind die Ziele definiert, gilt es, sie für künftige Überprüfbarkeit in einem sogenannten Sprint-Backlog einzutragen.

2. Sprint Planning 2

In einem zweiten Planungsmeeting wird die Art und Weise der Umsetzung besprochen: Welche Technologie wird verwendet, welche Lösungsmöglichkeiten gibt es. Die einzelnen To-Dos sollten zum Beispiel für alle sichtbar auf einem Whiteboard festgehalten werden.

3. Daily Scrum Meeting

Im täglichen Scrum-Meeting synchronsiert sich das Team: Fortschritte und Probleme werden besprochen. Hier kann ein „kleiner“ Deming-Kreis zum Einsatz kommen, um das Meeting möglichst effektiv zu gestalten, sodass jeder nach dem Meeting weiß, was zu tun ist.

4. Check/Review

Ist der Sprint samt des damit verbundenen Teilprojekts abgeschlossen, wird es vorgeführt. Idealerweise sind auch Vertreter der Gruppe „Kunde“ und „Nutzer“ zugegen, um zu prüfen, ob ihre Anforderungen auch erfüllt wurden. Gleichzeitig können Fehler schnell eliminiert und Anpassungen im Sprint-Backlog für den nächsten Sprint durchgeführt werden.

5. Act

Zu guter Letzt sprechen die Entwickler untereinander, um die Ergebnisse des letzten Scrum-Sprints zu besprechen. Wo liegen Fehler, welche Probleme kamen auf? Das sorgt für eine kontinuierliche Verbesserung des Ablaufs.

Scrum ist einfach und effizient

Grundsätzlich ist die Teamorganisation nach dem Scrum-Prinzip für jede Team- und Unternehmensgröße geeignet, sofern mindestens drei Mitarbeiter involviert sind. Es sorgt für maximale Effizienz bei minimalem Aufwand.

Durch die Unterteilung in „Unter-Scrums“ können große Projekte in beliebige kleinere Teilbereiche untergliedert werden. Allerdings sorgt jede Hierarchieebene für erneuten Overhead bei der Verwaltung der einzelnen Scrums, weshalb es nicht sinnvoll ist, zu kleine Einheiten und Teilbereiche zu entwickeln.

Für die einzelnen Team-Mitglieder ist das Scrum-Prinzip ebenfalls angenehm: Jeder erhält eine klare Arbeitsanweisung und ein Projektziel, das es in einem fixen Zeitraum zu erreichen gilt. Die konkrete Vorgehensweise ist jedoch nicht zwingend festgelegt, was den einzelnen Teammitgliedern im Rahmen der Vorgaben maximale Freiheit und Kreativität ermöglicht.

Der häufige Austausch innerhalb eines Scrum-Teams erlaubt zudem ein schnelles Abfangen von Fehlentwicklungen. Dadurch lassen sich bestimmte Probleme wie ausufernde inhaltliche Diskussionen oder Frust bei den Entwicklern deutlich reduziert werden.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44966158 / Agile Entwicklung)