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.

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.

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

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.

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.

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

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

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“.

Agilität ist in aller Munde. Scrum könnte man längst als eine Art Mainstream bezeichnen. Skalierungsrahmenwerke boomen. Trotzdem bringt der Einsatz der Frameworks manchmal nicht den gewünschten Erfolg. „Bei uns passt das eben nicht, wir müssen da anpassen!“ Recht haben Sie. Scrum@Scale von Scrum Co-Erfinder Jeff Sutherland ist mit Hilfe von zahlreichen Trainern und Coaches und deren Praxiserfahrung entstanden und hilft Ihnen dabei, hier die richtigen Entscheidungen zu treffen.

Den Erfindern von Scrum und von Lean Thinking ist empirisches Arbeiten sehr wichtig. Aber warum? Und was ist das Gegenteil von empirisch? Und wie geht empirisches Arbeiten genau? In einer kleinen Serie gehe ich diesen Fragen nach.

Den Erfindern von Scrum und von Lean Thinking ist empirisches Arbeiten sehr wichtig. Aber warum? Und was ist das Gegenteil von empirisch? Und wie geht empirisches Arbeiten genau? In einer kleinen Serie gehe ich diesen Fragen nach.

Den Erfindern von Scrum und von Lean Thinking ist empirisches Arbeiten sehr wichtig. Aber warum? Und was ist das Gegenteil von empirisch? Und wie geht empirisches Arbeiten genau? In einer kleinen Serie gehe ich diesen Fragen nach.

Den Erfindern von Scrum und von Lean Thinking ist empirisches Arbeiten sehr wichtig. Aber warum? Und was ist das Gegenteil von empirisch? Und wie geht empirisches Arbeiten genau? In einer kleinen Serie gehe ich diesen Fragen nach.

Praktisch jedes Team produziert Dateien, und in den allermeisten Fällen arbeitet man auch gemeinsam mit diesen. Die klassische Unterteilung in Home-Laufwerk und Abteilungs-/Projekt-/oder Bereichslaufwerk stößt beim vernetzten Arbeiten schnell an die Grenzen.

“We have a 80% chance of winning the deal,” proclaims the sales guy proudly. He’s proud of his chances and of his cold, hard number. It’s not just optimistic. It’s scientific. He’ll meet his sales goals, and his boss can report that the turnaround is just around the corner.  Maybe it’s all true. Alas, in many companies, such numbers are usually fake, rendering the financial forecasts and risk analyses than rely on them fake as well. But, there’s good news! Real empiricism is not that hard.

Was brauchen Scrum Master in der Praxis? Dazu gibt es ein neues Angebot im Netzwerk von Scrum Events.

Viele Unternehmen interessieren sich für Agilität. Mitarbeiterinnen und Mitarbeiter werden in Scrum-Trainings geschickt. Teams und Abteilungen können Beratungs- und Coachingleistungen nutzen. Aber ändert sich wirklich etwas? Werden Probleme gelöst? Ändern sich die Arbeitsbedingungen? Werden bessere Produkte auf den Markt gebracht? Skepsis ist angebracht. Eine Beratergruppe des US-amerikanischen Verteidigungsministerium hat sogar eine einfache Liste veröffentlicht, um vor Agilem Bullshit ( Detecting Agile BS ) zu warnen. Werfen wir ein Blick in die Geschichte. Nach dem 2. Weltkrieg gab es eine weltweite Welle für kontinuierliche Verbesserungen. In vielen Teilen der Welt war sie erfolgreich. Nur nicht in Deutschland. Die Gründe der Ablehnung damals klingen seltsam vertraut.

Sie möchten (oder müssen) agil arbeiten? Sie haben aber noch ein paar Fragen? Sie sind nicht allein. Hier der dritte Teil der Serie, in der ich einige der sehr guten und nachvollziehbaren Exemplare zu beantworten versuche, die mir neulich gestellt wurden./1/ Wieder in ungeordneter Reihung. Und wieder, indem ich lustvoll in die Beraterfalle tappe./2/

Immer wieder erreichen uns Fragen zu unseren Erfahrungen mit eduScrum. Einige davon treten besonders häufig / ähnlich auf. Drei davon werden hier beantwortet.

Als Dienstleistungsunternehmen ist es täglich Brot sich mit Kundenanforderungen, neuen Projekten und Kundenanfragen auseinanderzusetzen. Häufig ist es so, daß sich der Kunde mit einer Projektidee, einem Problem an den Dienstleister wendet und dieses gelöst haben will. Er braucht auch früh einen Indikator, was ihn das Ganze kosten würde bzw. wann das Projekt denn fertig sein wird. Er muss ja das Budget bereit stellen, Stakeholder Management betreiben und wissen, ab wann er einen Nutzen aus dem Projekt ziehen kann.

Wie bitte? Was hat Atmen mit Teamwork zu tun? Wer in Ihrem Team hat die höchste Stimme von allen? Wie gut können Sie dieser Person zuhören? Wie fühlt sich Ihr Kehlkopf an, wenn Sie dieser Person länger zuhören (müssen)? Fängt es irgendwo an zu kratzen? Müssen Sie sich räuspern? Wie genau bleiben Ihnen die Inhalte im Kopf, die diese Person gesagt hat? Wie sehr stimmen Sie der Person zu?

Haben Sie in Ihrem Team schon einmal darüber gesprochen, wie Sie genau zusammenarbeiten wollen? Oder hat sich das einfach so ergeben? Oder hatten Sie mal einen "großen Knall" und mussten sich mit dem Thema gezwungenermaßen auseinandersetzen? Für mein im Herbst erscheinendes Buch "Digital anders arbeiten" /1/ habe ich als Muster Leitlinien für (virtuelle) Teams zusammengestellt. Lesen Sie hier einen Auszug.

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. Doch allzu selten kommt es so. Zeit, unsere Vorstellung von den dahinter liegenden Prozessen zu überdenken. Dazu ein Blick in die Arbeit von Francis C. Moon.

Wer anfangen möchte (oder muss) agil zu arbeiten, hat meist viele Fragen. Einige sehr gute und nachvollziehbare Exemplare davon wurden mir neulich gestellt. Hier ein weiterer Versuch /1/, sie zu beantworten. In ungeordneter Reihung. Und wieder mal auf die Gefahr hin, in die Beraterfalle zu tappen./2/

Wenn wir von Informationen überflutet werden, werden wir tendenziell dümmer. Denn wir überprüfen weniger unsere Vorurteile und bleiben in alten Denkbahnen gefangen.

Games are a good opportunity to condense temporal experiences and learn together. Karl Scotland and Sallyann Freudenberg published their Lego Flow Game in May 2014. We took the game's main idea, and changed the material. Instead of Legos we use the material of Gregorz Rejchtman's Ubongo Game. These are the instructions of the Ubongo Flow Game.