Willkommen

Diese Webseite befindet sich noch im Aufbau – eigentlich ist es eher ein Minimum Viable Product (MVP), das jetzt weiter ausgebaut wird. Oder eben eher MVH – Minimum Viable Homepage.

Für Informationen zur Vorlesung IT-Management, steht der Bereich „Dozent“ schon bereit.

Fazit 10 Minuten Blog

Das ist der letzte Artikel in dieser Serie im 10 Minuten Blog. 35 Artikel habe ich in jeweils 10 Minuten geschrieben und dabei ein paar meiner Gedankengänge ins Internet gestellt.

Eine Idee dabei war, endlich einfach mal auf veröffentlichen zu klicken. Tendenziell will ich, dass alles was ich veröffentliche auch wirklich perfekt ist. Also bastel ich ewig daran rum und dann veröffentliche ich es im schlimmsten Fall gar nicht. Die Aufgabe war deshalb ganz klar: 10 Minuten schreiben und dann direkt auf Veröffentlichen klicken. Gut, den letzten Satz hab ich noch zu Ende geschrieben, wenn der Timer geklingelt hat 😉

Tatsächlich bin ich doch fasziniert, wie viel ich in 10 Minuten runterschreiben kann. Gleichzeitig wurde schnell klar, das funktioniert nur mit kleinen Themenausschnitte, weil nichts tiefergehend behandelt werden kann. Auch wenn ich schon häufig darüber gesprochen habe ist es deutlich einfacher, denn dann muss ich nur drauf losschreiben.

Das Feedback war durchweg positiv und ich freue mich sehr damit endlich losgelegt zu haben.

Es muss ja auch nicht immer alles perfekt sein. Auch eine Diskussion, welche durch eine ungünstige Formulierung angestoßen wird kann ja durchaus wertvoll sein. Logisch betrachtet wusste ich das natürlich auch vorher. Jetzt hab ich es einfach mal ausprobiert. Und es funktioniert.

Das Schreiben macht mir wirklich Spaß. Ungünstig ist, dass die Bilder und die Texte für Social Media so lange dauern. Das Posten war nicht Teil der Aufgabe und so habe ich das nur nach Lust und Laune nebenher gemacht und war immer wieder im Verzug. Nur fast alle Leser kommen bei mir über Social Media. Also lohnt sich das halt schon.

Jetzt mache ich erstmal eine Pause beim bloggen und danach werde ich ein paar Themen etwas tiefergehend beleuchten. Eine Idee war auch, die Vorlesung IT-Management in Form einer Blogartikelserie aufzuarbeiten. Dann dient das den Studenten als Skript und alle interessierten können sich auch genauer über die Themen dort informieren. Das geht dann halt deutlich über die Folien und die Notizen dazu hinaus.

Warum Scrum nicht agil ist

Scrum ist das mit Abstand beliebteste Framework im agilen Kontext. Viele glauben sogar, Agile und Scrum sind das gleiche, was natürlich nicht der Fall ist. Scrum wird insbesondere durch den Scrum Guide definiert, welcher kostenlos auf scrumguides.org zu finden ist.

Agile vs. Scrum

Agile leitet sich aus dem Manifest für Agile Softwareentwicklung ab (siehe agilemanifesto.org). Dort wird zentral Wert darauf gelegt, dass Individuen und Interaktionen mehr geschätzt werden als Prozesse und Werkzeuge. Jetzt wird Scrum natürlich gerne als Framework bezeichnet und gleichzeitig beinhaltet es sehr feste und konkrete Regeln im Scrum Guide, welche Prozesse (z.B. Planungsprozesse) und Werkzeuge (z.B. Product Backlog) definiert.

Das ist natürlich total sinnvoll, da es natürlich hilfreich ist, wenn man sich mit etwas neuem beschäftigt, auch konkret etwas an die Hand zu bekommen. Wenn da nicht seit jeher der letzte Absatz (Schlussbemerkung) im Scrum Guide wäre, welcher sehr deutlich sagt, dass die Werkzeuge (Artefakte) und Regeln unveränderlich sind. Natürlich können die Regeln geändert werden, nur dann ist es eben nicht mehr Scrum. Das steht da extra so drin.

