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)

Physikalische Grenzen werden von den meisten Menschen akzeptiert. So besitzt das Licht eine nicht beeinflussbare Geschwindigkeit und kein Mensch wird jemals die 100m  in sieben Sekunden laufen. Kein Handwerker baut Möbel nach Augenmaß und kein Architekt ein Haus ohne Berechnung der Statik. Dennoch werden genau diese Gesetzmäßigkeiten bei IT-Projekten immer wieder versucht zu umgehen. Es wird ein Projektplan aufgesetzt, der die Grenzen des Machbaren außer Acht lässt. Wenn also ca. 6 Personenmonate veranschlagt werden, ist es nicht mit 6 Personen in einem Monat realisiert. Oder anders ausgedrückt: „Wenn ein Schiff vier Tage braucht um den Atlantik zu überqueren, wie lange brauchen also zwei Schiffe…“.

Für jeden gegeben Funktionsumfang eines Software-Systems existiert eine minimale Projektlaufzeit und ein minimales Budget, welches kein Projektteam der Welt in der Lage ist zu unterschreiten. Ich kann mir also nur vorstellen, dass es sich um Wunschdenken im Management handelt solche Projekte zu verabschieden (siehe Punkt 6 in diesem Beitrag).

Die Grenzen der Machbarkeit beruhen auf einfachen Prinzipien wie ich in diesem Beitrag bereits erwähnt habe. Und wer ein Projekt mit unrealistischen Rahmenbedingungen unternimmt sollte vielleicht doch noch mal den Zollstock zur Hand nehmen

Bildquelle: www.piqs.de/ Knipsermann, Wir bauen ein Haus!