Direkt zum Hauptbereich

Die komprimierte Zeit in Hirn und Projekt

Schon wieder (fast) zu spät? Schon wieder den Termin für zugesagte Tätigkeiten nur mit Müh und Not eingehalten? Es könnte am hier beschriebenen Phänomen liegen...

Kürzlich hatte ich wieder einmal das Vergnügen, wenn auch nur kurz, mit Jan zu telefonieren. Ich hatte mich per SMS gemeldet und noch kalkulierte zehn Minuten Zeit vor Aufbruch zu meiner Osteopathiestunde, als er zurückrief. Im Laufe des Gesprächs notierte Jan, ich solle doch JETZT gleich losfahren, denn das Gehirn komprimiere Zeiten bei der mentalen Vorstellung von geplanten Aktivitäten, das sei wissenschaftlich erwiesen. Ich bestätigte "ja, ja" (ich würde angeblich losfahren), und wir beendeten das Gespräch.

Das Hirn lässt mal wieder einfach weg...

Diese interessante Information erklärte mir nicht nur auf einen Schlag, was mein eigenes Problem seit Kindesbeinen an ist ("immer auf den letzten Drücker..."), sondern auch das vieler Projekte und Initiativen. Hintergrund ist eine Effizienzsteigerung bei der Verarbeitung von Informationen im Hirn, die aber leider manchmal aufs zeitliche oder auch ein anderes Glatteis führt. Um Ressourcen zu sparen, lässt das Gehirn bestimmte Informationen unter den Tisch fallen und füllt sie nur bei Bedarf aus anderer Quelle wieder auf. Bei der mentalen Repräsentation von zeitlichen Vorgängen scheint nach und nach so einiges wegzufallen, wenn man der Wissenschaft trauen darf.

Gedankliche zeitliche Komprimierung in Projekten und Initativen

Bei agilen Initiativen kennt man die Herausforderung bei den auf Wochenfrist heruntergebrochenen Arbeitsbrocken, diesen sogenannten User Stories: Ständig werden sie zu groß geschnitten, und hinterher, wenn am Sprintende, dem Ende des laufenden Entwicklungszeitraums, noch ganz viel Story übrig ist, merkt man, dass man sich da mit dem Aufwand irgendwie wieder getäuscht hat. Weil der zeitliche Aufwand der einzelnen Stories unterschätzt wird, nimmt man sich auch heraus, gleich am besten drei von ihnen anzufangen, weil man sich sicher ist, dass man sie im aktuellen Entwicklungszeitraum erledigen kann.

Burn down chart als Spiegel

Oder vielleicht wurde jeder, der einmal in einem typischen solchen Umfeld gearbeitet hat, auf die eine oder andere Art dazu gezwungen, wenigstens einmal einen Blick auf das in Jira bereitgestellte "burndown chart" zu werfen, eine grobe Orientierung des Abarbeitungsgrades im eigenen Team pro Zeiteinheit/Sprint mit der Arbeit auf der Y-Achse und dem Zeitverlauf auf der X-Achse. Meist handelt es sich zunächst um eine endlos lang waagerecht verlaufende Linie (= null Abarbeitung bzw. Fertigstellung, denn nur, was fertiggestellt und nutzbar ist, gilt nach diesem Konzept als "abgearbeitet"), die am Ende, wenn auch der Sprint endet, quasi senkrecht nach unten abstürzt. Eventuell, indem man einige Arbeitspakete, die diffus genug umrissen waren, noch schnell uminterpretiert hat. Im agilen Bilderbuch verläuft diese Linie selbstverständlich als eine sich etwa stetig diagonal der Zeitachse nähernde und diese am Sprintende treffende Kurve.

Traumvorstellung und Realität