Wie passt das jetzt zusammen? Agile fordert, dass wir uns anpassen und Scrum verbietet explizit die Anpassung. Scrum ist also nicht agil. Dabei gibt es viele Gründe Scrum anzupassen. So funktioniert Scrum z.B. nur mit einem Team von bis zu 9 Entwicklern. Wenn mehr dabei sein sollen, lässt sich Scrum nicht mehr einsetzen. Es mag auch andere Praktiken geben, die für ein Team besser geeignet sind als die in Scrum, um den gleichen Nutzen zu erzielen, wie die Scrum-Praktiken. Das verbietet Scrum augenscheinlich. Scrum ist also definitiv nicht agil.

Scrum und Agile

Nur warum finden dann alle Scrum so toll? Warum glauben viele sogar, Scrum ist das gleiche wie Agile?

Ich finde Scrum toll und zwar weil es ein großartiger Startpunkt für das Thema Agile ist (sofern Produkte entwickelt werden). Es definiert so viele Regeln und Praktiken, dass jemand der gerade damit startet etwas hat, woran er sich festhalten kann. Das ist sehr hilfreich. Wenn das Team jedoch eigene Erfahrungen hat und tatsächlich agil wird (statt agil zu machen, denn das geht nicht), dann wird es anfangen eigene Regeln aufzustellen und damit die Individuen und Interaktionen in den Vordergrund stellen. Dann ist es vielleicht nicht mehr Scrum, nur das macht ja nichts. Scrum war der richtige Startpunkt.

Deshalb sage ich gerne: Scrum ist ein ganz toller Startpunkt. Teams die dauerhaft Scrum machen, sollten hinterfragen, ob sie sich wirklich kontinuierlich verbessern und anpassen. Es ist nichts schlimmes daran, nicht mehr Scrum zu machen. Meiner Erfahrung nach wachsen alle Teams irgendwann darüber hinaus.

Priorität vs. Reihenfolge

Ich habe in einem bestimmten Kreis von Leuten mehrfach die Erfahrung gemacht, dass ich gesagt habe, dass es wichtig ist Prioritäten zu vergeben und mir haben alle zugestimmt. Dennoch war das Ergebnis immer wieder, dass nicht wirklich klar, was jetzt als erstes gemacht werden soll. Das an sich verwundert mich natürlich nicht, ich weiß ja, wie schwer es vielen fällt Prioritäten zu setzen und damit letztlich auch Verzicht zu üben.

An der Reaktion der Leute fand ich allerdings komisch, dass sie nicht ausweichen, wenn ich von Prioritäten spreche und dann ja auch zustimmen, dass das erforderlich ist. Es hat eine Weile gedauert bis ich herausgefunden habe was das Problem war. Mir wurde zugestimmt, weil es natürlich sehr wichtig ist Prioritäten zu vergeben. Gleichzeitig ist ja ganz klar, dass das was auf der Liste steht, alles besonders wichtig ist. Also wurden ja Prioritäten vergeben. Meine Aussagen bezüglich Prioritäten sind deshalb völlig verpufft, weil mein Gegenüber der Meinung war, er hat ja schon priorisiert: ist alles wichtig, sonst würde es nicht angefordert. Wenn genau das alles gemacht wird, haben wir uns auf das wichtigste fokussiert.

Deshalb fällt mir in letzter Zeit der Begriff Priorität in meiner eigenen Sprache immer wieder auf und ich habe angefangen, stattdessen manchmal Reihenfolge zu sagen: „Wir brauchen hier eine klare Reihenfolge“. Damit kann ich dieses Missverständnis umgehen. Natürlich ist Reihenfolge und Priorität nicht das gleiche, deshalb kann es auch nicht grundsätzlich ersetzt werden. Nur gerade wenn jemand nicht so in der Agile-Welt unterwegs ist, die DEEP-Eigenschaften eines Backlogs nicht kennt und auch keine Erfahrungen mit priorisieren von Anforderungen im agilen Sinne hat, ist das in manchen Situationen viel einfacher verständlich.

