Product Owner im Jahr 1899

Teams, die sich zum ersten Mal mit Scrum beschäftigen, tun sich schwer mit der Rolle "Product Owner". Was macht diese Person genau? Wie sieht ihr Alltag aus? An welcher Stelle im Organigramm finde ich potenzielle Product Owner? Vielleicht hilft hier ein Blick in die Geschichte.

Scrum richtig skalieren mit Scrum@Scale

Ende Oktober habe ich das Global Scrum Gathering in Wien besucht. Eine so große Scrum Konferenz bietet so viele Gelegenheiten für Gespräche. Während der dreieinhalb Tage habe ich mit vielen Kollegen gesprochen. Nach einigen Gesprächen habe ich mich umgedreht, konnte drei Meter weit laufen, bevor ich auf die nächsten alten Bekannten traf.

Viele Gespräche habe ich an unserem Scrum@Scale-Stand geführt. Dabei habe ich mitbekommen, dass es vermutlich einige Missverständnisse darüber gibt, was Scrum@Scale eigentlich ist. In diesem Artikel möchte ich auf das Wesen von Scrum@Scale hinweisen, und dass es kein Skalierungs-Framework wie SAFe oder LeSS ist.

Leitlinien für Arbeitsgruppen in MS Teams

Es überrascht selbst mich: Microsoft Teams breitet sich rasant aus! In vielen Unternehmen erscheint es "irgendwie ganz plötzlich" und soll benutzt werden. Doch wie genau? Technisch ist es ja leicht zu durchschauen, aber strukturell? Da fühlen sich Arbeitsgruppen (ich nenne die Menschen so, um den Begriff von "Teams" zu unterscheiden) oft alleine gelassen. Hier stelle ich Leitlinien vor, die man so oder so ähnlich in der Arbeitsgruppe implementieren könnte.

Kommt zum Open Leadership Symposium BERLIN am 19.11.2019

Wir sehen die Symptome Dark Scrum, Fake Agile oder Command&Control-Scrum-Einführungen. Das Ergebnis ist, dass die Namen „Scrum“ oder „Agil“ verbrennen. Auf dem Open Leaderhip Symposium in Berlin setzen uns damit auseinander, wie wir mit Open Patterns & Practices™ Menschen für echten agilen Wandel gewinnen können.

Der Scrum Master im Jahr 1918

Das erste Scrum-Team wurde offiziell im Jahr 1993 zusammengestellt. Die Idee eines Scrum Masters ist aber viel älter.

Wir können nicht jeden Sprint Software ausliefern.

Scrum funktioniert, weil es mit jedem Sprint Feedback gibt. Die Kunden können sich die neue Produktversion ansehen. Sie zeigen, was gefällt und was ihnen fehlt. Aber was ist, wenn ich nicht jeden Sprint eine neue Version liefern kann oder der Kunde das auch gar nicht will? In diesem Beitrag verweise ich nochmal auf ein paar Klassiker für den agilen Buchklub.

Hinter Innovationen stecken zuverlässige Institutionen

Innovationen werden fast mystisch betrachtet. Wir warten auf den genialen Einfall für das nächste Produkt. Und natürlich wären wir selbst gern die Person, die diesen Einfall hat. Damit Innovationen zur Realität werden, braucht es etwas, das oft übersehen wird: starke Institutionen.

Möglichkeiten für Innovation schaffen! (2/2)

Innovationsfähigkeit ist weniger eine Kompetenz- als vielmehr eine Kulturfrage. Ein paar Gedanken zu Produktinnovation und organisatorischer Erneuerung. (Der zweite und letzte Teil.)

Möglichkeiten für Innovation schaffen! (1/2)

Innovationsfähigkeit ist weniger eine Kompetenz- als vielmehr eine Kulturfrage. Ein paar Gedanken zu Produktinnovation und organisatorischer Erneuerung. (Der erste Teil von zweien.)

“Communitys of Practice”: Gegenseitige Unterstützung bei der Überwindung von Hindernissen

Menschen, die agile Methoden in ihrer Organisation verbreiten wollen, stoßen dabei nicht selten auf Hindernisse. Oft haben sie die Erlaubnis oder sogar den Auftrag, ein bestimmtes Projekt agil – z. B. mit Hilfe von Scrum – umzusetzen. Aber als Insellösung in einer nicht-agilen Umgebung will das nicht so richtig funktionieren. In einer solchen Lage kann es ein richtiger Kraftquell sein, wenn man Gleichgesinnte kennt, die einem als „Sparringspartner“ zur Verfügung stehen. Ein Format dafür ist die sogenannte „Community of Practice“.