Ist Scrum nur ein Alibi?

Scrum ist weiterhin in aller Munde. Vielen Publikationen ist zu entnehmen, dass mittlerweile zahlreiche prominente Unternehmen auf diese Vorgehensweise setzen (siehe z.B. unser Bücherschrank). In der Praxis trifft man in der Tat zunehmend auf Unternehmen, welche Scrum anwenden.

„wir machen Scrum! Und wir sind sehr erfolgreich damit!“. Sätze dieser Art konnte ich bisher öfters aus den Bereichen der Softwareentwicklung hören. Genauer hingeschaut ergab sich dann in einem konkreten Beispiel folgendes Bild:

• Es gibt kein definiertes Product Backlog
• Es gibt kein Burn-Down-Chart
• Es findet keine Detaillierung in ein Sprint-Backlog statt
• Eine feste Regelung für das Daily Scrum gibt es nicht, man sitzt ja in einem gemeinsamen Büro und kann sich zurufen ….
• Die Planung der Sprints macht dann doch einer allein (der vermeintliche Scrum Master) und nicht das Team
• Der Product Owner will eigentlich keine Verantwortung übernehmen um die Sprint-Ergebnisse zu testen und abzunehmen
• Dokumentiert wird prinzipiell gar nichts

Am Ende des Tages stellt man fest: nur einige Elemente werden angewendet, gerade die entscheidenden Komponenten welche das Einsteuern und Detaillieren der Anforderungen regeln werden ausgelassen. Was man hier antrifft ist so eine Art „Pseudo-Scrum“, was natürlich mehr schlecht als recht funktioniert. So kam es in diesem Fall ständig zu massiven Ressourcenüberlastungen, Unklarheiten bei der Erfüllung der Anforderungen (durch zu großen Interpretationsspielraum bei Entwicklung Test aufgrund fehlender Detaillierung) und nicht zuletzt zu Qualitätsproblemen da Dokumentation und Test nicht ausreichend ausgeprägt sind.

Genauer betrachtet erinnerten mich diese Probleme an altbekannte „Strukturn“: in der es ohne nennenswerte Dokumentation und Verbindlichkeit, geprägt von der Interpretation des einzelnen, umsetzenden Entwicklers und zuletzt wenig ausgeprägten funktionalen Tests immer wieder zu Problemen mit der Umsetzung von Anforderungen und der Qualität gab…..

Fazit: Genau hinschauen – nicht immer ist Scrum drin wenn es drauf steht! Gerne wird diese Vorgehensweise dazu benutzt, in leicht adaptierter Form der oben beschriebenen Vorgehensweise einen vermeintlich strukturierten Anstrich zu geben. Oftmals fallen dabei aber genau die Erfolgsfaktoren vom Tisch:

• ein gezielter und strukturierter Umgang mit sich im Verlauf detaillierenden Anforderungen
• eine enge Kommunikation im Team und Abstimmung mit dem Repräsentanten der Anforderer
• einen hohen Stellenwert funktionaler Tests

Nicht zuletzt ist das Umfeld und die zu liefernden Ergebnisse entscheidend darüber, ob Scrum die richtige Wahl ist – und welche Ausprägungen Sinn machen.