Wie Hochleistungsteams  funktionieren wurde vorgestern in der ZDF-Sendung “Abenteuer Wissen” am Beispiel von Regatta-Segeln erklärt. Der Beitrag ist noch online verfügbar und weist aus meiner Sicht viele Parallelen zur agilen Softwareentwicklung auf. Insbesondere die Retrospektive wurde in dem Beitrag als einer der zentralen Schlüssel für den Erfolg von Teams identifiziert. Dabei gilt sowohl die Selbstreflektion jedes Einzelnen, als auch die der ganzen Gruppe.

Bevor aus einer Gruppe allerdings ein Team wird ist es notwendig, dass alle ein gemeinsames Ziel vor Augen und auch verinnerlicht haben. Das heißt, in den Köpfen der Mitglieder ist zum einen ihre Teilaufgabe hinterlegt, zum anderen aber auch das Big Picture. (Für das Big Picture in der Softwareentwicklung eignet sich der “Elevator Pitch” hervorragend).

Wichtig ist für die Teambildung der richtige Charakter der Mitglieder.  Man braucht Leute mit den richtigen Wesenszügen und Kompetenzen, denen man vertrauen kann. Alle müssen sie unter einer klaren Führung zusammenarbeiten. Ein Team ist kein Ort der Selbstprofilierung oder individueller Machtstrategien.

Wer nähere Informationen zu dem Thema sucht, findet sicherlich was auf dem Blog von Winfried Berner. Dort habe ich einen interessanten Beitrag über die Geheimnisse gut funktionierender Arbeitsgruppen gefunden, der das Thema aus Sicht von Projektteams erläutert.

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!