Das Teamwork-Blog

Ja.  Wir müssen sprechen. Und zwar über die richtigen Dinge. Und auf eine gute Art und Weise. Zumindest sollten wir das dann tun, wenn wir uns und unser Geschäft erfolgreich neuen Gegebenheiten anpassen wollen oder müssen. Ein kleines Einmaleins von Veränderungsvorhaben.

Das populärste agile Framework hat seinen Namen von einer Mannschaftssportart bekommen. Scrum bedeutet Gedränge. Beim Rugby bekommt man ein Gefühl für die Zusammenarbeit im Team. Gibt es auch Vergleiche für die Scrum Ereignisse? Hier ist mein Vorschlag.

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.

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.

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.