Methoden

Ich habe mich vor ein paar Tagen mit dieser Frage beschäftigt, als mein Sohn mir wieder seine Weihnachtswünsche mitgeteilt hat, die vollkommen von der ursprünglichen Planung abweichen.  Dabei ist mir erst die Nähe zum Projektgeschäft aufgefallen und die gemeinsamen Probleme, wenn man die Sache nicht richtig angeht.

Fangen wir mal vorne an. Im Rahmen einer Anforderungsanalyse  (Blättern durch den Spielzeugkatalog) entstehen erste Ideen. Die daraus entstandenen Anforderungen werden bei uns in ein Lastenheft (Wunschzettel) geschrieben.  Dann folgt eine kurze Diskussion darüber, dass nicht alle Anforderungen in der gegebenen Zeit umgesetzt werden können, da die Ziele vollkommen überzogen sind. Zur Umsetzung aller Anforderungen müssten noch weitaus mehr Meilensteine gesetzt werden als in dem ursprünglichen Zeitplan (Nikolaus und Weihnachten). Meilensteine wie Ostern, Geburtstag und nochmal Weihnachten… Also haben wir den Rahmen festgelegt und uns auf den Liefertermin geeinigt – Weihnachten eben.

Das Projektteam (meine Frau und ich) hat also versucht die Anforderungen umzusetzen und dabei in täglichen Meetings (Abends auf dem Sofa) den Projektfortschritt untereinander abgestimmt.  So agil sind wir schon. Die Rückkopplung zum Kunden habe ich übernommen, indem ich hin und wieder mal nachgefragt habe, ob die Anforderungen noch stabil sind. Tatsächlich habe ich vor ein paar Tagen festgestellt, dass sich die Wünsche vollkommen geändert haben.   Nun sollte es ja im agilen Projektumfeld keine große Schwierigkeit geben, wenn sich die Anforderungen ändern. Vermutlich steht auch ein Scrum-basiertes Projekt vor dem Aus, wenn die Anforderungen sich um 180° drehen.  Wir haben so allerdings noch die Möglichkeit Teile der ursprünglichen Planung zu verwerfen und auf die neuen Anforderungen einzugehen. Das Change-Management  wird auch wieder auf dem Wunschzettel durchgeführt. Dabei ist mir aufgefallen, dass es sinnvoll ist auch bei so kleinen Projekten die Anforderungen mit einem Datum zu versehen.

Für mich stellt sich nun die Frage, ob der Weihnachtsmann agil arbeiten  sollte oder eher klassisch Phasenorientiert. Ich bin zu der Überzeugung gekommen, dass ein agiles Vorgehen auch hier hilft. Denn neben den geänderten Anforderungen hat man so großen Einfluss auf die Erwartungshaltung des Kunden – und das ist nicht nur Weihnachten wichtig.

Eben erst hatte ich Zeit mir die neue  iX anzusehen und mir spring sofort der Artikel auf Seite 110 in die Augen. Ein Beitrag über agile Softwareentwicklung speziell mit Scrum – insgesamt lesenswert. Was mir aber besonders gefallen hat, ist die Liste der Scrum-Anti-Patterns:

1. Der Scrum Master weist Aufgaben zu und zerstört so das sich selbst steuernde und organisierende Team.
2. Der Sprint wird von außen gestört. Es werden neue Aufgaben eingefügt oder Änderungen an den gewählten User Stories vorgenommen.
3. Es finden keine Review Meetings statt.
4. Es findet keine Retrospektive statt.
5. Es gibt keine regelmäßigen Daily Standup Meetings.
6. Der Product Owner hat keine ausreichende Kompetenz und nimmt seine Rolle nicht wahr.
7. Es gibt kein „1 to 1 Agreement“, also keine persönliche Vereinbarung zwischen dem Product Owner und dem Team.
8. Die Beteiligten sind nicht ausreichend geschult.
9. Meetings sind nicht Timeboxed.
10. Anstatt Features werden Aktivitäten erfasst.
11. Man schickt ein paar Scrum Master zum Training und denkt, nun werde alles gut.

Diese Liste ist bei weitem noch nicht vollständig. Mir fallen da spontan noch ein paar Ding wie „Bug-fix Sprints“ oder die aktive Beteiligung des Management am Daily Scrum ein.

Fallen Ihnen vielleicht noch ein paar schöne Scrum-Anti-Patterns ein? Ich bin gespannt.

(Bildquelle: Stock Exchange, johnmckeag)