Nachhaltige Fortbildungen

Es gibt eine riesige Trainingsindustrie, welche den Menschen hilft mehr zu Wissen. Es gibt z.B. Projektmanagementseminare, in denen die Teilnehmer das Wissen von Projektmanagement vermittelt bekommen.

Wissen alleine Hilft nicht

Die Anwendung ist das Entscheidende. Der frisch Wissensvermittelte Projektleiter findet plötzlich ein echtes Unternehmen vor, mit echten Menschen und nicht nur Rollen auf dem Papier. Dazu kommen ganz viele (Sonder-)Fälle, welche in der Theorie nicht behandelt wurden. Die Anwendung des Wissens klappt aus seiner Sicht nicht und überhaupt ist dafür keine Zeit.

Wenn extrem übergewichtige Menschen abnehmen wollen, wissen sie, dass sie sich gesünder ernähren und mehr bewegen sollten. Dennoch nehmen sie häufig nicht ab und verhalten sich nicht entsprechend dem, was sie wissen. Da spielen z.B. Gewohnheiten, die Eigenschaften und die Persönlichkeit mit rein, welche ggf. ein anderes Verhalten basierend auf dem Wissen verhindern. Verhalten das über Jahrzehnte antrainiert wurde wird nicht durch ein bisschen Wissen überschrieben.

Natürlich ist ein erster Schritt, überhaupt zu Wissen, dass es eine Option gibt sich anders zu verhalten. Die Wissensvermittlung kann also ein sinnvoller erster Schritt sein. Ich habe nichts gegen Trainings und Wissensvermittlung. Nur dann ist es wichtig, daraus auch was zu machen und das ist eben kein Automatismus.

Von der Theorie zur Praxis

Bezüglich Programmierung z.B. gibt es immer wieder das Problem, dass jemand einen Kurs besucht zu einem Programmierthema und er oder sie dann das gelernte nicht auf den Code im Unternehmen übertragen kann, weil dann eben doch alles anders ist, andere Rahmenbedingungen da sind, der Zeitdruck dazu kommt, so dass keine Zeit ist neue Dinge auszuprobieren, usw.

Ein Thema, dem sich meine Mitarbeiter widmen wollten war Clean Code, wo es um gewisse Programmiertechniken geht. Hier habe ich einen großartigen Trainer für dieses Thema gefunden (Thomas Much) und mit ihm geklärt, dass ich eben nicht einfach eine Schulung diesbezüglich möchte, sondern mir wichtig ist, dass es auch zur Anwendung kommt. Unsere Lösung: Immer wieder mal einen Workshop, in dem ein kleines Prinzip vermittelt wird und dann gehen alle zurück an den Arbeitsplatz und wenden es gemeinsam mit Thomas am eigenen Code an (Pair und Mob Programming). Anschließend nimmt sich die Gruppe eine Änderung des eigenen Coding-Verhaltens bezüglich des Prinzips vor und beim nächsten Workshop werden die Erfahrungen damit reflektiert und ggf. aufgearbeitet. So haben sich die Programmierpraktiken des Clean Codes bei uns nachhaltig etabliert und die Codequalität steigt kontinuierlich mit jedem Workshop.

Leider sind die 10 Minuten schon wieder um. Es gibt natürlich noch viele andere Möglichkeiten von der Wissensvermittlung zur Anwendung zu kommen. Das ist für mich als Coach für Führungskräfte ein sehr wichtiges Thema. Denn nur das Ergebnis meiner Coachees zählt, nicht wie viel mehr sie nach meinem Coaching wissen.

Unabhängigkeit vom Arbeitgeber

