IAPM Essentials #74 - Neuigkeiten aus der Projektmanagementwelt

Orientierung für den Product Owner – mit POEM
Der Product Owner „repräsentiert den Kunden bzw. die Stakeholder und ist für das Produkt verantwortlich“. Es gibt verschiedene Möglichkeiten, die Verantwortung eines Product Owners darzustellen. Eine Methode dafür ist das Maturity Level: Es zeigt den Grad der Verantwortung des Product Owners für das Produkt, aber es zeigt nicht, wie der Product Owner innerhalb des Unternehmens eingeordnet ist. Hier ist die POEM-Methode das Werkzeug der Wahl. POEM steht für Product Ownership Evolution Model. Hintergrund dieser Methode ist, dass es in einem Unternehmen nicht nur eine Person gibt, die für das Produkt verantwortlich ist - nämlich den Product Owner - sondern mehrere Verantwortliche. Um zu vermeiden, dass sich die verschiedenen Rollen für den gleichen Bereich zuständig fühlen und um das Konfliktpotenzial gering zu halten, kann die POEM-Klassifizierung sinnvoll sein. Dazu wird für jede Rolle entschieden, wie hoch ihre Produktverantwortung in Bezug auf Teilbereiche des Produktes ist. Sind Sie nun neugierig, wie ein durch POEM erstelltes Raster aussehen kann und wie POEM in der Praxis angewendet werden kann? Dann sollten Sie unbedingt den Artikel von Helen Sedlmeier lesen.
Klicken Sie hier um den Originalartikel zu lesen.

Unvermeidbare und versehentliche Komplexität
Komplexität existiert in zwei verschiedenen Formen. Zum einen gibt es die "essentielle Komplexität" oder unvermeidbare Komplexität. Sie kann nicht beeinflusst werden und ist unvermeidlich. Die Marktdynamik oder die "Unvorhersehbarkeit der Softwareentwicklung" sind Beispiele dafür. Auf der anderen Seite gibt es die "zufällige Komplexität". Diese entsteht ungewollt, z.B. durch unrealistische Planung oder Legacy-Systeme. Auf das eine muss also schnell reagiert werden, das andere gilt es zu vermeiden. An dieser Stelle könnten Agile und Lean ansetzen. Da Agilität eine Organisationsstruktur mit einer schnellen Reaktionszeit erfordert, kann sie als Reaktion auf "essentielle Komplexität" kategorisiert werden. Lean hingegen konzentriert sich darauf, redundante und fehlerhafte Systeme zu finden und zu beseitigen, und kann als Vermeidung von "zufälliger Komplexität" eingestuft werden.
Klicken Sie hier um den Originalartikel zu lesen.

We tried Fluid teams, no Product Owner, a Transition phase, and that worked for us.
Das agile Projektmanagement muss nicht immer dem Schema F - z.B. Scrum - folgen. Auch wenn die Definition von Scrum festgelegt ist, kann die Praxis des agilen Projektmanagements individuell angepasst werden und so haben auch Fredrik Carleson und sein Team Anpassungen bei ihrer agilen Arbeitsweise gemacht. In seinem Beitrag berichtet er Ihnen von seinen Erfahrungen. Probieren Sie doch auch einmal fluide Teams - also kleine wechselnde Teams - aus. Der Vorteil? Es wird vermieden, dass Wissen in einem einzigen Team verloren geht. Außerdem verbreiten sich Standards und Best Practices von selbst. Ein weiterer Tipp: Der Verzicht auf Product Owner, wie wir sie kennen, und stattdessen die direkte Kommunikation mit Experten und Unternehmen. Dies bringt direktes Feedback und die Vermeidung von "Stiller Post". Auf diese Weise werden die Ansprechpartner der jeweiligen Stelle sozusagen zu Product Ownern. Die letzte Idee besteht darin, eine Übergangsphase nach Abschluss eines Projekts einzurichten. Anstatt Teams direkt aufzulösen und sie an einem anderen Projekt arbeiten zu lassen, werden Änderungen und Fehler mit dem Endanwender besprochen und diese direkt eingearbeitet und korrigiert. Das Resultat: Schneller Support und mehr Zeit für andere Projekte, statt sich immer wieder neu einarbeiten zu müssen.
Klicken Sie hier um den Originalartikel zu lesen.
 

Agile Principles: Early and Continuous Delivery
Klicken Sie hier um den Originalartikel zu lesen.

Agile Principles: Welcome Change
Klicken Sie hier um den Originalartikel zu lesen.

Eine Konferenz mit der Dropbox organisieren
Klicken Sie hier um den Originalartikel zu lesen.

Fluid Scrum Teams — An example
Klicken Sie hier um den Originalartikel zu lesen.

Inspection and the Sprint Backlog - Back to the foundations of the Scrum framework (18)
Klicken Sie hier um den Originalartikel zu lesen.

Power of Backlog Refinement
Klicken Sie hier um den Originalartikel zu lesen.

Practicing with the Complaining Habit
Klicken Sie hier um den Originalartikel zu lesen.

Produktvision – Wieso, weshalb … und wie
Klicken Sie hier um den Originalartikel zu lesen.

Wichtiger als richtig machen: Die richtigen Projekte machen.
Klicken Sie hier um den Originalartikel zu lesen.
 

Autor: IAPM intern