“There Is Surely Nothing Quite So Useless as Doing with Great Efficiency What Should Not Be Done At All“ ― Peter Drucker
In seinem Artikel “Managing for Business Effectiveness”, der 1963 im “Harvard Business Review” erschienen ist, stellte der Ökonom und Management Experte Peter Drucker genauso treffend wie provokativ fest, dass es wohl kaum etwas Nutzloseres gibt, als mit größter Effizienz Dinge umzusetzen, die überhaupt nicht getan werden sollten. Mit diesem Satz kontrastiert er die im allgemeinen Sprachgebrauch oftmals als Synonyme verwendeten Begriffe Effektivität und Effizienz ― seine Definition:
Effizienz heißt „Die Dinge richtig tun“ Effektivität heißt „Die richtigen Dinge tun“
Dieser etwas saloppen Differenzierung folgend, bedeutet Effizienz immer eine Abwägung von Aufwand zu Ertrag: Wie zeit- oder kostenintensiv ist ein Arbeitsschritt? Stehen diese Aufwände in einem angemessenen Verhältnis zu den Ergebnissen? Ließe sich dasselbe Ergebnis auch schneller und kostensparender erreichen?
Effektivität hingegen fragt, ob die erzielten Ergebnisse überhaupt wertvoll sind und zum Beispiel von einem Kunden benötigt werden.
In der Diskussion über agile Methoden bleiben gewisse Frage selten aus:
„Ist es nicht viel zu aufwändig, in sehr kurzen Abständen immer wieder Software komplett fertigzustellen und an den Kunden zu liefern?“
„Muss man wirklich regelmäßig die fachlichen Anforderungen anpassen, ggf. ergänzen und neupriorisieren?“
„Wäre es nicht weniger Zeitaufwand, wenn am Anfang eines Projektes ein/zwei Leute einen Plan machen, die Aufgaben effizient über die gegebene Zeit und die Teammitglieder verteilt … und dann halten sich einfach alle dran?“
Verständliche Fragen, wenn man bedenkt, dass „fertigstellen und ausliefern“ für Scrum Teams bedeutet, z.B. alle 2 Wochen* vollständig lauffähige, dokumentierte und integrativ-getestete Software an den Kunden zu liefern, die sofort eingesetzt werden kann. Außerdem soll die ausgelieferte Software dann in ebenso regelmäßigen „Review Meetings“ zusammen mit dem Kunden evaluiert und die fachlichen Anforderungen kontinuierlich weiterentwickelt werden. Eine vorab abgestimmte Liste an verbindlichen Anforderungen gibt es nicht mehr. An deren Stelle tritt ein dynamisches Backlog, das „alle aktuell bekannten Anforderungen an ein Softwareprodukt“ enthält und regelmäßig an die Kundenwünsche angepasst wird.
Dazu kommt, dass Anforderungen, die heute mit dem Kunden neu definiert oder hoch-priorisiert werden, möglicherweise dazu führen, dass technische Lösungen, die kurz vorher umgesetzt wurden, überarbeitet oder neu gedacht werden müssen:
„Hätten wir gewusst, dass der Kunde das jetzt so möchte, hätten wir das damals anders gebaut…“
Schließlich ist in Scrum auch noch von cross-funktionalen Teams die Rede. Teammitglieder brauchen zwar nicht „alle alles können“ aber die Idee ist schon, dass man sich gegenseitig vertreten kann. Die Methodik möchte, dass sich ein ganzes Team im Zweifel zu 100% auf eine fachliche Anforderung konzentriert, die gerade die höchstpriorisierte ist – auch wenn die technische Umsetzung dieser nur das Spezialgebiet von wenigen ist.
Insofern haben alle, die die oben zitierten Fragen stellen, absolut recht mit ihrer Einschätzung: All das ist zeitaufwändig! Unter dem Gesichtspunkt der Effizienzoptimierung betrachtet, wäre es mitunter sinnvoller, die regelmäßigen Meetings, Evaluationen, Abstimmungen und potentiellen Nacharbeiten zu vermeiden. Man könnte zunächst alle Anforderungen erfassen, analysieren, ein umfängliches technisches Design erstellen und die einzelnen Aufgaben effizienzoptimiert auf die einzelnen Kollegen verteilen.
Und – das soll nicht bestritten werden: Neben der angestrebten Effizienz gibt es einige gute Gründe, die für solch ein „Wasserfall“-Vorgehen sprechen.
„I believe in this concept, but the implementation described above is risky and invites failure“ Dr. Winston W. Royce, US-amerikanischer Informatiker und Direktor am Lockheed Software Technology Center in Austin, Texas
Obwohl der weithin (und fälschlicherweise) als „Erfinder des Wasserfalls“ bezeichnete Dr. Winston W. Royce betont, dass er an das Wasserfallmodell glaube, führt er in seinem Artikel „Managing the Development of Large Software Systems“ (1970) neben den Vorteilen auch einige Risiken desselben auf.
Am Ende ist die Wahl des Arbeitssystems also eine Abwägung der mit dem jeweiligen System verbundenen Vorteile und Risiken. Die Details zum Wasserfallmodell gibt es hier.
In agilen Rahmenwerken wie Scrum gilt das Motto „Effektivität vor Effizienz“.
Zu allererst möchte Scrum dem Kunden immer genau die Produktfunktionen liefern, die ihm aktuell den größten Nutzen bringt. Passenderweise wird im Scrum Guide der Product Owner auch als „Wertmaximierer“ bezeichnet. Dahinter steht die Idee, dass es eine Person geben soll, deren wichtigste Aufgabe und größte Verantwortung es ist, ein in sich stimmiges und nah an den momentan dringendsten Bedürfnissen der Kunden und Stakeholder entwickeltes Produkt zu bauen. Dazu kommt, dass der Kunde schnell einen ersten Teil des Produktes in Händen halten soll, um zeitnah Wert aus dem entstehenden Produkt zu ziehen.
Mit diesem Ansatz will Scrum zunächst einen Effektivitätszuwachs erreichen, der so mit dem Wasserfallmodell nicht zu realisieren wäre.
Erst wenn der gewünschte Grad an Effektivität – nämlich zeitnah die aktuellen Kundenanforderungen zu erfüllen – sichergestellt ist, geht es um die Optimierung von Effizienz. Das zu verstehen ist essentiell wichtig für die Einführung von einem agilen Rahmenwerk wie Scrum.
… ein Stück weit bezahlt man die neu-gewonnene Effektivität durch geringere Effizienzwerte.
Comments