Viele Unternehmen haben das Thema, ihre Mitarbeiter ans Unternehmen zu binden und viele Mitarbeiter haben das Thema sich unentbehrlich zu machen (z.B. durch Kopfmonopol). Ich finde es sehr wichtig, dass ich als Mitarbeiter unabhängig bin oder mich zumindest unabhängig fühle vom Unternehmen und dieses auch nicht abhängig von mir zu machen.

Wenn ich mich abhängig fühle von meinem Arbeitgeber, muss ich sicherstellen, dass mein Arbeitsplatz nicht gefährdet ist. Damit erschaffe ich mir selbst ein System, in dem ich eher Kompromisse und Nachteile meinerseits in Kauf nehmen muss. Das gilt allgemein als Mitarbeiter und häufig habe ich den Eindruck, es gilt besonders in meiner Rolle als Führungskraft. Es ist mir sehr wichtig, dass ich dem Unternehmen gegenüber eine entsprechende Durchsetzungsfähigkeit habe und damit auch die Wünsche meiner Mitarbeiter besser durchsetzen kann. Mir kann keiner damit drohen, dass ich sonst meinen Job verliere, weil ich nicht darauf angewiesen bin. Es gibt Grenzen die nicht überschritten werden dürfen und das muss ich durchsetzen können. Im Zweifelsfall verhindere ich den Grenzübertritt, indem ich mich dem Zugriff des Unternehmens entziehe.

Manchmal frage ich, wenn jemand über seinen Arbeitgeber jammert: „Wie schlimm muss es noch werden, damit du kündigst?“. Häufig ist die Antwort, dass eine Kündigung wegen der Abhängigkeit ja keine Option ist. Jemand der abhängig ist, ist bereit viel mehr zu tolerieren, als jemand der sich unabhängig fühlt.

Die klassischen Führungskräfte finden das natürlich toll, wenn der Mitarbeiter abhängig ist. Da können sie mehr Druck ausüben. Nur so geht der aus meiner Sicht nicht. Ich will explizit, dass meine Mitarbeiter Spaß an der Arbeit haben und motiviert sind. Jemand der nur wegen der Abhängigkeit nicht geht, leistet doch niemals so gute Arbeit wie jemand, der voll motiviert bei der Sache ist. Sie sollen da bleiben, weil sie einen Sinn und Freude in ihrer Arbeit sehen. Wenn die Arbeit erfüllend ist, entfaltet das extrem viel mehr Energie, als wenn es eine üble Notwendigkeit ist.

Dann sind die Mitarbeiter auch bereit mal Dinge hinzunehmen die nicht so toll sind. Natürlich hab ich schon Momente erlebt, in denen ich mir konkret die Frage gestellt habe: „Ist das der Moment, in dem ich die Kündigung schreibe?“, bzw. im Grunde genommen, ob das die Grenze überschreitet. Bisher war das nicht der Fall und ich konnte aus den Situationen jeweils das Beste machen. Ich bin mir sicher, dass das auch daran liegt, dass ich mich traue die Dinge einfach anzusprechen, zu thematisieren und dem Nachdruck zu verleihen. Weil ich eben keine Angst vor Konsequenzen für meinen Job haben muss.

Dankbarkeit für kleine Erfolge

Eine Eigenschaft die mich auszeichnet ist, dass ich sehr schnell Probleme erkenne und dann Lösungen dafür finde. Das ist als Coach und Berater sehr praktisch, da ich ein gutes Gespür für die entscheidenden Themen habe. Als Führungskraft muss ich jedoch aufpassen, dass ich nicht aus den Augen verliere, was eigentlich schon erreicht wurde.

