PRODUKTIVITÄT
Dokumentenmanagement für den Privatgebrauch | Mit Raspberry PI und ngx
Ich bin kein Bastler, spiele aber schon länger mit dem Gedanken, mich mit Rasberry PI zu beschäftigen, auch oder gerade weil ich auf Blogartikel wie den folgenden von Herbert Hertentramph gestoßen bin, der in Kombination mit Paperless-ngx ein schlankes Dokumentenmanagement für den privaten Gebrauch vorstellt, das ohne die üblichen verdächtigen Anbieter und deren Cloudlösungen auskommt, ohne gleich einen eigenen Server betreiben zu müssen. Leider fehlen mir dazu im Moment die Zeit und die Nerven. Aber ich bin neugierig geworden und freue mich auf die weiteren Beiträge der Serie, um mehr zu erfahren.
https://digital-cleaning.de/index.php/paperless-ngx-auf-dem-raspberry-pi-erstaunlich-gut-teil-1/
Pausen | Regelmäßige Pausen sind essentiell
Als regelmässiger Hörer des Podcasts von Ivan Blatter ist der Beitrag von Andrea Windolph für mich eigentlich olle Kamelle 😉 Zeitmanagement ist vor allem Energiemanagement. Und deshalb sind regelmäßige Pausen und Auszeiten extrem wichtig. Die Erkenntnis ist da, die Umsetzung noch deutlich ausbaufähig. Zumindest bei mir.Als regelmäßiger Hörer des Podcasts von Ivan Blatter ist der Beitrag von Andrea Windolph eigentlich olle Kamelle für mich 😉 Zeitmanagement ist in erster Linie Energiemanagement. Und daher sind regelmäßige Pausen und Auszeiten extrem wichtig. Die Erkenntnis ist da, die Umsetzung noch deutlich verbesserungsfähig. Zumindest bei mir.
https://projekte-leicht-gemacht.de/blog/softskills/zeitmanagement/pausen/
Tagesreflexion | Mit fünf Fragen mit Wirkmacht
Was J. D. Meier hier vorschlägt, ist simpel und für die tägliche Reflexion unschlagbar. 5 Fragen mit großer Wirkung, die Dankbarkeit, Lernerfahrung und Kaizen beinhalten. Genau mein Ding. Und mehr braucht es nicht. Das Ganze dauert höchstens 10 Minuten am Tag, hilft aber ungemein. Ich reflektiere den Tag aktuell (fast täglich) und schriftlich. Und ich bin überrascht, wie es mir immer wieder hilft, selbst den chaotischsten Tagen etwas Positives abzugewinnen.
https://gettingresults.com/frame-your-day/
AGILE
Product Owner im Großkonzern | Eine Herausforderung, aber nicht unmöglich
Es wird ja immer gerne über die Trägheit der öffentlichen Verwaltung geschimpft. Abgesehen davon, dass es die öffentliche Verwaltung so nicht gibt (allein der Unterschied zwischen Kommunal-, Landes- und Bundesverwaltung ist gewaltig), habe ich in meiner Praxis gelernt, dass im Vergleich so mancher Großkonzern von der noch so trägen Finanzverwaltung in Sachen Agilität überholt wird. Da läuft man natürlich sehr schnell Gefahr, ein Pauschalurteil zu fällen, was sicher nicht im Sinne des Erfinders ist. Zum Glück gibt es dann hin und wieder kleine Nadelstiche, die mich daran erinnern, diese Fehler nicht zu machen. Besonders spannend ist es dann, wenn Menschen wie Daniel Dubbel, von dem ich hier auch schon den einen oder anderen Beitrag verlinkt habe, in einem Podcast zeigen, wie agile Rollen im Konzernkontext – trotz aller Widrigkeiten – mit Leben gefüllt werden können:
https://produktwerker.de/product-owner-im-konzern/
Skalierung | Skalierung von Scrum-Teams mit Nexus
Es gibt nicht nur SAFe auf dem Markt der Skalierungsframeworks. Alle haben ihre Stärken und Schwächen. Nicht alle sind für jeden Kontext gleich gut geeignet, auch wenn manche Protagonisten diesen Eindruck erwecken und ja, auch ich bin nicht von allen wirklich immer begeistert. Ich persönlich sehe Frameworks ohnehin nur als Referenzmodelle, die helfen, die passende Struktur zu finden und bevorzuge das „Prinzip der Einfachheit“. Mit LeSS, Scrum of Scrums oder Nexus gibt es Frameworks, die sich sehr gut für die Skalierung von Entwicklungsprojekten eignen. Bei SAFe (dem ich etwas kritischer gegenüberstehe) schätze ich die Skalierung entlang des Wertstroms. Das kann man aber auch mit einer Kanban-Skalierung erreichen. Wichtig finde ich, dass man die Frameworks zumindest kennt und versteht, um sinnvoll entscheiden zu können, welches für den jeweiligen Kontext passt, wenn die Notwendigkeit der Skalierung wirklich besteht. Daher ist es sinnvoll, regelmäßig auch Beiträge zu Skalierungsframeworks zu lesen, um ein erstes Gefühl dafür zu bekommen, was irgendwann in Frage kommen könnte und was nicht. Beiträge wie dieser von Mary Iqubal über Nexus zum Beispiel. Ein Framework, das mir zwar eher selten begegnet, das aber durch seine relative Einfachheit und große Nähe zu Scrum in Scrum-lastigen Umgebungen sicher nicht uninteressant ist.
Agile Skalierung | Ein methodischer Überblick
Wie bereits erwähnt, gibt es auf dem „Markt“ eine Reihe von Skalierungsframeworks. Die Auswahl ist nicht gerade klein. Lars Richter hat die meisten hier kurz zusammengefasst und ich teile auch seine kritische Einschätzung. Allerdings vermisse ich in seiner Auflistung Flight Level und Kanban als mögliche Optionen. Man kann aber darüber streiten, ob diese zu den Frameworks gehören. Für mich ist es durchaus eine denkbare Option. Gerade als Alternative zu SAFe.
https://cdi.digital/agile-skalierung/#toc_Agile_Skalierungsmodelle_von_denen_Du_die_Finger_lassen
Sensibilisierung für Negativfolgen von Multitasking | Ein praktische Übung für Teams, Führungskräfte und andere Anspruchsgruppen
Der häufige Kontextwechsel ist ein Fluch. Spannenderweise kennen viele das Prinzip der Begrenzung von Parallelarbeit und arbeiten auf persönlicher Ebene damit. Aber gerade in Organisationen erlebe ich immer wieder, dass ständige Prioritätenwechsel, ständige Umpriorisierungen in extrem kurzen Zyklen die Norm sind, so dass sich auf so manchem „Schreibtisch“ immer mehr unerledigte, unerledigte Arbeit türmt. Nicht, weil der Einzelne schlecht organisiert wäre. Nein, weil zu viele „Veränderungen“ von außen kommen. Meist von Führungskräften, die selbst oft unter Erfolgsdruck stehen und irgendwo liefern müssen. Was hier gut hilft, ist eine kleine Sensibilisierung mit allen Beteiligten in spielerischer Form, wie sie Marc Kaufmann vorstellt. Ich habe so etwas schon öfter gemacht und es funktioniert sehr gut.
https://www.teamworkblog.de/2023/10/stop-starting-start-finishing-eine-10.html
Agile Organisation | Was versteht man darunter?
Auch wenn ich persönlich mittlerweile dazu neige, das „Label“ agile möglichst nicht mehr zu verwenden, weil es in so vielen Organisationen einfach verbrannt ist und ich persönlich lieber von beidhändigen oder – nach Wohland – dynamikrobusten Organisationen spreche, macht es Sinn, sich immer wieder (Stichwort 5S im Kopf) klar zu machen, was Agilität für eine Organisation bedeutet und was das Ziel dahinter ist. Das mag irgendwann abgedroschen klingen. Ich habe aber die Erfahrung gemacht, dass man ohne regelmäßige Rückbesinnung in der täglichen Routine „vergisst“, warum man etwas für wen tut und dann besteht die Gefahr des Selbstzweckes mit all seinen Auswüchsen. Deshalb ist es wichtig, sich immer wieder vor Augen zu führen, was wir unter agiler Organisation verstehen, so wie es Lars Richter hier tut.
https://cdi.digital/agile-organisation/
Agile Transformation |Den Wandel zu dynamikrobuten Organisation meistern
Passend zur agilen Organisation sollten wir auch über ein anderes „Buzzword“ sprechen: agile Transformation. Dabei ist es mir wichtig, Transformation nicht als abgeschlossenes Projekt zu verstehen. Agile Organisationen sind sehr lebendig und erfinden sich ständig neu, indem sie sich evolutionär weiterentwickeln. Transformation ist in diesem Sinne die „Sensibilisierung“ der Organisation dafür. Und das ist kein leichtes Unterfangen. Mehr dazu von Lars Richter:
https://cdi.digital/agile-transformation/
Scrum Daily | Statt der „klassischen“ Fragen, PBI für PBI
Das Scrum Daily als tägliches Synchronisationstreffen des Scrum-Teams ist das Herzstück von Scrum. Darüber sind sich viele Autoren und Scrum-Enthusiasten einig. Schaut man jedoch genauer hin, scheint gerade das Daily immer wieder Gegenstand von „Problembeschreibungen“ zu sein. Es verkommt sehr schnell zum Gegenteil von dem, was es sein soll – ein Sync-Meeting und kein Reporting-Meeting. Wie kommt man aus diesem Dilemma heraus? Mike Cohn schlägt vor, dass die Teammitglieder PBI für PBI diskutieren. Meine Erfahrung damit: Kann funktionieren. Sogar gut. Aber nur, wenn alle verstanden haben, dass es nicht darum geht, über jemanden zu berichten, sondern zu sehen, wie das Team vorankommt und wo es hakt oder gegenseitige Unterstützung nötig ist. Die Gefahr, dass am Ende jeder nur berichtet, was er gemacht hat, bleibt. Auch hier sind die Scrum Master:innen gefragt, darauf zu achten, dass dabei über mögliche Hindernisse, Unterstützungsbedarf und neue Erkenntnisse als Team gesprochen wird.ird.
https://www.mountaingoatsoftware.com/blog/daily-scrums-not-working-try-this
Scrum Master | Die Zertifizierung ist erst der Anfang
Auch wenn sich gefühlt viele Organisationen damit schwer tun und meinen, möglichst billig an einen Scrum Master zu kommen, würde schon reichen, denn das bisschen Moderieren von Teamevents kann auch jemand mit wenig Berufserfahrung. Kostet nicht viel und mehr ist es ja auch nicht, was Scrum Master:innen machen. Pustekuchen! Da steckt viel mehr dahinter. Und wer glaubt, dass die Rolleninhaber:innen nach zwei Tagen ausgebildet sind, der irrt gewaltig. Das ist erst der Auftakt. Scrum Master:innen sind Servant Leader, Change Coaches, Trainer, Mentoren, Facilitatoren … sie sind wahre Multitalente, wenn sie ihren Job richtig machen. Sie unterstützen nicht nur Teamevents, nein, sie schaffen den Rahmen für die „Befähigung“ von Teams und der umgebenden Organisation, damit selbstgesteuertes Arbeiten möglich wird. Sie sind „Leader“ ohne hierarchische Macht. Wer ehrenamtlich Führungsaufgaben wahrnimmt, weiß, dass dies die Königsdisziplin ist. Und man muss schon ein bisschen mehr können. Leider, und damit trifft Willem-Jan Ageling einen Nerv, ist das vielen Rolleninhaber:innen und, was noch schlimmer ist, vielen Verantwortlichen in Organisationen nicht wirklich bewusst.
https://ageling.substack.com/p/you-cant-be-a-true-scrum-master-with
Scrum anpassen | Empfehlungen, Hinweise und Reflexionshilfen
Scrum ist ein leichtgewichtiges Entwicklungsframework. Entwickelt als Werkzeug für einen Kontext und einen Rahmen. Nicht immer 100% passend und manchmal gar nicht. Vor allem dann, wenn wir es mit Standardaufgaben zu tun haben, die auf verlässlichen Routinen basieren. Die gibt es in jeder Organisation. Ohne Stabilität keine Agilität. Wer das Gegenteil behauptet … Aber auch dort, wo nach reiflicher Überlegung Scrum die Wahl ist, stellt sich immer wieder die Frage: Müssen wir alles 1:1 so umsetzen? Anpassung ist kein Tabu. Aber etwas, das mit Sinn und Verstand gemacht werden sollte, denn es ist kein Zufall, dass Scrum den Standard definiert. Aber Standards sind nicht in Stein gemeißelt. Auch das ist richtig und wichtig. Wann also wie Scrum adaptieren und wann nicht? Dazu gibt es Antworten von Stefan Wolpers, die ich sehr passend finde.
https://www.scrum.org/resources/blog/sollten-wir-scrum-anpassen
Toms Gedankenblog 