Gut, schlecht, falsch, richtig, Fehler und Irrtum

Agilität (DE) Scrum Master (de)
1

Diese Worte hören wir oft und ich stelle hiermit die Hypothese auf, dass wir sie v. a. im Arbeitsalltag zu austauschbar nutzen. Diese Begriffe hängen natürlich zusammen und trotzdem sind die feinen Unterschiede in der Wahrnehmung bei der Arbeit mit Menschen wichtig. Denn Worte machen Wahrheit (noch so ein Begriff).

Schauen wir uns zunächst eine Definition an: “Ein Fehler ist die Abweichung eines Zustands, Vorgangs oder Ergebnisses von einem Standard, den Regeln oder einem Ziel”. Oder auch anders ausgedrückt ist ein Fehler ein “Merkmalswert, der die vorgegebenen Forderungen nicht erfüllt”.

Unter diesen Voraussetzungen ist beispielsweise ein Vertipper ein Rechtschreibfehler. Es ist eine Abweichung von einem Rechtschreibstandard. In der Mathematik ist ein falsches Ergebnis ein Rechenfehler. Es ist eine Abweichung von einem erwarteten Ergebnis. Eine solche Abweichung sind auch Softwarefehler. War die Anforderung ein blauer Button und geliefert wird ein gelber, dann ist das ein Fehler. Der Button entspricht nicht dem vorgegebenen Ziel.

In allen Fällen ist das Ergebnis falsch und wir haben einen Fehler gemacht. Geprägt aus der Schule und von diversen Rechtschreibprüfungen bringe ich Fehler meist in Zusammenhang mit der Signalfarbe “rot”. Und rote Hinweise machen mich bis heute nervös und ich fühle mich schlecht dabei. Es fühlt sich nach drohender Strafe und Maßregelung an.

“Der Irrtum [dagegen] bezeichnet im engeren Sinne eine falsche Annahme oder Meinung […], wobei der Behauptende, Meinende oder Glaubende jeweils das Falsche für richtig hält. […] ein Irrtum [entsteht] unabsichtlich aus falschen Informationen oder Fehlschlüssen”.

So gesehen kann eine Erzählung über ein vergangenes Ereignis Irrtümer enthalten, da zeitliche Zusammenhänge durcheinander kamen. Bei einer Wegangabe kann sich eine Person geirrt haben, da sie den eigenen Standort oder eine Abbiegung verwechselt hat.

Auch in diesen Fällen ist das Ergebnis falsch. Passiert es mir persönlich, fühle ich mich durchaus noch schlecht. Allerdings bei Weitem nicht so stark und lange wie bei einem Fehler.

:gift: Und was dies alles mit Entscheidungen und Schätzungen zu tun hat, kannst Du auf Gut, schlecht, falsch, richtig, Fehler und Irrtum | Marco Spörl - Freiberuflicher Teamcoach weiterlesen.

2

Mir gefällt, dass du das Thema Schätzen als Beispiel nimmst.

So gesehen irren wir uns doch nur von Sprint zu Sprint (oder Iteration zu Iteration, um mal allgemein zu sprechen).

Je höher die Dynamik, desto kürzer müssten die Intervalle werden. Meine innere Logik - die Ihr gerne challengen dürft - sagt mir gerade, dass es einen Grenznutzen gibt. Also der Nutzen von Schätzungen irgendwann nicht mehr haltbar ist, weil die Kosten / Aufwände des Schätzens eben den Nutzen immer mehr übersteigen.

Stichwort #noestimates-Bewegung?

Die Kanban-Welt macht seit vielen Jahren vor, wie mit statistischen Methoden (Monte Carlo, ick hör dir trapsen) die Forecast Probability gesteigert werden kann. Eben weil Statistik auf Basis der Empirie zum Einsatz kommt.

Aber auch da frage ich mich oftmals: Ab wann ist der Punkt erreicht, ab dem auch hier die Aufwände der Schätzung den Nutzen übersteigen?

Immerhin “ganz einfach” berechnet ist der Forecast nach Serviceklasse eines Work Items und der statistischen Schätzung: Tickets in Serviceklasse X dauern in der Regel zwischen N und M Tagen, bis sie erledigt werden.

So gewöhnt man den Stakeholder auch gleich mal daran, dass eine Schätzung auch nur ein Korridor und damit ungenau ist. :slight_smile:

Und doch darf die andere Seite nicht vergessen werden: Schließlich ist es legitim, wissen zu wollen, für was mein Investment genutzt wird. Ob ich den Return (also den Value) bekomme? Sehe ich ja erst hinterher. :slight_smile:

Daher sind schnelle, kleine Feature-Änderungen mit direkter Delivery an den Nutzer wichtig, um auf dieser Basis weitere Business-Entscheidungen treffen zu können.

Das bedeutet, dass die Budget-Verantwortlichen näher an das Produkt gebracht werden müssen. Und auch hier gibt es einen Grenz-Nutzen (die verfügbare Zeit der Budget-Verantwortlichen), aber der dann vielleicht scheibchenweise das Geld wegdelegiert wird hin zur unmittelbaren Nähe des Produkt-Teams, um dort Teile der Budget-Entscheidung oder die Budget-Entscheidung als ganzes zu treffen.

Oder?

1 Like
3

Grenznutzen ist an der Stelle ein schöner Begriff.

Meine aktuelle Sichtweise ist ja, dass “Das Projekt” und die damit verbundene Denke noch zu stark in den Köpfen ist. Selbst ein befreundeter, agil-geneigter Producer hat mit mir die Tage wieder diskutiert zum Thema “na, aber ich muss doch wissen, wann was fertig wird.” Was eine berechtigte Frage ist und die folgende Diskussion darauf ehrlich eingeht - eben mit Indikationen, Korridoren, Unsicherheiten, etc.

Und apropos Fragen zum ganzen Thema Schätzung - Einfach mal fragen, wozu die Schätzung gut sein soll bzw. gebraucht wird. Da kommen oft spannende Ansätze raus.