Als ich nun also das Haus verließ, um mit dem Fahrrad zu meinem Termin zu fahren, zeigte mir das Schicksal auch sogleich einen lebhaften Beweis dessen, was ich gerade erfahren hatte. Zugegebenermaßen war ich ohnehin schon wieder auf den letzten Drücker unterwegs, weil ich - am 31.01. - "noch schnell" meine Zeiten im System des Kunden gebucht hatte, um nicht nach meiner Rückkehr am frühen Abend nochmals dienstlich an den Rechner zurückzumüssen. Mir bot sich ein hervorragendes Delta zwischen meiner Vorstellung der Fahrt und der Realität. In meiner Vorstellung war ich einfach in die Garage gerast, um mein Fahrrad zu schnappen und loszufegen. In Realität stand ich da und musste mein Fahrzeug erst einmal freilegen, weil es unerwarteterweise durch zwei Fremdräder zugeparkt war, der Durchgang war dadurch kaum noch begehbar, und natürlich blieb ich auch mehrfach irgendwo hängen. Aus der in meinem Geiste rasanten und sportlichen Fahrt zur Osteopathiepraxis wurde in Wahrheit ein Ausbremsmanöver, bei dem ich bereits auf dem ersten Streckenabschnitt bergab meinen bis dahin aufgebauten Schwung verlor, weil es fast unmerklich nieselte und ich den deutschen Autofahrern, die allesamt ständig auf der Bremse standen, mit meinem Fahrrad mehrfach fast in den Kofferraum fuhr. Acht Minuten später kam ich mit hängender Zunge an der Praxis an und war wiedermal gerade noch rechtzeitig.

Komprimierte Lernfähigkeit?

Immerhin war meine Hirnleistung nicht so komprimiert, als dass ich mich nicht darüber gewundert hätte, dass ich ja die Wahrnehmung dieser wissenschaftlichen Erkenntnisse in meinem Leben schon unzählige Male gehabt, daraus aber trotzdem bis heute nicht gelernt habe. (Ich werde eine empirische Studie starten, ob das Bewusstsein der wahren Hintergründe für ständige Fast-Verspätungen in terminreichem Leben etwas zum Besseren wendet.) Immerhin war mir vor so mancher Abreise immer mal schon gedämmert, dass ich früher als gedacht losfahren sollte, weil ja z. B. auch ein Müllwagen das Fortkommen behindern könnte. (Mir ist es tatsächlich auch schon passiert, dass ich bereits unter Zeitdruck in einer Straße mit dem Auto weder vor noch zurück kam, dazu verdammt, die Müllabfuhr mit ihrem ausladenden Wagen vor mir dabei zu beobachten, wie sie in aller Seelenruhe an der Straße stehende Mülltonnen entleerte.)

Puffer sind wahrscheinlich gerechtfertigter als gedacht

Nach dem Gespräch mit Jan erkannte ich auch, dass häufig hinter vorgehaltener Hand vollzogene Projektaktivitäten - ob in klassischen oder agilen Projekten, ist dabei völlig egal - den genannten Erkenntnissen wahrscheinlich Rechnung tragen. Wer kennt sie nicht, die subtil gerümpften Nasen, wenn man bekennt, dass man bei der Aufwandsschätzung für eine Tätigkeit noch einen kleinen Puffer eingebaut hat? Schnell wird man womöglich abgestempelt als Faulpelz, der sich mit einer Mondschätzung für Nasebohren selbst den Rücken freihalten will, und man gerät in einen unheilvollen Rechtfertigungsstrudel - aber sollten wir aufgrund dieser nicht bewussten zeitlichen Komprimierung von Vorgängen, die unser Hirn vornimmt, nicht viel häufiger völlig selbstbewusst diesen kleinen Puffer einrechnen, wenn wir jemandem eine Aufwandsschätzung für unsere Tätigkeiten geben?

Von ungetaner Arbeit, die hätte getan werden sollen

Vielleicht würde das Projekt dann teurer, ziemlich sicher sogar, aber es gäbe auch nicht diese bösen Überraschungen, wenn am Ende des (ersten) bewilligten Budgets plötzlich noch so viel ungetane Arbeit übrig ist, und wir reden hier nicht von der "ungetanen Arbeit, die maximiert werden sollte" aus dem agilen Sprichwort, sondern von der, die eigentlich hätte getan werden müssen.

Die wissenschaftliche Erkenntnis sollte uns allen helfen, unsere eigenen Aus-dem-Bauch-Schätzungen noch einmal gründlich zu hinterfragen und nach Stellen zu fahnden, die unser Hirn aus Effizienzgründen einfach "weggeöscht" haben könnte. Oder im richtigen Moment an einen verhältnismäßigen zeitlichen Puffer zu denken...


Verwendete Quelle:

https://www.dzne.de/im-fokus/meldungen/2022/warum-uns-unser-gedaechtnis-manchmal-taeuscht/

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.