Verbessern Prozesse und Methoden wirklich etwas - oder ist das praktizierter Aberglaube in Steuerkreisen? - Ich sage: Scrum verbessert wirklich etwas.
Das Produkt, das mein Team und ich zwei Jahre lang entwickelt haben, geisterte fast fünfzehn Jahre lang als Vision in den Köpfen der Anwender. Mehrmals nahm man Anlauf. Große Projekte, lange Dokumente. Man entwickelte, ging auf die Startbahn und - brach ab.
Wenn in den Zeitungen von gescheiterten IT-Projekten zu lesen ist, steckt als Methode immer der sog. "Wasserfall" dahinter: Oben schrieb einer auf, was die da unten seiner Meinung nach brauchen. Dann kam noch einer und diktierte ihm noch ein Kapitel. Dann sprach sich das herum, dass da einer Anforderungen sammelt, und der Projektleiter holte sie alle "ins Boot". Die Wunschliste wurde immer länger. So lang, dass der Empfänger ein Team für die Exegese organisieren musste. Was meinte der Kunde - und wozu?
Dann hat das IT-Unternehmen so entwickelt, wie es meinte die Anforderungen seines Kunden verstanden zu haben, der ja meinte, die Anforderungen seiner Anwender verstanden und verschriftlicht zu haben.
Ab einer bestimmten Größe (gemessen z. B. am Funktionsumfang oder der Anwenderzahl) kommt man so nicht ins Ziel. Man muss es so machen, wie in der Steve Jobs Biographie zu lesen: In kleinen Schritten entwickeln und dem Anwender zwischendurch Prototypen an die Hand geben, damit er damit spielen kann.
Doch "spielen" geht in Deutschland bekanntlich gar nicht. Klingt nach Zeitverschwendung. Noch schlimmer: Nach Spaß und Spieltrieb.
Probiert man es aber aus, funktioniert es plötzlich. "So, wir haben hier einen Editor für eure Tabelle entwickelt. Schaut mal, ob Ihr damit zurecht kommt. Danach sehen wir weiter."
Nenn es Sprint, Gate oder Qualitätskontrolle. Es geht darum, das Große in Teile zu zerschneiden und bei jedem Teil möglichst früh zu erkennen, wohin die Reise gehen soll. Wobei die Teile hier nicht hintereinander liegen ("Ausbaustufen") sondern eher wie konzentrische Kreise umeinander. Beim Wasserfall dagegen erkennt man immer erst ganz unten, was falsch ist und muss das Wasser wieder nach oben schleppen.
Kein Projektleiter kann sich alle Anwendungsfälle seiner Anwender ausdenken. Und selbst wenn er den Job seiner Anwender früher selbst gemacht hat: Er könnte betriebsblind sein, oder schon immer eine Hypothese gehabt haben, was man anders machen muss. Er sieht nicht, worauf die Gruppe beim Ausprobieren kommt. Und die Gruppe verbalisiert nicht alles, was sie will. Vieles ist implizit, "das war doch klar, dass wir das so und so meinten.."
Meine Empfehlung an IT-Projekte in Industrieunternehmen ist: Probiert agile Methoden aus.
Das Produkt, das mein Team und ich zwei Jahre lang entwickelt haben, geisterte fast fünfzehn Jahre lang als Vision in den Köpfen der Anwender. Mehrmals nahm man Anlauf. Große Projekte, lange Dokumente. Man entwickelte, ging auf die Startbahn und - brach ab.
Wenn in den Zeitungen von gescheiterten IT-Projekten zu lesen ist, steckt als Methode immer der sog. "Wasserfall" dahinter: Oben schrieb einer auf, was die da unten seiner Meinung nach brauchen. Dann kam noch einer und diktierte ihm noch ein Kapitel. Dann sprach sich das herum, dass da einer Anforderungen sammelt, und der Projektleiter holte sie alle "ins Boot". Die Wunschliste wurde immer länger. So lang, dass der Empfänger ein Team für die Exegese organisieren musste. Was meinte der Kunde - und wozu?
Dann hat das IT-Unternehmen so entwickelt, wie es meinte die Anforderungen seines Kunden verstanden zu haben, der ja meinte, die Anforderungen seiner Anwender verstanden und verschriftlicht zu haben.
Ab einer bestimmten Größe (gemessen z. B. am Funktionsumfang oder der Anwenderzahl) kommt man so nicht ins Ziel. Man muss es so machen, wie in der Steve Jobs Biographie zu lesen: In kleinen Schritten entwickeln und dem Anwender zwischendurch Prototypen an die Hand geben, damit er damit spielen kann.
Doch "spielen" geht in Deutschland bekanntlich gar nicht. Klingt nach Zeitverschwendung. Noch schlimmer: Nach Spaß und Spieltrieb.
Probiert man es aber aus, funktioniert es plötzlich. "So, wir haben hier einen Editor für eure Tabelle entwickelt. Schaut mal, ob Ihr damit zurecht kommt. Danach sehen wir weiter."
Nenn es Sprint, Gate oder Qualitätskontrolle. Es geht darum, das Große in Teile zu zerschneiden und bei jedem Teil möglichst früh zu erkennen, wohin die Reise gehen soll. Wobei die Teile hier nicht hintereinander liegen ("Ausbaustufen") sondern eher wie konzentrische Kreise umeinander. Beim Wasserfall dagegen erkennt man immer erst ganz unten, was falsch ist und muss das Wasser wieder nach oben schleppen.
Kein Projektleiter kann sich alle Anwendungsfälle seiner Anwender ausdenken. Und selbst wenn er den Job seiner Anwender früher selbst gemacht hat: Er könnte betriebsblind sein, oder schon immer eine Hypothese gehabt haben, was man anders machen muss. Er sieht nicht, worauf die Gruppe beim Ausprobieren kommt. Und die Gruppe verbalisiert nicht alles, was sie will. Vieles ist implizit, "das war doch klar, dass wir das so und so meinten.."
Meine Empfehlung an IT-Projekte in Industrieunternehmen ist: Probiert agile Methoden aus.