Es hat eben alles Vor- und Nachteile. Wenn ich die kleinen Erfolge auf dem Weg immer in den Vordergrund stelle, nimmt die Motivation ab weiter zu machen, weil nicht so klar ist, wie groß der Schmerz immer noch ist, weil wir eben noch nicht angekommen sind. Wenn ich allerdings immer nur darauf hinweise, wo noch überall Probleme sind, kommt Frust auf, weil nicht das Gefühl entsteht vorwärts zu kommen. Das ich immer das Gefühl habe es geht alles zu langsam macht es natürlich nicht gerade besser.

Deshalb nehme ich mir immer wieder mal bewusst ein bisschen Zeit zu reflektieren, was eigentlich alles schon erreicht wurde. Auch mit dem Team zusammen, so dass wir eben auch sehen können, dass wir schon weit gekommen sind. Hier brauche ich auch niemand besonders loben, das Ergebnis motiviert (siehe auch den vorigen Artikel Teamerfolge feiern). Darauf aufbauend stelle ich immer wieder sicher, dass wir eine geteilte Vision davon haben, wo wir hin wollen, was wiederum motiviert. Das basiert dann auch darauf, von wo wir weg wollen.

Insgesamt werden also sowohl Teammitglieder motiviert, die eher durch Probleme motiviert sind (also sich von dem aktuellen Zustand wegbewegen wollen), als auch diejenigen, die eher durch große Ziele motiviert sind (also hin zu einem neuen Zustand). Zusätzlich natürlich auch alle, die beides motiviert, denn so schwarz / weiß ist Motivation ja auch nicht 😉

Teamerfolge feiern

Ein Thema was glaube ich immer wieder übersehen wird ist, die Erfolge der Mitarbeiter wahrzunehmen und entsprechend zu würdigen / feiern. Ich bin noch gar nicht genauer darauf eingegangen in diesem Blog – Bonuszahlungen und so sind nicht gut. Der ist hoffentlich eh schon bei dir angekommen. Ansonsten darf ich das Thema auch nochmal aufarbeiten. Wenn ich von würdigen und feiern rede meine ich also genau das und nicht eine finanzielle Belohnung. Einfach mal „Danke“ und „gute Arbeit“ sagen wirkt Wunder.

Interessant finde ich das im Kontext der Linienführungskraft. Natürlich wird vom Chef erwartet, dass er sagt, wenn gute Arbeit geleistet wurde. Gleichzeitig möchte ich mich nicht zu sehr Teil des Systems machen. Ich möchte wirklich nicht, dass meine Mitarbeiter immer genau tun was ich sage, oder was sie denken, was ich von ihnen erwarte. Es ist mir wichtig, dass sie für unsere Kunden tun, was echten Mehrwert hat. Um meine Bedürfnisse und Wünsche sollte es nicht gehen. Ich bin nur dafür da, die Kollegen dabei zu unterstützen. Wenn sie nicht das tun was ich erwarte, ist das Feedback an mich und ich darf herausfinden, warum das eine bessere Option für sie war.

Deshalb ist Lob (ernstgemeintes Feedback) ein zweischneidiges Schwert in dieser Konstellation. Gerne drücke ich meinen Dank und meine Freude über das erreichte Ergebnis aus, gleichzeitig möchte ich nicht, dass meine Anerkennung der Maßstab wird. Durch das Machtverhältnis ist nur gerade das die Gefahr. Schließlich verteile ich die Gehaltserhöhungen…

Auf einer Konferenz habe ich mal gesagt, dass ich vorsichtig im Umgang mit Feedback bin (aus dem oben genannten Grund) und wurde direkt von den anderen Gesprächsteilnehmern auseinander genommen. Die waren gar nicht zugänglich für Argumente. Es gilt das Mantra, eine gute Führungskraft muss auch loben. Schließlich motiviert das die Mitarbeiter. Einer der Artikel der mir da zu Denken gegeben hat kommt von intrinsify: Sollte eine Führungskraft Mitarbeiter wirklich loben?

Ein Ansatzpunkt um das genannte Problem zu umgehen ist, die Kunden zu motivieren Feedback und damit eben auch Lob zu geben. So kommt das Feedback von der Stelle, an der es besonders wichtig ist.

