In der traditionellen Planung wird versucht, die Auslastung der „Ressourcen“ zu optimieren: Die Idee ist, dass man dann am effizientesten arbeitet, wenn jeder voll ausgelastet ist.

Agile Planung versucht Ergebnisse zu optimieren: Das Team bemüht sich, zunächst die wichtigsten Aufgaben abzuschließen, dann die nächst-wichtigen usw. Man konzentriert sich also darauf, Aufgaben abzuschließen, anstatt darauf, Aufgaben anzufangen.

Durch die Optimierung der Ergebnisse ist die Anzahl der zugleich bearbeiteten Aufgaben niedriger, es sind weniger Abstimmungen und Kontextwechsel notwendig, das Team erledigt insgesamt mehr Aufgaben. Die Auslastung einzelner Entwickler mag zwar gelegentlich geringer sein, als bei Auslastungsorientierter Planung – wie auch die Auslastung der Flugbegleiter in meinem gestrigen Eintrag. Aber der Geschäftsnutzen ist größer. Und darauf kommt es an.

Wer die Koordination der Flugbegleiter beim Service auf einem Kurzstreckenflug beobachtet, kann ein schönes Beispiel globaler Optimierung entdecken: In dem engen Mittelgang hat nur ein Servicewagen Platz, überholen ist ausgeschlossen. Oft beginnt die erste Flugbegleiterin in Reihe 1 mit ihrem Service und arbeitet sich voran. Sobald der Kollege seinen Wagen bereit hat und aufschließt, überspringt die erste Kollegin einige Reihen, in denen der Kollege dann den Service übernimmt. Das ist zwar sehr naheliegend, zeigt aber, dass hier erst globale Optimierung ein vernünftiges Ergebnis bringt: Würde die erste Kollegin einfach „schneller“ bedienen, sprich ihre eigene Effizienz optimieren, wäre ihr Kollege arbeitslos, die Aufgabe, alle Passagiere zu versorgen wäre in der gebotenen Zeit nicht zu schaffen. Sie muss ihre Arbeit für zwanzig oder dreißig Sekunden einstellen – also ineffizienter werden – damit der Kollege wiederum mit seiner Arbeit beginnen kann.

Warum ich darüber schreibe? Genau das zweite Verhalten, die operative Hektik, sehe ich immer wieder in der Softwareentwicklung: Wenn Entwickler versuchen, ihre persönliche Aufgabe durch Überstunden und besonders „schnelle“ Arbeit so schnell wie möglich „abzuschließen“, geht das in der Regel auf Kosten der Qualität. Nachfolgende Tester oder Entwickler, die später den Code ändern müssen, sind die Leidtragenden, weil ihre Arbeit schwieriger wird. Und vor allem sind die Kunden die Leidtragenden, die nicht selten durch irrationalen Druck gehörige Mitverantwortung tragen. Diese operative Hektik ist nicht einmal Egoismus, weil das sogar den Entwickler selbst treffen kann. Es ist simple Kurzsichtigkeit.

Das gleiche gilt für Tester, die neue Features nicht testen, sobald sie bereit stehen, sondern erst, wenn der Test „an der Reihe ist“. Und natürlich für Manager, die solches Verhalten oft nicht nur dulden, sondern sogar fördern und belohnen.

Warum sind Flugbegleiter dabei so viel besser? Sie trainieren in mehreren Iterationen täglich in ständig wechselnden Teams. Sie haben den direkten Kundenkontakt, der bei ineffizientem Service deutliches Feedback ermöglicht. Und sie haben die notwendige Prozessfreiheit, den Vorgang immer weiter zu optimieren.

Iterationen, direkter Kundenkontakt und Retrospektiven helfen bei agiler Entwicklung, global zu optimieren, anstatt die Mitarbeiter in operativer Hektik auszubrennen.