Aufgeblähte Aufgaben
Geschäftsleute haben es gern vorhersehbar. Sie möchten im Voraus eine Schätzung, wie viel ein Projekt kosten und wie lange es dauern wird. Dies kann in einigen Bereichen überraschend schwierig sein.
Selbst beim Bau eines physischen Objekts wie einer Eisenbahn kommt es oft zu erheblichen Verzögerungen. So verzögerte sich die Fertigstellung der neuesten Londoner Eisenbahnlinie zwei Tage vor ihrer Einweihung um zwei Jahre. Stellen Sie sich vor, wie viel schlimmer die Situation bei immateriellen Produkten wie Software ist, wo es schwierig ist, genau zu definieren, was für die Lieferung des Produkts erforderlich ist – und was das Produkt überhaupt ist.
In den frühen 2000er Jahren wurde eine Philosophie namens Agilität in der Technologiebranche sehr populär. Sie sollte den Softwareentwicklungsprozess verbessern. Bei der agilen Entwicklung wird Software in sehr kurzen Zyklen entwickelt, die bis zu zwei Wochen dauern können, und das Ergebnis wird zwischen den Zyklen validiert und die Ziele werden neu ausgerichtet.
Alle paar Wochen trifft sich das Team, um die Aufgaben für den nächsten Zyklus zu planen. In dieser Planungsphase geschieht etwas Seltsames: Es ist üblich geworden, den für die Durchführung einer Aufgabe erforderlichen Aufwand stark zu übertreiben, was wir als Aufblähen der Aufgaben bezeichnen. In der Planungssitzung stimmen Praktiker, Manager und andere Beteiligte darin überein, dass jede Aufgabe eine außergewöhnlich hohe Anzahl von Stunden in Anspruch nimmt und eine außergewöhnlich hohe Anzahl von Mitarbeitern erfordert.
Zur Analyse der Gründe dafür komme ich gleich, vorher aber ein paar Beispiele, die das Ausmaß des Problems verdeutlichen.
Mitgefangen, mitgehangen
Eine meiner jüngsten Aufgaben bei der Investmentbank bestand darin zu analysieren, wofür einige von Microsoft zur Verfügung gestellte Software-Code-Vorlagen verwendet werden könnten. Jeder, der mit Softwareentwicklung vertraut ist, könnte dies in höchstens ein paar Stunden erledigen. In unserer Planungssitzung wurde jedoch gemeinsam beschlossen, dass diese Aufgabe mehrere Tage Arbeit und zwei Personen erfordere.
Der Schwierigkeitsgrad von Aufgaben wird in diesem Unternehmen per Abstimmung festgelegt und in diesem Fall entschied die kollektive Intelligenz, dass die Aufgabe relativ schwer war. Ich stimmte dafür, dass sie einfach sei, was nicht mit der Mehrheitsmeinung übereinstimmte. Auf Nachfrage räumte ich ein, dass die Aufgabe vielleicht doch schwieriger sei, als ich dachte.
Es ist schwer, in solchen Situationen anderer Meinung zu sein, weil es so aussieht, als ob man gegen die kollektive Intelligenz des Teams arbeitet. Wenn außerdem jede einzelne Aufgabe so aufgebläht wird und niemand etwas sagt, möchte man das System nicht infrage stellen. Da zwei von uns mit dieser Aufgabe betraut waren, teilten wir sie schließlich in zwei noch einfachere Teile auf, einen für jeden. Ich habe meinen Teil in ein paar Minuten erledigt und so getan, als ob es viel länger gedauert hätte.
Im nächsten Zyklus wurde ich beauftragt, die Ergebnisse der vorherigen Aufgabe in einem Absatz zusammenzufassen. Ich stimmte für einen Schwierigkeitsgrad von 1, die niedrigste mögliche Stufe, da es sich um eine 10-Minuten-Aufgabe handelte. Meine Kollegen waren jedoch anderer Meinung; sie stimmten dafür, dass meine Aufgabe schwieriger war, als sie aussah, und mehrere Tage Arbeit erfordern würde.
Viele kleine Teilaufgaben, die eeewig dauern
Es ist auch üblich, eine einfache Aufgabe in ein Dutzend Teile aufzuteilen und dann jede Teilaufgabe künstlich für schwierig zu erklären. Wir hatten zum Beispiel die Aufgabe zu entscheiden, welches Softwaretool wir für eine bestimmte Anwendung verwenden sollten. Wir hatten eine Liste der benötigten Funktionen und vier infrage kommende Tools, also mussten wir herausfinden, welches der Tools die meisten der benötigten Funktionen abdeckte.
Das klang für mich nach einer einfachen Aufgabe, die eine wirklich gründliche Person in ein paar Tagen erledigen könnte. Aber die Aufgabe wurde in die vier Teilaufgaben aufgeteilt, jedes der vier infrage kommenden Tools einzeln zu untersuchen. Für jede Teilaufgabe wurde zwei Mitarbeitern ein Zeitfenster von mehreren Tagen eingeräumt.
Ich schätze, ein Aufblähfaktor von mindestens 10 ist die Norm. Aber auch 50 oder sogar 100 ist nicht ungewöhnlich. Dadurch wurde die Messlatte für das, was von einem technischen Mitarbeiter erwartet wird, kollektiv gesenkt.
Wie kommt es zu dieser Aufblähung? Es ist verlockend, zynisch zu werden und von einer großen Verschwörung auszugehen, die dazu beiträgt, dass faule Mitarbeiter nicht arbeiten müssen und Unternehmen ihren Kunden überhöhte Preise berechnen können. Da mag zwar etwas Wahres dran sein, aber es muss tiefere Ursachen geben.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Tech-Branche: Wir arbeiten nicht. Null. | Wie das agile Konzept die Produktivität tötet |
Ach. Ach was. Scrum ist wie Kommunismus. Jedes mal, wenn es (mal wieder) nicht...
Natürlich haben Storypoints eine Bedeutung und das beste an Scrum. Wenn du es nicht...
Danke für Deine Frage. Wenn man nur "Scrum tut", dann unterwirft man sich wieder nur...
3000+ MA und >5Milliarden Umsatz fand ich nicht klein. Aber die Mitarbeiter wurden...
Kommentieren