In den Frühzeiten agiler Entwicklung wurde mir einmal während einer Podiumsdiskussion über Entwicklungsprozesse aus dem Publikum die folgende Frage gestellt: „Sie propagieren die schnelle Reaktionsfähigkeit und die Anpassungsfähigkeit an den Markt. Das klingt sehr schön, aber wir müssen Produktplanungen über die nächsten fünf Jahre vorlegen. Wie können Sie das mit agiler Entwicklung tun?“ Ich war neugierig geworden, welche Branche so lange Zukunftsperspektiven nicht nur ermöglicht, sondern offensichtlich einzufordern scheint und so fragte ich erst nach, aus welcher Branche der Fragesteller denn käme. Die Antwort erregte allgemeine Heiterkeit: „Wir bauen Handys.“

Ich empfahl dem Fragesteller, die derzeitigen Prozesse unbedingt beizubehalten, sollte es ihnen tatsächlich gelungen sein, vor fünf Jahren vorherzusehen, dass der SMS-Versand von Jugendlichen die wichtigste Einnahmequelle der Mobilfunkbetreiber werden würde – zu dieser Zeit war der SMS-Service noch keine fünf Jahre alt.

Der Handyhersteller ist übrigens mittlerweile insolvent, unter anderem, weil er sich am Markt nicht schnell genug bewegt hatte.

Stefan Hagen hat in seinem „Projektmanagement Blog“ eine Folie bereitgestellt mit den „Bestandteilen eines Projektplans„. Die Folie enthält unter anderem 18 Teilpläne, einschließlich „Arbeitspaketdefinitionen“ und „Terminplan (GANTT)“.

Aus agiler Sicht erscheint das eher schwergewichtig. Anstatt festzulegen, welche Pläne gebraucht werden, diskutiere ich lieber die Ziele einer Planung:

• Das Team auf die wichtigen Aufgaben fokussieren
• Zusammenarbeit koordinieren
• Vorhersagen über Fertigstellungstermine ermöglichen
• Transparenz über den Projektstatus schaffen

Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Weiterlesen →

Ein wichtiges Argument für agile Entwicklung ist, dass man flexibel auf Änderungen der Umstände reagieren kann. Viele Manager befürchten allerdings, dass sie diesen Vorteil auf Kosten der Planbarkeit erkaufen müssten. Gerade bei Produkthäusern verlangen Kunden und Investoren möglichst zuverlässige Aussagen, wann welche neuen Produktmerkmale oder Marktstrategien zur Verfügung stehen. Stört hier agile Entwicklung?

Ich meine, dass agile Planungspraktiken ganz im Gegenteil sogar helfen, solche langfristigen Planungsaussagen nicht nur zu treffen, sondern dann auch noch einzuhalten. Allerdings muss man dafür eine zusätzliche Planungsebene einführen, nennen wir sie strategische Planung (oder Roadmap, falls Ihnen Anglizismen besser gefallen). Anders als alle anderen Planungsebenen in einem agilen Vorhaben, geht der Horizont der strategischen Planung nicht nur über die anstehende Iteration, sondern über die nächsten 18 oder 24 Monate – mehr ist in der Regel nicht mehr seriös planbar.
Weiterlesen →

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.