Jeder beruft sich gerne auf eine Expertenschätzung, denn mit ihr fühlt man sich gut beraten. Außerdem handelt es sich hier um eine Win-win-Situation: der Laie wird aussagefähig und der Experte kann mit seinem Know-how beeindrucken. Da Experten ihr Ruf voraus eilt, kann sich der Laie mit der Expertenschätzung bequem zurück lehnen, denn eine solche Schätzung gilt gemeinhin als belastbar.

Doch was, wenn die Expertenschätzung gar nicht der Weisheit letzter Schluss ist? Was, wenn die Kultur der Expertenbefragung ohne Kritik Bestand hat? Was, wenn vermeintliche Experten neuartige Probleme lapidar auf gemachte Erfahrungen reduzieren und damit der Komplexität der Fragestellungen und des tatsächlichen Kerns des Problems nicht hinreichend gerecht werden? Wieviel Aussagekraft hat die Expertenschätzung überhaupt noch, wenn dieser an der Umsetzung anschließend gar nicht beteiligt ist?

Oder konkreter:

• Ist „der Experte“ überhaupt einer?
• Kann es in Projekten überhaupt Experten geben, wenn Projekte doch in ihrem Kern stets die Lösung eines völlig neuartigen Problems haben? In Bezug auf dieses neuartige Problem ist folglich doch jeder ein Laie?
• Gibt es tatsächlich Experten für die Lösung komplexer Problemstellungen?

Die letzten Zeilen sollen zum Nachdenken anregen, den Expertenstatus grundsätzlich kritischer zu hinterfragen. Für den Moment gehen wir allerdings einmal davon aus, dass der betrachtete Experte im Vergleich zu den restlichen Protagonisten tatsächlich einer ist, also über mehr relevantes Wissen verfügt.

Ganz konkret betrachten wir die Problematik der Expertenschätzung in agilen Softwareprojekten.

Das Thema

Zuallererst möchte ich zu einem Paradigma Stellung beziehen, das in der agilen Softwareentwicklung hoch gehängt wird: einzelne Überflieger will man nicht, alles was zählt, ist das Team!

Das ist zwar eine tolle Maxime, die helfen soll, Kollaboration zu fördern, Wissen auf mehrere Köpfe zu verteilen und damit Risiken zu begegnen, aber sein wir mal ehrlich: In der Realität gibt es sie doch, die Überflieger. Und es ist gut, dass es sie gibt! Denn sie machen häufig den Unterschied zwischen einer adäquaten und einer guten Lösung. Es wäre widersinnig, sich den außergewöhnlichen Fähigkeiten dieser Leute nicht zu bedienen. Man muss das Rad nicht für jeden Teilaspekt der Lösung neu erfinden, wenn es doch jemanden gibt, der pragmatisch zeigen kann, wie es funktioniert.

Und bei allem Sendungsbewusstsein für Teamarbeit: wenn ein Projektmanager in kürzester Zeit eine Daumenschätzung für eine Anforderung abgeben muss, dann ist er gut beraten, sich den fähigsten Experten zu greifen und mit ihm die Schätzung durchzuführen. Das ist pragmatisch und häufig auch sinnvoll.

Nun ist der grade geschilderte, pragmatische Ansatz meist motiviert durch Zeitdruck und begrenzte Verfügbarkeit. Beides ist in Softwareprojekten traditionell zwar latent vorhanden, sollte durch ein professionelles Vorgehen und gutes Projektmanagement allerdings so weit abgemildert sein, dass sich vernünftige Alternativen auftun.

Denn es lauern Gefahren im Expertentum im Allgemeinen und in der Expertenschätzung im Speziellen.

Gehen wir einmal sogar davon aus, dass unser Experte ein wirklich „guter“ ist. Also sitzt er nicht allein in seinem Elfenbeinturm, sondern bemüht sich, zuvorkommend zu helfen und sein Wissen zu teilen, wenn sich ihm die Möglichkeit dazu bietet.