Auch hier ist die Welt nicht Schwarz-Weiß. Diese Aussagen und der Artikel von intrinsify sollen nur als Denkanstoß zur Reflektion dienen. Natürlich kommt es auch individuell auf das Verhältnis zwischen Mitarbeiter und Vorgesetztem an und wie reflektiert die gemeinsame Zusammenarbeit ist. Insgesamt wünsche ich mir einfach einen bewussteren Umgang mit Feedback.

Scrum Master – Ausbildung

Inzwischen hat Scrum sich etabliert und deshalb ist die Nachfrage nach Scrum Mastern groß. Wie in meinem letzten Artikel über die Frage, woher man Scrum Master bekommt beschrieben, ist es keine gute Idee einfach Entwickler umzufunktionieren. Außerdem habe ich da schon angedeutet, dass es ja gar keine detaillierten Kenntnisse in der Programmierung braucht. Tendenziell hat der Scrum Master ja so eine Art Coaching Funktion und es geht viel darum mit Menschen zu arbeiten.

Das alles zusammen führt dazu, dass jeder der mal irgendwas mit Menschen, Pädagogik und Co gemacht hat, jetzt glaubt Scrum Master werden zu müssen. Da kann man offenbar gut Geld verdienen. Formell gesehen dauert so ein Kurs zum Scrum Master zwei Tage und die Prüfung ist ziemlich leicht. Mein Eindruck ist, dass das inzwischen dazu geführt hat, dass der Markt überschwemmt wird mit Leuten die sich für diese Rolle bewerben – insbesondere als externe Berater und Selbstständige.

Der Scrum Master ist eine sehr schwierige Rolle. Er soll dienend führen (Servant Leadership), alle Teammitglieder bezüglich der Scrum Regeln coachen und auf dessen Einhaltung achten, die Organisation entwickeln, das Team unterstützen und vieles mehr. Gleichzeitig ist es gar nicht so einfach genau zu sagen, was ein Scrum Master macht, da er tendenziell das tun sollte, wo er am meisten Wirkung für das Team hat. Das alles lernt keiner in einem zwei Tages Seminar.

Er soll coachen können, eine Coaching Ausbildung ist also wünschenswert. Sehr beliebt in dem Zusammenhang ist eine Ausbildung zum systemischen Coach. Außerdem soll er den Product Owner unterstützten können. Eine Ausbildung im Bereich Projektmanagement, Anforderungsmanagement (Requirements Engineering) und insbesondere im Bereich Stakeholder Management wäre also gut. Außerdem soll er helfen, die Organisation weiterzuentwickeln. Dementsprechend sind Fortbildungen im Bereich Organisationsentwicklung, Präsentation und Beratung wichtig. Auch das Development Team soll kontinuierlich unterstützt werden. Hier kommen Fortbildungen zur Arbeit mit Teams zum tragen, z.B. zum Teambuilding, Serious Gaming und kontinuierliche Verbesserung.

Natürlich ist das noch nicht alles und gleichzeitig denke ich, es wird schon gut sichtbar, warum nicht jeder der schon mal mit Menschen gearbeitet hat auch in zwei Tagen zum Scrum Master qualifiziert ist. Guck also genau hin, wenn du externe Scrum Master anheuert. Wenn du wiederum Scrum Master anstellst und ausbildest, spar nicht an Fortbildungen, Konferenzen und Austauschmöglichkeiten außerhalb des eigenen Unternehmens für diese Mitarbeiter.

Scrum Master – Woher nehmen?

Scrum ist im IT-Bereich groß und erfolgreich geworden. Viele Scrum Master waren deshalb selbst früher Entwickler. Wenn das Experiment gewagt wurde, ein Projekt mit Scrum zu gestalten, wurde halt ein Scrum Master gebraucht. Das hat dann früher üblicherweise einer von denen übernommen, die für das Projekt vorgesehen waren. So bin ich auch das erste mal zu meiner Tätigkeit als Scrum Master gekommen. „Hey, es gibt da dieses Scrum, wollen wir das mal ausprobieren? Wer holt denn mal ein Buch und erklärt das?“ – ratet wer sich freiwillig gemeldet hat – meine ersten Gehversuche mit Scrum. Boah ist das lange her.

