Wenn ein Unternehmen beschließt, einen erfahrenen ScrumMaster zu Hilfe zu holen und "es einmal mit Scrum zu versuchen", geschieht das oft "im Geheimen", weil ein Software-Projekt in der einen oder anderen Form "hängt".
- Man wird nicht fertig mit der Anforderungsanalyse.
- Das Projekt dauert unerklärlich lange ohne erkennbare Fortschritte.
- Anforderungen ändern sich, und das Projekt droht, daran zu scheitern.
- Der Overhead durch das Projektmanagement mit RUP, V-Modell [XT], Wasserfall- oder Spiralmethode ist zu hoch und bremst das Projekt durch eine Flut von Dokumentation und Besprechungen.
- Viel Arbeit und Zeit (=Geld) wurde bereits investiert, ohne daß man sich darüber im Klaren ist, ob das Projekt auf dem richtigen Weg ist.
Diese Situationen sind nicht untypisch: Das Kind ist bereits in den Brunnen gefallen, und jetzt soll die Feuerwehr kommen, um es wieder heraus zu holen. Als ScrumMaster könnte man sich jetzt beklagen, weil es natürlich schöner ist, ein Projekt von vorneherein mit Scrum aufzusetzen. Aber die Flexibilität und Reaktionsschnelligkeit im Umgang mit neuen Situationen zeichnet Scrum als Methode ja gerade aus, und so ist es wenig erstaunlich, daß Scrum in der Vergangenheit schon diverse Projekte gerettet hat und dies auch in Zukunft weiter tun wird.
Warum das so ist, hat nichts mit ausgeklügelten Regelsätzen für jede erdenkliche Situation zu tun, sondern mit der (konsequenten) Anwendung gesunden Menschenverstandes und relativ simpler Regeln.
| < Zurück | Weiter > |
|---|