Das größte Problem mit diesen Experten ist, dass man sie nicht klonen kann und jeder etwas von ihnen will. Ist der Experte ein Softwareentwickler, wird seine Manpower häufig nicht ausreichen, um Softwaresysteme im Alleingang zu bauen. Weiterhin ist es aus Risikosicht nicht sinnvoll, auf Einzelkämpfer zu setzen, denn professionelle Softwareentwicklung sollte flexibel sein, auch was die beteiligten Personen angeht.

Kommen wir zur Schätzung. Der Experte wird in der Lage sein, seine zu erledigende Arbeit hinreichend abzuschätzen. Kennt er seine Kollegen, wird er vermutlich sogar deren Umsetzungsgeschwindigkeit abschätzen können. Problematisch wird es dann in der Umsetzung, denn er wird sich nicht in Ruhe seiner Arbeit widmen können. Schließlich ist er der Experte und jeder wird an ihm zerren. Und bevor er die Fehler erst im Review der umgesetzten Anforderungen findet, schaltet er sich lieber gleich bei der Entwicklung mit ein. Das ist zwar prima für das Ergebnis der Kollegen, aber sein eigener Workload bleibt liegen. Und schon ist seine Schätzung hinfällig. Macht es da nicht sogar mehr Sinn, seine Arbeitskraft gleich aus der Schätzung heraus zu rechnen?

Wenn man davon ausgeht, dass mehrere Leute zusammen an einer Lösung arbeiten, dann wird es vorkommen, dass sie Aufgaben anderer übernehmen. Selbst, wenn diese jeweils Experten auf ihrem Gebiet sind, werden sie es nicht auf dem Gebiet des Teamkollegen sein, für den sie Aufgaben übernehmen. Womit der Zustand der Expertenschätzung nicht mehr gegeben wäre.

Problematisch wird es in Schätzungen, wenn der Experte sich als solcher zu erkennen gibt, von anderen auch als solcher anerkannt wird, aber in Wirklichkeit keiner ist. Das muss nicht einmal böse Absicht sein. Wahrscheinlich hat er schlichtweg den Hintergrund des Problems nicht komplett durchdrungen und denkt lediglich, es falle in sein Spezialgebiet. In dem Fall ist seine Schätzung genau so wertvoll wie die anderer Kollegen. Jedoch mit dem Nachteil, dass aufgrund seines Expertenstatus kaum einer seine Schätzung in Frage stellen wird. So werden Probleme vorsätzlich nicht genauer hinterfragt und man merkt erst mitten in der Umsetzung, dass man Teilaspekte nicht berücksichtigt hat. Es wird also eine Sicherheit suggeriert, die nicht vorhanden ist. Löst man sich gar von der Meinung des vermeintlich vorhandenen Experten und hinterfragt das Problem mit unterschiedlichen Teammitgliedern, hat man die Chance, ein Verständnis für das Problem zu gewinnen, was einen anderen Experten hervor holt.

Tipps & Tricks

• Expertenschätzungen eignen sich für einen Daumenwert, der schnell und unkompliziert benötigt wird.
• Experten sollten im Team nicht die Rolle des einzelnen Überfliegers einnehmen, sondern die des Unterstützers des gesamten Teams. Er sollte keine Aufgabe im Alleingang bearbeiten, auch wenn das in Situationen unter Zeitdruck schwer fällt.
• Es sollten immer diejenigen Personen eine Schätzung abgeben, die auch für die Umsetzung zuständig sind, denn beim Vorgang der Schätzung wird Wissen generiert, das der Umsetzung zu Gute kommt.
• Schätzungen in der täglichen Entwicklung sollten im Team durchgeführt werden, um dem fehlgeleiteten Vertrauen in „falsche“ Experten vorzubeugen oder um gar den tatsächlichen Experten zu finden.

Fazit

Experten sind weder ein Allheilmittel noch sind sie abzuschaffen. Es gibt sie und man sollte in jeder Situation gut überlegen, wie man sie am effektivsten einbindet, ohne ihnen blind zu vertrauen. Ziel einer Schätzung ist es, Wissen zu generieren und auf mehrere Köpfe zu verteilen. Eine Expertenschätzung kann im Einzelfall hilfreich sein, dient aber nicht dem Wissensgewinn des Teams. Außerdem birgt die Expertenschätzung das Risiko der vermeintlichen Sicherheit und dem Unterschätzen einer Problemstellung.