SCRUM hilft dem nur, der SCRUM auch kann



In einem uns bekannten Fall brauchte ein kleines Unternehmen ein großes Webportal. Eine Viertelmillion würde es kosten. Mehrere hundert Manntage wurden nötig brauchte. Ein Lastenheft wurde erstellt. aber der Auftragnehmer, eine mittelständische Software-Firma aus Hamburg, redete dem Kunden das Pflichtenheft aus. Der Auftragnehmer redete dem Kunden stattdessen agile Prozesse nach dem Scrum-Modell ein. Allerdings machte dafür weder den Kunden fit, um die unverzichtbare Rolle des "Product Owners" zu besetzen, noch besetzte er diese Rolle mit einem Teammitglied selbst. Die übergreifenden Interessen des Kunden spielten dadurch gar keine Rolle mehr und wurden den alltäglichen Interessen des Projektteams "untergebuttert".

Es kam, was kommen musste: Das Team entwickelte an den Anforderungen vorbei. Mit acht oder neun detaillierten Störungsmeldungen reagierte der Kunde. Er wurde nicht ernst genommen. Er wurde vertröstet und vertröstet. "Wir sind auf einem guten Weg" wurde ihm gesagt. Ihm wurde gedroht. Wenn die Mitarbeiter nicht bezahlt werden könnten und entlassen werden müssten, dann könne das halbfertige Produkt gar nicht mehr übergabereif gemacht werden. So wurde der Kunde immer wieder zu Teilzahlungen für Projektteile genötigt, die tatsächlich weder geliefert noch abgenommen waren.

Sechs Monate Projetzeit waren geplant. Insgesamt 15 Monate ging das Theater. Bis dahin hatte der Kunde netto 250.000 Euro Abschlagszahlungen überwiesen. Ein abnahmefähiges Werk wurde ihm bis zm Ende nicht geliefert. Da das gesamte Marketing der Folgejahre auf dem neuen Portal aufbaue sollte, verursachte der Ausfall weitere Folgeschäden in wenigstens sechsstelliger Höhe. Der Kunde blieb letztlich nichts weiter übrig als gegen den Auftragnehmer gerichtlich vorzugehen. Auf dem Gesamtschaden wird er dennoch sitzenbleiben.

Genau solche Reinfälle sollten agile Prozesse wie Scrum gerade vermeiden. Nie dürfen Projekte unter unklaren Entscheidungswegen, missverständlich formulierten und priorisierten Anforderungen oder fehlender Transparenz des Projektfortschrittes leiden. Eigentlich sind die im Scrum-Modell beschriebenen Mechanismen und Rollen geeignet, grundlegende Verbesserung zu erreichen. Eigentlich lässt sich so die Motivation, Identifikation und Effizienz der Projektmitarbeiter steigern.

Eigentlich kann Scrum daher ein wesentliches Instrument zur nachhaltigen Qualitätssteigerung im Projekt sein. Als iteratives Vorgehensmodell beschreibt Scrum keine klassischen Projektphasen, sondern legt vielmehr von Beginn an Wert auf laufend verwertbare Ergebnisse.

Das Problem besteht darin, das Scrum relativ unbekannt ist. Und sogar Anwender, die lizenziert wurden, können es fahrlässig oder vorsätzlich falsch anwenden, wie das obige Beispiel zeigt.

Deshalb ist Klasse, dass die InterFace AG hier http://www.scrum-plakat.de eine tolle, einfache und klare Übersicht in Form eines Plakats erarbeitet wurde, das unter der Lizenz Creative Commons http://creativecommons.org/licenses/by-nc-sa/2.0/de/ verwendet werden darf.

Sehr zu empfehlen!

PS: Es gibt im Scrum-Prozess zum Beispiel folgende "Rollen":
Scrum-Team: Optimale Größe: 7 +/-2 Mitglieder; Interdisziplinär besetzt; Alle Fähigkeiten für Entwicklung vorhanden. Das Team agiert als aktiver Berater des PO.
Scrum-Master: Coach für die Anwendung von Scrum, löst organisatorische Hindernisse, schützt vor störenden Einflüssen und arbeitet mit dem Product Owner.
Product Owner (PO): Der Product Owner gibt die Vision vor und entscheidet über die Features im Product Backlog. Er vertritt alle Interessengruppen außerhalb des Projektteams.



Ihre Sicherheit und Privatsphäre im Internet sind uns wichtig! Es werden mittels des Einsatzes von Cookies keinerlei persönliche Daten gespeichert oder mit Dritten getauscht. Dennoch verwendet diese Website Cookies zur Steigerung von Funktionalität und Leistungsfähigkeit. Falls Sie weiter lesen und unsere Website verwenden, stimmen Sie dem Gebrauch von Cookies zu.

Schließen