Suchen

Agile Software-Entwicklung: Eine gute Alternative, aber kein Allheilmittel Stolpersteine in Scrum-Projekten und wie man sie umgeht

| Autor / Redakteur: Jessica Schmidt / Florian Karlstetter

Die Software-Schmiede BSI Business Systems Integration AG entwickelt in einigen Projekten nach der agilen Entwicklungsmethode Scrum. Scrum hat, wie andere agile Vorgehensmodelle auch, viele Vorteile, lässt beispielsweise viel Flexibilität bei den am Ende umgesetzten Funktionen. Allerdings gibt es auch einige Stolpersteine bei Scrum.

Die beiden Scrum-Profis Alexandra Junghans und Marco Montoya, beide Software-Ingenieure bei BSI.
Die beiden Scrum-Profis Alexandra Junghans und Marco Montoya, beide Software-Ingenieure bei BSI.
( Archiv: Vogel Business Media )

So bringen fehlende Hierarchien viele neue Herausforderungen mit sich. Eine gut funktionierende Kommunikation ist die Voraussetzung für den Projekterfolg. BSI zeigt Stolpersteine in Scrum-Projekten auf und gibt Tipps, wie Sie diese Klippen umschiffen.

Die Vorteile der Scrum-Methodik sind den meisten Unternehmen heute bekannt: Zwar wird anfangs ein Spezifikations- und Zeitplan aufgestellt und auch die Gesamtlaufzeit des Projektes und das Budget werden festgelegt. Die konkrete Umsetzung der Funktionen ist aber nicht in Stein gemeißelt, da sich im Projektverlauf viele Faktoren ändern können. Dicke Spezifikationsbücher, die alle Funktionen en detail abdecken, gibt es nicht. Stattdessen werden die umzusetzenden Funktionalitäten der Software ständig neu hinterfragt und nach klaren Prioritäten umgesetzt. So kann es passieren, dass ein anfangs benötigtes Feature am Ende nicht umgesetzt wird, dafür aber ein neues, dessen Wichtigkeit erst im Lauf des Projektes erkannt wurde.

Durch dieses so genannte agile Vorgehen erübrigt sich die Angst, etwas zu vergessen, da man zu jeder Phase im Projekt Wichtiges, das sich neu ergeben hat, einbringen kann. Der Kunde weiß immer über den aktuellen Projektstand Bescheid. Schon zu einem sehr frühen Zeitpunkt steht dem Kunden eine funktionsfähige Software zur Verfügung, die er testen und anpassen lassen kann.

Tim Hellinga, Scrum-Master und Projektleiter bei BSI. (Archiv: Vogel Business Media)

„Für die Projektmitarbeiter ist die agile Entwicklung – in unserem Fall Scrum – extrem motivierend, da sie in jeder Projektphase an dem arbeiten, was dem Kunden am wichtigsten ist“, bestätigt Tim Hellinga, Scrum-Master und Projektleiter bei BSI. „Entsprechend groß ist auch die Anerkennung auf Kundenseite, wenn das Projekt mit einem Scrum-erprobten Partner umgesetzt wird und der Kunde zusehen kann, wie schnell und effektiv aktuelle Anforderungen implementiert werden. Allerdings bergen Scrum-Projekte auch Risiken, die Unternehmen unbedingt bedenken sollen“, warnt Hellinga.

Außerhalb der Schranken von Hierarchien

Scrum und Hierarchien widersprechen sich grundsätzlich. Es gibt Rollen mit ihren Kompetenzen, z. B. hat der Product Owner im Sprintplanning-Meeting das Sagen: Er definiert in Absprache mit den Fachverantwortlichen auf Kundenseite die Priorität der Stories, die im Sprintbacklog dokumentiert werden. Aber das Team entscheidet während des Sprints selbst, wie es die Stories aus dem Sprintbacklog umsetzt. Das klassische „Order And Command“ Schema darf vom Product Owner nicht angewendet werden, da sonst die Selbstorganisation des Teams unterbunden wird (dazu weiter unten mehr).

Das lässt viel Freiheit für das Projekt, stellt aber auch neue Herausforderungen. Während des Sprints die Kontrolle abzugeben, kann ungewohnt sein für einen Product Owner, wenn er vorher ein eher autoritärer Projektleiter war. Zudem muss der Product Owner in seinem Unternehmen sehr gut vernetzt sein, um alle Präferenzen und Dringlichkeiten im Projekt einschätzen zu können. Diese Person muss die vielen Meinungen, die gleichzeitig quasi auf ihn einprasseln, sehr gut organisieren und priorisieren können. Dazu braucht ein Product Owner ein sehr tiefes Verständnis der umzusetzenden Software und der Business-Logik seines Unternehmens. Ein guter Projektleiter ‚klassischer Manier‘ ist damit nicht zwangsläufig auch ein guter Product Owner. „Der Product Owner ist eigentlich wie ein Politiker: Er sammelt Meinungen, Eindrücke, fragt, wo der Schuh drückt und baut aus diesen vielen Einzelstücken den aktuellen Projektstand täglich neu“, fasst Alexandra Junghans, Software-Entwicklerin bei BSI und Scrum-Profi, zusammen.

Aber auch innerhalb des Teams auf Herstellerseite stellen die flexiblen Strukturen der Scrum-Methodik ganz andere Anforderungen an die Mitglieder als ‚herkömmliche‘ IT-Projekte mit ‚starrer‘ Vorgehensweise. So werden keine Aufgaben vom Scrum Master an die Teammitglieder angewiesen. Der Scrum Master ist der Coach, der sicherstellt, dass das Team effizient arbeiten kann und der Hindernisse aus dem Weg räumt. Der Scrum Maser mischt sich nur ein, wenn das Team sich nicht an die Scrum-Regeln hält, z. B. wenn es die höchst priorisierten Stories nicht als erstes in Angriff nimmt.

Das erfordert viel Disziplin, Organisation und Verantwortungsbewusstsein bei den Teammitgliedern. Damit kann und mag nicht jeder Mitarbeiter umgehen. „Der Gruppendruck ist enorm hoch: Jemand, der versucht, sich immer die Rosinen aus dem Kuchen zu picken, fällt schnell auf. Aber solche Fälle sind zum Glück sehr selten. Meiner Erfahrung nach funktioniert die Aufgabenverteilung in selbstorganisierten Teams, wie sie bei Scrum der Fall sind, sehr gut und Mitarbeiterstudien haben gezeigt, dass Mitarbeiter in selbstorganisierten Teams zufriedener sind als Kollegen in hierarchischen Gruppen“, weiß Alexandra Junghans.

Auf der nächsten Seite erfahren Sie, wie wichtig die Kommunikation bei Scrum-Projekten ist.

Artikelfiles und Artikellinks

(ID:2050013)