Das Teamwork-Blog

Der Umgang mit Lieferanten entscheidet über Wettbewerbsvorteile. Kein Unternehmen kann alle nötigen Kompetenzen allein aufbauen und abdecken. Neue Projekte, neue Produkte, neue Märkte: das geht viel leichter, wenn man sich Hilfe holt. Aber wie lange dauert es, bis die Vertragspartner sich einig sind?

Um Gottes Willen, wohin mit den Kriterien? Einige der größten Fragezeichen beim Erstkontakt mit eduScrum löst die Frage um Akzeptanzkriterien und Definition of Done aus. Alle Kriterien sollen meine Lerner erfüllen, aber was ist denn nun was? 

Wir haben eine Location und wir haben einen Keynote-Speaker. 

Gerade wollte ich jemandem einen Link zum FindTime-Artikel senden und stelle fest: es gibt ihn nicht! Na da muss schleunigst gegengesteuert werden! Find Time ist im Grunde "Doodle innerhalb von Outlook" und steht unter Office 365 zur Verfügung. Die Eingeladenen müssen nicht über Office 365 verfügen und auch nicht über ein Microsoft-Konto. Hier eine kurze Einführung.

Bis zum 19. Januar 2020 bitten wir die agile Community um Vorschläge für den nächsten Scrum Day . Bisher haben wir immer 4-5 Vorschläge für einen Slot bekommen. Wie reduzieren wir diese Liste?

Sie möchten (oder müssen) agil arbeiten? Sie haben aber noch ein paar Fragen? Sie sind nicht allein. Hier der vierte und vorläufig letzte Teil der Serie, in der ich einige der sehr guten und nachvollziehbaren Exemplare zu beantworten versuche, die so oder so ähnlich öfter mal gestellt werden./1/2/3/ Wieder in ungeordneter Reihung. Und wieder, indem ich lustvoll in die Beraterfalle tappe./4/

Sie kommen in einen Raum voller Energie. Sie sehen, wie jeweils 3-5 Personen auf dem Fußboden oder über einen Tisch lehnend an etwas arbeiten. Mit Stoppuhr, Stift und Notizblock ausgerüstet experimentieren die Teams hochkonzentriert. Mit jedem Versuch kommen sie ihrem Ziel etwas näher. Wieder ein paar Sekunden besser als das letzte Mal. Der Countdown an der Wand zeigt die wenigen verbleibenden Minuten an. Teammitglieder wollen nochmal andere Oberflächen oder eine weitere Technik ausprobieren. Hellwach suchen sie ihre Umgebung nach weiteren Möglichkeiten ab.

Zumindest ist‘s der letzte Blogpost, den Ihr, liebe Leserinnen und Leser, in diesem Jahr von uns zu lesen bekommt. Herzlichen Dank für Euer Interesse an unserem Blog und alles Gute für‘s kommende Jahr! Wie das wohl werden wird? Entweder so oder so. Oder doch sowohl so, als auch so?

Das Jahr geht zu Ende. Wir feiern mit Weihnachten die Ankunft eines Erlösers. Ist das noch zeitgemäß?

Einleitung Fertig! Monatelang hat der Dienstleister an der Erstellung des Werkes gearbeitet! Es wurde gesprintet! Es wurde das Backlog verfeinert! Es wurde alle 4 Wochen ein Review mit dem Kunden durchgeführt. Der vereinbarte Budgetrahmen wurde eingehalten.Das Produkt ist fehlerfrei. Perfekte Welt! Wirklich? Nach all den Investitionen ist es für den Kunden an der Zeit das für ihn erstellte Werk abzunehmen und zu nutzen. Nur: Es gibt Widerstände!

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Der Scrum Day Ende Mai 2020 in Stuttgart ist eine gute Gelegenheit, Erfahrungen zu teilen. Bis zum 19. Januar 2020 könnt Ihr Vorträge einreichen.

Es war einmal... Rechtzeitig zur Geschichtensaison bringen 45 Autorinnen und Autoren ihre ganz persönliche Short Story heraus, wie es sie auf ihre "Mission Agile" verschlagen hat.  Dieses Kapitel ist mein Beitrag zu diesem Buch, auf das wir uns alle ganz besonders freuen. Zünden Sie sich die erste Kerze auf dem Adventskranz noch einmal an, schnappen Sie sich einen Tee, und dann viel Vergnügen bei dieser kleinen Kostprobe!

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.