Heutzutage ist Scrum ein etabliertes Framework und die Rolle des Scrum Masters längst kommerzialisiert. Du willst erstmalig mit Scrum starten? Es stehen dutzende Unternehmen bereit, die dir Personen bereitstellen, damit das Team direkt in Fahrt kommt. Nur wo kommen diese Personen her? Auch das waren früher meist ehemalige Entwickler, die einfach festgestellt haben, dass sie mehr Spaß daran haben andere zu unterstützen, als selbst zu coden.

Da liegt jedoch ein großes Problem: Wenn wir Entwickler umfunktionieren / umqualifizieren, graben wir an der Stelle, wo wir ohnehin schon Fachkräftemangel haben. Da lohnt es sich mal hinzugucken, was ein Scrum Master eigentlich können muss. Programmieren können gehört nicht dazu – auch wenn natürlich das Verständnis dafür praktisch ist bei der Arbeit. Nur reicht da vermutlich ein Level, was sich jemand fachfremdes aus Interesse selbst aneignen kann.

Deshalb meine klare Empfehlung: Schaffe keine Anreize für die Entwickler, sich zum Scrum Master oder Agile Coach weiterzuentwickeln. Wir brauchen die Entwickler!

Das heißt natürlich nicht, dass wenn ein Entwickler von sich aus Interesse daran zeigt, das unterbunden werden sollte. Mir ist es sehr wichtig, dass jeder sich da einbringt, wo er glaubt, am meisten Wirkung zu zeigen. Vielleicht schlummert ja tatsächlich ein Scrum Master Talent in ihm. Wie immer in der Führung braucht es hier Fingerspitzengefühl, eine persönliche und individuelle Betreuung und Förderung.

Jetzt sind die 10 Minuten schon wieder um. Morgen geht es weiter.

Trick für „wichtig, nicht dringend“

In der Eisenhower-Matrix werden Aufgaben unterteilt in die Dimensionen wichtig und dringend. Eine wesentliche Feststellung ist dann, dass wir uns tendenziell eher Zeit für dringende Aufgaben nehmen und „wichtige, nicht dringende“ Aufgaben irgendwann „wichtig und dringend“ werden. Wie schaffst du es nun, dir Zeit zu nehmen für die Aufgaben, die noch nicht dringend sind.

Ein Trick den ich dabei gerne nutze ist, mir eine dringende Aufgabe zu suchen und sie bewusst mit „wichtigen, (noch) nicht dringenden“ Sachen anzureichern. Ein Beispiel: Im Unternehmen war es wichtig einige grundlegenden Verbesserungen bei einer Software zu machen, für die nie Zeit war, weil es immer irgendeinen Projektdruck gab. Immer wieder wurde versprochen, dass wir uns dafür bald Zeit nehmen und dann war immer irgendwas dringender und wurde deshalb höher priorisiert. Eins davon war ein Sicherheitsupdate. In dieses „Arbeitspaket“ (Update der Software) habe ich dann eine Reihe der gewünschten Verbesserungen rein definiert. Mit der Dringlichkeit des Updates, ist das Arbeitspaket dann verfolgt worden und hat gleichzeitig Dinge erledigt, die nicht elementar dazu gehörten und in dem Zuge gut zu erledigen waren.

Das ist natürlich langfristig keine Lösung. Die Ursache, dass die „wichtigen, nicht dringenden“ Aufgaben, nicht regulär erledigt werden, wird nicht behoben. Gleichzeitig finde ich es einen praktischen Trick für die Toolbox, mit der man das System ein bisschen austricksen kann. Manchmal braucht es eben auch ein paar solcher Kniffe.