IAPM Essentials #90 - Neuigkeiten aus der Projektmanagementwelt
Was hat uns letzte Woche bewegt? Was hat sich im Projektmanagement getan? Hier finden Sie lesenswerte Artikel und Links zu Videos oder Podcasts die wir Ihnen gerne ans Herz legen möchten.
Oder kurz gesagt: Essentielles aus der Welt des Projektmanagements.
Viel Spaß beim Lesen!
Oder kurz gesagt: Essentielles aus der Welt des Projektmanagements.
Viel Spaß beim Lesen!
IAPM Essentials 25. Januar 2022
Diese drei Artikel haben uns diese Woche besonders überzeugt:
5 Reasons Why Developers Hate Product Owners
Developer sind die Personen in einem Scrum Team, die den Product Backlog Items einen konkreten Wert verleihen, indem sie ein lauffähiges Programm entwickeln. Obwohl ihnen in dieser Phase niemand vorschreiben sollte, wie sie ihre Arbeit zu tun haben, erfinden manche Product Owner eine neue Rolle für sich und wollen genau das als "Developer Owner" tun - da ist Frustration vorprogrammiert. Um dies zu verhindern, stellt dieser Artikel fünf Punkte vor, wie sich ein Product Owner verhalten sollte. Erstens: Binden Sie die Developer mit ein. Sie haben es nur gut gemeint, als Sie den Developern einen ausgearbeiteten Plan vorgelegt haben, um sie nicht zusätzlich zu belasten? Was als gute Geste gemeint war, wird als Misstrauen interpretiert werden. Um dies zu vermeiden, sollten die Developer in der Planung mit einbezogen werden. Zweitens: Sie als Product Owner sind nicht der Chef. Obwohl es angesichts der Rollenbezeichnung naheliegend wäre, hat der Product Owner keine Weisungsbefugnis. Ein solches Verhalten führt daher nur zu Unmut. Drittens ist es wichtig, den Developern bei der Problemlösung zu vertrauen und sie nicht zu ignorieren und stattdessen immer weiter auf die Implementierung von Features zu drängen. Im vorletzten Punkt ist es wichtig, dass der Product Owner deutlich macht, warum etwas umgesetzt werden soll, denn ohne das Verständnis der Developer fehlt die Motivation und die Produktivität sinkt. Und schließlich: Setzen Sie die Developer nicht unter Druck, weil kurzfristige Ziele nicht erreicht wurden. Wann wird etwas fertig sein? Wie können wir die Effizienz steigern? Warum ist dieses Inkrement heute nicht fertig geworden? Anstatt zu versuchen, das Team zu managen, indem Sie solche Fragen stellen, sollte das Gesamtziel im Auge behalten werden.
Klicken Sie hier um den Originalartikel zu lesen.
Why you should avoid Prioritization Frameworks
Frameworks wie RICE oder WSJF helfen Teams bei der Priorisierung von Funktionen. Im Grunde funktioniert es so: Alles wird mit einem Wert versehen, in eine Formel geworfen und heraus kommt eine Liste mit wichtigen und weniger wichtigen Funktionen. Was narrensicher erscheint, ist in Wirklichkeit ein Hindernis. Oft ist diese Liste viel zu lang, man arbeitet sie ab und kommt trotzdem nicht weiter und außerdem: Funktionen entstehen durch Probleme und Möglichkeiten. Es wäre also besser, diese beiden anstelle von Funktionen zu priorisieren. Abgesehen davon beruhen die Berechnungen auf Schätzungen und subjektiven Einschätzungen. Es wäre mehr als optimistisch, auf dieser Grundlage einen genauen Plan zu erstellen. Das einzige Nutzungsszenario dieser Listen besteht also darin, sie als Grundlage zu verwenden, um zu verstehen, warum etwas so priorisiert wurde, wie es eben wurde.
Klicken Sie hier um den Originalartikel zu lesen.
Entlarvt: Die 6 größten Produktivitätslügen
Wer kennt das nicht, nach dem Jahreswechsel stehen bei einigen Menschen viele gute Vorsätze auf ihrer To-Do-Liste. Beispielsweise, der Wunsch nach mehr Selbstständigkeit und erhöhter Produktivität – sei es im beruflichen Alltag oder im privaten Umfeld. Viele Menschen denken, dass sie ihre Zeit sinnvoller nutzen können, wenn sie weniger schlafen und Pausen verringern oder aber indem sie Aufgaben parallelisieren. Doch mittlerweile ist wissenschaftlich belegt, dass das Gehirn nicht multitaskingfähig ist. Auch verhindern Sie eine komplette Regeneration des Körpers, wenn Einsparungen an Schlaf- und Pausenzeiten vorgenommen werden, so verlockend dies auch klingt mehr vom Tag zu haben. Sie wollen noch mehr Irrtümer in Bezug auf Produktivität kennen lernen? Dann lesen Sie am besten den gesamten Artikel!
Klicken Sie hier um den Originalartikel zu lesen.
Developer sind die Personen in einem Scrum Team, die den Product Backlog Items einen konkreten Wert verleihen, indem sie ein lauffähiges Programm entwickeln. Obwohl ihnen in dieser Phase niemand vorschreiben sollte, wie sie ihre Arbeit zu tun haben, erfinden manche Product Owner eine neue Rolle für sich und wollen genau das als "Developer Owner" tun - da ist Frustration vorprogrammiert. Um dies zu verhindern, stellt dieser Artikel fünf Punkte vor, wie sich ein Product Owner verhalten sollte. Erstens: Binden Sie die Developer mit ein. Sie haben es nur gut gemeint, als Sie den Developern einen ausgearbeiteten Plan vorgelegt haben, um sie nicht zusätzlich zu belasten? Was als gute Geste gemeint war, wird als Misstrauen interpretiert werden. Um dies zu vermeiden, sollten die Developer in der Planung mit einbezogen werden. Zweitens: Sie als Product Owner sind nicht der Chef. Obwohl es angesichts der Rollenbezeichnung naheliegend wäre, hat der Product Owner keine Weisungsbefugnis. Ein solches Verhalten führt daher nur zu Unmut. Drittens ist es wichtig, den Developern bei der Problemlösung zu vertrauen und sie nicht zu ignorieren und stattdessen immer weiter auf die Implementierung von Features zu drängen. Im vorletzten Punkt ist es wichtig, dass der Product Owner deutlich macht, warum etwas umgesetzt werden soll, denn ohne das Verständnis der Developer fehlt die Motivation und die Produktivität sinkt. Und schließlich: Setzen Sie die Developer nicht unter Druck, weil kurzfristige Ziele nicht erreicht wurden. Wann wird etwas fertig sein? Wie können wir die Effizienz steigern? Warum ist dieses Inkrement heute nicht fertig geworden? Anstatt zu versuchen, das Team zu managen, indem Sie solche Fragen stellen, sollte das Gesamtziel im Auge behalten werden.
Klicken Sie hier um den Originalartikel zu lesen.
Why you should avoid Prioritization Frameworks
Frameworks wie RICE oder WSJF helfen Teams bei der Priorisierung von Funktionen. Im Grunde funktioniert es so: Alles wird mit einem Wert versehen, in eine Formel geworfen und heraus kommt eine Liste mit wichtigen und weniger wichtigen Funktionen. Was narrensicher erscheint, ist in Wirklichkeit ein Hindernis. Oft ist diese Liste viel zu lang, man arbeitet sie ab und kommt trotzdem nicht weiter und außerdem: Funktionen entstehen durch Probleme und Möglichkeiten. Es wäre also besser, diese beiden anstelle von Funktionen zu priorisieren. Abgesehen davon beruhen die Berechnungen auf Schätzungen und subjektiven Einschätzungen. Es wäre mehr als optimistisch, auf dieser Grundlage einen genauen Plan zu erstellen. Das einzige Nutzungsszenario dieser Listen besteht also darin, sie als Grundlage zu verwenden, um zu verstehen, warum etwas so priorisiert wurde, wie es eben wurde.
Klicken Sie hier um den Originalartikel zu lesen.
Entlarvt: Die 6 größten Produktivitätslügen
Wer kennt das nicht, nach dem Jahreswechsel stehen bei einigen Menschen viele gute Vorsätze auf ihrer To-Do-Liste. Beispielsweise, der Wunsch nach mehr Selbstständigkeit und erhöhter Produktivität – sei es im beruflichen Alltag oder im privaten Umfeld. Viele Menschen denken, dass sie ihre Zeit sinnvoller nutzen können, wenn sie weniger schlafen und Pausen verringern oder aber indem sie Aufgaben parallelisieren. Doch mittlerweile ist wissenschaftlich belegt, dass das Gehirn nicht multitaskingfähig ist. Auch verhindern Sie eine komplette Regeneration des Körpers, wenn Einsparungen an Schlaf- und Pausenzeiten vorgenommen werden, so verlockend dies auch klingt mehr vom Tag zu haben. Sie wollen noch mehr Irrtümer in Bezug auf Produktivität kennen lernen? Dann lesen Sie am besten den gesamten Artikel!
Klicken Sie hier um den Originalartikel zu lesen.
Weitere lesenswerte Artikel und hörenswerte Podcasts, die Sie sich nicht entgehen lassen sollten:
10 spannende Einblicke zum Stand des Projektmanagements 2022
Klicken Sie hier um den Originalartikel zu lesen.
4 things decision makers get wrong when hiring an agile coach for their organization
Klicken Sie hier um den Originalartikel zu lesen.
A wie Agiles Reifegradmodell
Klicken Sie hier um den Originalartikel zu lesen.
Agiler Adventskalender: BAPO vs. OPAB
Klicken Sie hier um den Originalartikel zu lesen.
Agility is more than Scrum and Agile
Klicken Sie hier um den Originalartikel zu lesen.
BANI – VUCA 2.0 ?
Klicken Sie hier um den Originalartikel zu lesen.
Folge 109: Agile Dokumentation
Klicken Sie hier um den Originalartikel zu lesen.
How to Approach Project Estimation in a Healthy Way
Klicken Sie hier um den Originalartikel zu lesen.
How to Measure the Predictability of Agile
Klicken Sie hier um den Originalartikel zu lesen.
Purpose, Intuition und Gamification
Klicken Sie hier um den Originalartikel zu lesen.
Klicken Sie hier um den Originalartikel zu lesen.
4 things decision makers get wrong when hiring an agile coach for their organization
Klicken Sie hier um den Originalartikel zu lesen.
A wie Agiles Reifegradmodell
Klicken Sie hier um den Originalartikel zu lesen.
Agiler Adventskalender: BAPO vs. OPAB
Klicken Sie hier um den Originalartikel zu lesen.
Agility is more than Scrum and Agile
Klicken Sie hier um den Originalartikel zu lesen.
BANI – VUCA 2.0 ?
Klicken Sie hier um den Originalartikel zu lesen.
Folge 109: Agile Dokumentation
Klicken Sie hier um den Originalartikel zu lesen.
How to Approach Project Estimation in a Healthy Way
Klicken Sie hier um den Originalartikel zu lesen.
How to Measure the Predictability of Agile
Klicken Sie hier um den Originalartikel zu lesen.
Purpose, Intuition und Gamification
Klicken Sie hier um den Originalartikel zu lesen.
Autor: IAPM intern
Schlagworte: IAPM Essentials, Links, News