schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.

This server runs the snac software and there is no automatic sign-up process.

Search results for tag #Scrum

#agile boosted

[?]Agile ♻️ Agilist.in » 🌐
@agile@mastodon.online

[?]ralf warümme tauscher » 🌐
@derralf@friends.librescrum.org

what a nice start today to appear on the same page with @JuttaEckstein ,
@karen , @barryovereem and @christiaanverwijs

i assume we were always on the same page. and now visible to anyone 🥰

reflexiveai.org/

i am in for healthy ai usage: planet, humans and software.

its new to me to go into "action research" within @haufegroup . will keep you posted.

chris and barry with a crowd in a liberating structure setting 
photo by lisanne lentink

Alt...chris and barry with a crowd in a liberating structure setting photo by lisanne lentink

    Stefan Roock boosted

    [?]Thomas 🔜 Manage Agile 2026 » 🌐
    @nobsagile@mastodon.social

    Neulich im Daily: Es geht reiherum, jeder spricht 90 Sekunden ins Leere,
    keiner hört zu. Am Ende weiß genau einer mehr als vorher: der Chef.

    Ein Daily ist kein Status-Report. Sobald es einer wird, optimiert jeder
    seine eigene Zeile statt den Fluss der Arbeit. Zu Recht hasst ihr das Ding.

    Es gibt eine Variante, in der die 15 Minuten wirklich was bewegen. Die
    redet nicht über Menschen, sondern über Tickets.

    no-bullshit-agile.de/warum-dai

      #agile boosted

      [?]Agile ♻️ Agilist.in » 🌐
      @agile@mastodon.online

      #agile boosted

      [?]Retro Point » 🌐
      @retropoint@mastodon.moscow

      Хотите посмотреть RetroPoint в работе до регистрации? Теперь это можно сделать за один клик 🚀

      Мы запустили заполненный демо-режим. Внутри уже есть ретро-доски с карточками и Action Items, OKR и SWOT, встречи 1‑2‑1, Performance Review, Planning Poker, команды, отпуска и дни рождения.

      Можно открыть доски, изучить реальные сценарии работы команды, посмотреть графики прогресса и попробовать интерфейс голосования 🃏

      Демо доступно без регистрации и оплаты. Данные защищены от изменений, поэтому можно смело исследовать продукт. А когда захотите попробовать самостоятельно, создайте обычный аккаунт прямо из демо ✨

      👉 retropoint.ru/demo

      @rf @Russia

      #agile boosted

      [?]Thomas 🔜 Manage Agile 2026 » 🌐
      @nobsagile@mastodon.social

      RE: mastodon.social/@Berufebilder/

      Ein Artikel über agile Kommunikation, bei dem das Scrum-Board-Beispiel im falschen Kapitel steht.

      Kernthese: bessere Kommunikation = mehr Innovation. Kein Wort davon, dass schlechte Kommunikation meist Symptom ist für kaputte Feedback-Schleifen und unklare Verantwortung.

      Stattdessen: Trainings gegen Hierarchiedenken. Ein Miro-Link gegen Missverständnisse.

      Genau das Muster. An der Oberfläche schrauben.

        #agile boosted

        [?]SCRUMschau » 🌐
        @scrumschau@mastodon.social

        RE: tomsgedankenblog.social/2026/0

        Wie jeden Montag: Eine sehr gute "Presseschau".

        #agile boosted

        [?]Toms Gedankenblog » 🌐
        @tomsgedankenblog.social@tomsgedankenblog.social

        #LINKSDERWOCHE | 30/2026: Produktivität, Lean, Agile, Mangement und Leadership

        Photo by Pixabay on Pexels.com

        PRODUKVITIÄT

        Obsidian | Callouts farblich gestalten

        Eine Funktion, die ich in Obsidian bisher noch nicht genutzt habe, ist durch einen Blogartikel von Thomas Mathoi wieder in meinen Fokus gerückt: Callouts. Offenbar gibt es so etwas wie einen „Callout-Manager”, mit dem sich die Callouts farblich variieren lassen. Das ist sicherlich für den einen oder anderen interessant. Ich selbst weiß noch nicht, ob und wie ich diese Möglichkeit künftig nutzen werde.

        https://www.mathoi.at/2026/07/22/obsidian-kaizen-der-callout-manager/

        Statt Bequemlichkeit | Tue, was den Unterschied macht

        Dan Rockwell wirft einen interessanten Ansatz in den Raum. Nicht das, was uns glücklich macht, sollte in den Fokus gestellt werden, sondern das, was uns voranbringt. Das klingt naheliegend. Eigentlich. Aber seien wir ehrlich: Wir suchen doch immer zuerst nach dem „Glück” und dem, was uns „Spaß” macht. Zumindest legen das viele Ratschläge immer wieder nahe. Rockwell sagt jedoch, dass das, was den Unterschied macht, viel relevanter ist. Ich würde ergänzen, dass dort der Schlüssel zur langfristigen, gesunden Zufriedenheit liegt. Glück ist flüchtig. Zufriedenheit macht träge. Etwas zu finden, das den Unterschied macht und von dem man überzeugt ist, dass es einen voranbringt, ist nicht immer bequem, hält uns aber in Bewegung.

        https://leadershipfreak.blog/2026/07/24/do-what-makes-you-unhappy/

        Gefühl der Einsamkeit | Ein nachdenklicher Impuls

        Der Blogartikel von Uwe Hauck lässt mich nachdenklich zurück. Ein bisschen erkenne ich mich selbst darin wieder. Spezialthemen, die nur wenige interessieren – das kommt mir bekannt vor. Wenn auch die thematische Schnittmenge eine etwas andere ist. Auch ich habe gemerkt, wie wichtig soziale Kontakte sind, und nehme daher regelmäßig an Veranstaltungen wie dem Europa-Stammtisch, Meet and Talk von Wir in Weinsberg und ähnlichen Events teil. Viele Freunde und Bekannte, die meine Interessen teilen, leben übrigens oft 100 km weit weg von meinem Wohnort. Mit nur wenigen Menschen im Umkreis von 50 km habe ich einen sehr intensiven Kontakt, der unter die Rubrik „echte Freundschaft” fällt. Glücklicherweise kämpfe ich nicht gegen eine Angststörung. Das macht es etwas einfacher. Aber auch bei mir kommt gelegentlich das Gefühl der Einsamkeit hoch, wenn Gespräche mit Tiefgang fehlen und der Austausch im Alltag nur an der Oberfläche kratzt.

        https://www.livingthefuture.de/2026/07/19/alleine-ist-ein-zustand-einsam-ein-gefuehl/

        LEAN

        Standardisierung und Kaizen | Gute Standards sind lebendig

        In seinem Blogartikel beschreibt Mark Graban ein Thema, das ich in ähnlicher Form auch immer wieder aufgreife: Standards. Ich verstehe Standards als „fluid” und adaptiv. Es sind gut bestätigte Arbeitshypothesen, die so lange gültig sind, bis wir eine bessere finden. Ganz simpel und einfach. Sie entwickeln sich beständig weiter. Ganz im Sinne von Kaizen. Allerdings erlebe ich immer wieder, dass Standards nicht reflektiert oder hinterfragt werden – geschweige denn angepasst. Einmal definiert, gelten sie, bis das Römische Reich untergeht. Das ist in meinen Augen unsinnig. In eine ähnliche Kerbe schlägt auch der Beitrag.

        https://www.leanblog.org/2026/07/standardized-work-and-kaizen-toyota

        AGILE

        Prototypentest | Feedback Capture Grids nutzen

        Im Scamper-Blog von Lars Richter bin ich auf einen Ansatz gestoßen, der mich stark an ein Format erinnert, das wir gerne in Team-Retros verwenden. Der Unterschied ist, dass er es im Kontext von Prototypentesting nutzt. Eigentlich naheliegend. Das Feedback Capture Grid ist ein einfaches Raster, das sich leicht abbilden lässt und fast selbsterklärend ist. Es liegt also nahe, es auch tatsächlich als Feedback-Werkzeug für das Prototypentesten zu nutzen.

        https://scamper.blog/feedback-capture-grid

        Impediments | Einordnung der Impediments auf einer Wirkungspyramide

        Als ich den Blogartikel von Dominik Maximini gesehen habe, bin ich im ersten Moment innerlich etwas zusammengezuckt. Eine Pyramide der Impediements? Glücklicherweise hat er direkt klargestellt, dass es nicht darum geht, dass Teams eine Stufe nach der anderen durchlaufen – in dem Fall hätte ich den Beitrag nicht einmal erwähnt – sondern dass es sich um eine Einordnungshilfe handelt, die dabei helfen soll, Hindernisse zu kategorisieren. Das macht die Sache für mich interessanter. Die Hauptunterscheidung liegt in den Einflussebenen „Team” oder „Organisation”, also wo kann ich den Hebel ansetzen, um Wirkung zu erzielen? Diese beiden Hauptebenen differenziert er in Unterkategorien, die in einer „Wirksamkeitspyramide” münden. Die Darstellung finde ich persönlich zwar nicht optimal, dennoch kann ich inhaltlich gut folgen. Denn tatsächlich sind viele Impediments struktureller Art und es hilft herzlich wenig, an einem Team „herumzudoktern”. Solche Fälle durfte ich im Leben auch schon oft genug erleben. Das Team war top, konnte aber wegen struktureller Probleme an den Schnittstellen innerhalb der Organisation – beispielsweise entlang der Wertstromkette, in die es eingebunden war – sein Potenzial nicht nutzen.

        https://www.scrum.org/resources/blog/pyramid-impediments

        Agile Rolle | Gute Arbeit, die unsichtbar bleibt

        In den letzten Monaten hatte ich den Eindruck, dass massenweise Agile Coaches, Scrum Master:innen, Kanban Coaches und Ähnliches nach neuen Jobs Ausschau gehalten haben, weil ihre Stellen in Unternehmen wegrationalisiert worden sind. Das Problem bei diesen Rollen ist, dass die Leistung der Inhaber:innen nicht direkt bezifferbar ist und somit oft unklar ist, welchen Mehrwert die Rolle hat. Marc Löffler greift genau dieses Thema unter dem Titel „Gute Arbeit, die keiner sieht, sieht aus wie gar keine Arbeit” auf. Ich würde behaupten, dass dies für jede Form echter und guter Führungsarbeit gilt. Selbst wenn man seinem Vorschlag folgt, braucht es immer noch eine Referenz, um die Sichtbarkeit durch einen Vergleich herzustellen, was in der Praxis weiterhin schwierig bleiben dürfte.

        https://passionateteams.com/e/gute-arbeit-die-keiner-sieht-sieht-aus-wie-gar-keine-arbeit

        Velocity | Die kognitiven Fallen der Velocity

        Die gute alte Velocity ist nach wie vor ein Dauerbrenner, wie es scheint. Noch einmal: Sie misst den Durchsatz und ist somit eine Kennzahl für das Team, mit der sich dessen spezifische Geschwindigkeit ermitteln lässt. Ein Vergleich mit anderen Teams ist jedoch nicht möglich, da er auf relationellen Schätzungen basiert. Sie ist aber sicherlich nicht die einzige Kennzahl, mit der man arbeiten und auf die man sich verlassen sollte. Chuck Suscheck verdeutlicht gut, weshalb dem so ist, denn hier lauern auch einige kognitive Fallen, die zu Fehlschlüssen verleiten könnten.

        https://www.scrum.org/resources/blog/cognitive-trap-velocity-misinterpretation

        Scheitern | Weshalb „kontrolliertes“ Scheitern für das Lernen von Bedeutung ist

        Auf den ersten Blick mag der Titel „Wann Scrum Master Teams bewusst scheitern lassen sollten” von Niklas Magerl etwas seltsam klingen. Zusammengefasst geht es jedoch nicht um das Scheitern an sich, sondern um „Risikomanagement” im Hinblick auf Experimente, die die Lernerfahrung des Teams stärken sollen. Es geht also um ein kontrolliertes „Scheitern“ mit dem Ziel, die Lernerfahrung zu intensivieren. Das ist naheliegend, denn Scheitern gehört zum Geschäft, wenn wir explorativ unterwegs sind und Lösungen erkunden. Wir müssen ja erst herausfinden, was der richtige Weg ist. Versuch und Irrtum gehören dazu. Das Ganze jedoch auf Risikomanagement zu reduzieren, würde zu kurz greifen. Ein durchaus lesenswerter Ansatz.

        https://t2informatik.de/blog/scrum-master-teams-scheitern-lassen-sollten/

        Scrum ohne Manager? | Auch selbstorganisierte Teams brauchen Führung

        Ein hartnäckiger Mythos ist, dass selbstorganisierte Teams ohne Führung auskommen und man daher keine Führungskräfte mehr braucht. Das artet gerne auch mal so aus, dass behauptet wird, das Team sei selbstorganisiert und solle deshalb alles selbst entscheiden, wobei das Team dann im Stich gelassen wird. Nein, die Führung und das Management haben auch bei selbstorganisierten Teams nicht ausgedient. Die meisten Teams sind operative Teams. Sie sind auf operativer Flughöhe unterwegs. Für den ganzen taktischen, strategischen „Kram” haben sie nur bedingt Kapazitäten – und hier kommt unter anderem die Führung ins Spiel. Nur um ein Beispiel zu geben. Es ist auch ein weitverbreitetes Missverständnis, dass Scrum Master (und oft auch Product Owner) keine Führungskräfte sind. Sie sind genau das. Dazu passt, dass Mary Iqbal der Frage nachgeht, ob es in Scrum keine „Manager” gibt.

        https://www.scrum.org/resources/blog/no-manager-scrum

        LEADERSHIP UND MANAGEMENT

        Führung braucht Ausbildung | Führungskräfte oft nicht auf Führungsaufgabe vorbereitet

        Bei vielen Führungskräften lässt sich feststellen, dass sie nicht darauf vorbereitet wurden, Führungskraft zu werden. Mit etwas Glück bringen sie Vorerfahrung mit, sind hochgradig selbstreflektiert und bereiten sich daher selbst auf ihre Aufgabe vor. Dennoch ist meine Beobachtung nach wie vor, dass man sie viel zu oft im Stich lässt und sie nicht auf ihre Aufgabe vorbereitet. Eine Beobachtung, die Jan Fischbach zu teilen scheint. Er plädiert dafür, dass Führungskräfte eine „Ausbildung” benötigen. Führen will gelernt sein. Und da stimme ich ihm zu. Da ist nach wie vor viel Luft nach oben.

        https://www.teamworkblog.de/2026/07/fuhrungskrafte-brauchen-eine-ausbildung.html

            #agile boosted

            [?]Toms Gedankenblog » 🌐
            @tomsgedankenblog.social@tomsgedankenblog.social

            #LINKSDERWOCHE | 30/2026: Produktivität, Lean, Agile, Mangement und Leadership

            Photo by Pixabay on Pexels.com

            PRODUKVITIÄT

            Obsidian | Callouts farblich gestalten

            Eine Funktion, die ich in Obsidian bisher noch nicht genutzt habe, ist durch einen Blogartikel von Thomas Mathoi wieder in meinen Fokus gerückt: Callouts. Offenbar gibt es so etwas wie einen „Callout-Manager”, mit dem sich die Callouts farblich variieren lassen. Das ist sicherlich für den einen oder anderen interessant. Ich selbst weiß noch nicht, ob und wie ich diese Möglichkeit künftig nutzen werde.

            https://www.mathoi.at/2026/07/22/obsidian-kaizen-der-callout-manager/

            Statt Bequemlichkeit | Tue, was den Unterschied macht

            Dan Rockwell wirft einen interessanten Ansatz in den Raum. Nicht das, was uns glücklich macht, sollte in den Fokus gestellt werden, sondern das, was uns voranbringt. Das klingt naheliegend. Eigentlich. Aber seien wir ehrlich: Wir suchen doch immer zuerst nach dem „Glück” und dem, was uns „Spaß” macht. Zumindest legen das viele Ratschläge immer wieder nahe. Rockwell sagt jedoch, dass das, was den Unterschied macht, viel relevanter ist. Ich würde ergänzen, dass dort der Schlüssel zur langfristigen, gesunden Zufriedenheit liegt. Glück ist flüchtig. Zufriedenheit macht träge. Etwas zu finden, das den Unterschied macht und von dem man überzeugt ist, dass es einen voranbringt, ist nicht immer bequem, hält uns aber in Bewegung.

            https://leadershipfreak.blog/2026/07/24/do-what-makes-you-unhappy/

            Gefühl der Einsamkeit | Ein nachdenklicher Impuls

            Der Blogartikel von Uwe Hauck lässt mich nachdenklich zurück. Ein bisschen erkenne ich mich selbst darin wieder. Spezialthemen, die nur wenige interessieren – das kommt mir bekannt vor. Wenn auch die thematische Schnittmenge eine etwas andere ist. Auch ich habe gemerkt, wie wichtig soziale Kontakte sind, und nehme daher regelmäßig an Veranstaltungen wie dem Europa-Stammtisch, Meet and Talk von Wir in Weinsberg und ähnlichen Events teil. Viele Freunde und Bekannte, die meine Interessen teilen, leben übrigens oft 100 km weit weg von meinem Wohnort. Mit nur wenigen Menschen im Umkreis von 50 km habe ich einen sehr intensiven Kontakt, der unter die Rubrik „echte Freundschaft” fällt. Glücklicherweise kämpfe ich nicht gegen eine Angststörung. Das macht es etwas einfacher. Aber auch bei mir kommt gelegentlich das Gefühl der Einsamkeit hoch, wenn Gespräche mit Tiefgang fehlen und der Austausch im Alltag nur an der Oberfläche kratzt.

            https://www.livingthefuture.de/2026/07/19/alleine-ist-ein-zustand-einsam-ein-gefuehl/

            LEAN

            Standardisierung und Kaizen | Gute Standards sind lebendig

            In seinem Blogartikel beschreibt Mark Graban ein Thema, das ich in ähnlicher Form auch immer wieder aufgreife: Standards. Ich verstehe Standards als „fluid” und adaptiv. Es sind gut bestätigte Arbeitshypothesen, die so lange gültig sind, bis wir eine bessere finden. Ganz simpel und einfach. Sie entwickeln sich beständig weiter. Ganz im Sinne von Kaizen. Allerdings erlebe ich immer wieder, dass Standards nicht reflektiert oder hinterfragt werden – geschweige denn angepasst. Einmal definiert, gelten sie, bis das Römische Reich untergeht. Das ist in meinen Augen unsinnig. In eine ähnliche Kerbe schlägt auch der Beitrag.

            https://www.leanblog.org/2026/07/standardized-work-and-kaizen-toyota

            AGILE

            Prototypentest | Feedback Capture Grids nutzen

            Im Scamper-Blog von Lars Richter bin ich auf einen Ansatz gestoßen, der mich stark an ein Format erinnert, das wir gerne in Team-Retros verwenden. Der Unterschied ist, dass er es im Kontext von Prototypentesting nutzt. Eigentlich naheliegend. Das Feedback Capture Grid ist ein einfaches Raster, das sich leicht abbilden lässt und fast selbsterklärend ist. Es liegt also nahe, es auch tatsächlich als Feedback-Werkzeug für das Prototypentesten zu nutzen.

            https://scamper.blog/feedback-capture-grid

            Impediments | Einordnung der Impediments auf einer Wirkungspyramide

            Als ich den Blogartikel von Dominik Maximini gesehen habe, bin ich im ersten Moment innerlich etwas zusammengezuckt. Eine Pyramide der Impediements? Glücklicherweise hat er direkt klargestellt, dass es nicht darum geht, dass Teams eine Stufe nach der anderen durchlaufen – in dem Fall hätte ich den Beitrag nicht einmal erwähnt – sondern dass es sich um eine Einordnungshilfe handelt, die dabei helfen soll, Hindernisse zu kategorisieren. Das macht die Sache für mich interessanter. Die Hauptunterscheidung liegt in den Einflussebenen „Team” oder „Organisation”, also wo kann ich den Hebel ansetzen, um Wirkung zu erzielen? Diese beiden Hauptebenen differenziert er in Unterkategorien, die in einer „Wirksamkeitspyramide” münden. Die Darstellung finde ich persönlich zwar nicht optimal, dennoch kann ich inhaltlich gut folgen. Denn tatsächlich sind viele Impediments struktureller Art und es hilft herzlich wenig, an einem Team „herumzudoktern”. Solche Fälle durfte ich im Leben auch schon oft genug erleben. Das Team war top, konnte aber wegen struktureller Probleme an den Schnittstellen innerhalb der Organisation – beispielsweise entlang der Wertstromkette, in die es eingebunden war – sein Potenzial nicht nutzen.

            https://www.scrum.org/resources/blog/pyramid-impediments

            Agile Rolle | Gute Arbeit, die unsichtbar bleibt

            In den letzten Monaten hatte ich den Eindruck, dass massenweise Agile Coaches, Scrum Master:innen, Kanban Coaches und Ähnliches nach neuen Jobs Ausschau gehalten haben, weil ihre Stellen in Unternehmen wegrationalisiert worden sind. Das Problem bei diesen Rollen ist, dass die Leistung der Inhaber:innen nicht direkt bezifferbar ist und somit oft unklar ist, welchen Mehrwert die Rolle hat. Marc Löffler greift genau dieses Thema unter dem Titel „Gute Arbeit, die keiner sieht, sieht aus wie gar keine Arbeit” auf. Ich würde behaupten, dass dies für jede Form echter und guter Führungsarbeit gilt. Selbst wenn man seinem Vorschlag folgt, braucht es immer noch eine Referenz, um die Sichtbarkeit durch einen Vergleich herzustellen, was in der Praxis weiterhin schwierig bleiben dürfte.

            https://passionateteams.com/e/gute-arbeit-die-keiner-sieht-sieht-aus-wie-gar-keine-arbeit

            Velocity | Die kognitiven Fallen der Velocity

            Die gute alte Velocity ist nach wie vor ein Dauerbrenner, wie es scheint. Noch einmal: Sie misst den Durchsatz und ist somit eine Kennzahl für das Team, mit der sich dessen spezifische Geschwindigkeit ermitteln lässt. Ein Vergleich mit anderen Teams ist jedoch nicht möglich, da er auf relationellen Schätzungen basiert. Sie ist aber sicherlich nicht die einzige Kennzahl, mit der man arbeiten und auf die man sich verlassen sollte. Chuck Suscheck verdeutlicht gut, weshalb dem so ist, denn hier lauern auch einige kognitive Fallen, die zu Fehlschlüssen verleiten könnten.

            https://www.scrum.org/resources/blog/cognitive-trap-velocity-misinterpretation

            Scheitern | Weshalb „kontrolliertes“ Scheitern für das Lernen von Bedeutung ist

            Auf den ersten Blick mag der Titel „Wann Scrum Master Teams bewusst scheitern lassen sollten” von Niklas Magerl etwas seltsam klingen. Zusammengefasst geht es jedoch nicht um das Scheitern an sich, sondern um „Risikomanagement” im Hinblick auf Experimente, die die Lernerfahrung des Teams stärken sollen. Es geht also um ein kontrolliertes „Scheitern“ mit dem Ziel, die Lernerfahrung zu intensivieren. Das ist naheliegend, denn Scheitern gehört zum Geschäft, wenn wir explorativ unterwegs sind und Lösungen erkunden. Wir müssen ja erst herausfinden, was der richtige Weg ist. Versuch und Irrtum gehören dazu. Das Ganze jedoch auf Risikomanagement zu reduzieren, würde zu kurz greifen. Ein durchaus lesenswerter Ansatz.

            https://t2informatik.de/blog/scrum-master-teams-scheitern-lassen-sollten/

            Scrum ohne Manager? | Auch selbstorganisierte Teams brauchen Führung

            Ein hartnäckiger Mythos ist, dass selbstorganisierte Teams ohne Führung auskommen und man daher keine Führungskräfte mehr braucht. Das artet gerne auch mal so aus, dass behauptet wird, das Team sei selbstorganisiert und solle deshalb alles selbst entscheiden, wobei das Team dann im Stich gelassen wird. Nein, die Führung und das Management haben auch bei selbstorganisierten Teams nicht ausgedient. Die meisten Teams sind operative Teams. Sie sind auf operativer Flughöhe unterwegs. Für den ganzen taktischen, strategischen „Kram” haben sie nur bedingt Kapazitäten – und hier kommt unter anderem die Führung ins Spiel. Nur um ein Beispiel zu geben. Es ist auch ein weitverbreitetes Missverständnis, dass Scrum Master (und oft auch Product Owner) keine Führungskräfte sind. Sie sind genau das. Dazu passt, dass Mary Iqbal der Frage nachgeht, ob es in Scrum keine „Manager” gibt.

            https://www.scrum.org/resources/blog/no-manager-scrum

            LEADERSHIP UND MANAGEMENT

            Führung braucht Ausbildung | Führungskräfte oft nicht auf Führungsaufgabe vorbereitet

            Bei vielen Führungskräften lässt sich feststellen, dass sie nicht darauf vorbereitet wurden, Führungskraft zu werden. Mit etwas Glück bringen sie Vorerfahrung mit, sind hochgradig selbstreflektiert und bereiten sich daher selbst auf ihre Aufgabe vor. Dennoch ist meine Beobachtung nach wie vor, dass man sie viel zu oft im Stich lässt und sie nicht auf ihre Aufgabe vorbereitet. Eine Beobachtung, die Jan Fischbach zu teilen scheint. Er plädiert dafür, dass Führungskräfte eine „Ausbildung” benötigen. Führen will gelernt sein. Und da stimme ich ihm zu. Da ist nach wie vor viel Luft nach oben.

            https://www.teamworkblog.de/2026/07/fuhrungskrafte-brauchen-eine-ausbildung.html

              #agile boosted

              [?]Thomas 🔜 Manage Agile 2026 » 🌐
              @nobsagile@mastodon.social

              4 days in, has some gems:

              "I misused the daily as a status report."
              "I thought agile meant finishing tickets fast so I could change the plan anytime."
              "Endless upfront plans, until I learned to run experiments."

              Your turn: the most anti-agile thing you've done, and what it taught you. Any language, just tag .

              Agile Confession

              Alt...Agile Confession

                #agile boosted

                [?]Michal Bryxí [he/him] » 🌐
                @MichalBryxi@mastodon.world

                There is this huge push to “keep me honest” in the SCRUM world.

                Ok.

                So let’s not call them “burn down charts”, but “pile up charts”. Honestly we never burned anything and they never go down 🤷

                  #agile boosted

                  [?]Richard Griffiths » 🌐
                  @dectentoo@mastodon.ie

                  Estimates improve with learning

                  Every estimate is based on assumptions.

                  Development replaces assumptions with knowledge.

                  If the estimate changes because you've learned something, the process is working exactly as intended.

                    [?]Mike Bowler » 🌐
                    @mike_bowler@hachyderm.io

                    JiraMetrics v3.0 is out.

                    It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.

                    A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.

                    Full change log at jirametrics.org/changes/

                    The label JiraMetrics in the centre, on top of four quadrants, each with its own graph. Top left shows estimates against actual time elapsed, top right is a cycle time scatterplot, bottom right is work in progress by day, bottom left, is a throughput chart.

                    Alt...The label JiraMetrics in the centre, on top of four quadrants, each with its own graph. Top left shows estimates against actual time elapsed, top right is a cycle time scatterplot, bottom right is work in progress by day, bottom left, is a throughput chart.

                      [?]Mark Levison » 🌐
                      @mlevison@hachyderm.io

                      🗂️ Product Backlog Refinement is where the whole Scrum Team prepares the backlog for the next few Sprints: adding items, breaking down big ones, sharing prioritization reasoning, deleting what no longer matters.

                      Most of that is conversation, not paperwork. The value is the shared understanding. That's why GenAI won't speed it up, and shouldn't.

                      What does your team treat as paperwork here?

                      agilepainrelief.com/glossary/p

                        #agile boosted

                        [?]Agile ♻️ Agilist.in » 🌐
                        @agile@mastodon.online

                        [?]Mark Levison » 🌐
                        @mlevison@hachyderm.io

                        🤝 Building a Working Agreement? The ScrumMaster coaches, not leads. Canvass the team first on what matters: Daily Scrum time, respect, phones, equal voice.

                        Start with a check-in, then use a format where every voice is heard (I like 1-2-4 with the Decider Protocol). When someone says no, they suggest something better.

                        Every few Sprints, ask: is this still our Working Agreement?

                        agilepainrelief.com/blog/team-

                          [?]Mark Levison » 🌐
                          @mlevison@hachyderm.io

                          🚦 Most teams treat Definition of Ready as a checklist to enforce. Hold it lightly instead.

                          If items get stuck mid-Sprint, a Definition of Ready can help, but only cover the details actually causing problems now. As the team matures, make it thinner. The failure mode: it becomes a dumping ground for every little problem the team ever had.

                          Does your "Ready" gate reduce delay, or just hide it earlier?

                          agilepainrelief.com/glossary/d

                            #agile boosted

                            [?]Agile ♻️ Agilist.in » 🌐
                            @agile@mastodon.online

                            »Legacy - The One Metric on Your Greatest Legacy as a Leader, Part-3« bobgalen.substack.com/p/legacy .in

                              #agile boosted

                              [?]Richard Griffiths » 🌐
                              @dectentoo@mastodon.ie

                              Estimate the work remaining

                              When a story needs re-estimating, don't ask:

                              "How many points have we already spent?"

                              Ask:

                              "How much effort is left to finish?"

                              The work already completed is history.
                              The remaining work is what matters for planning.

                                [?]Mark Levison » 🌐
                                @mlevison@hachyderm.io

                                📋 The Product Backlog is an ordered list of the work the Product Owner wants the team to tackle next. The trouble starts when it stops being ordered and turns into a dumping ground.

                                When everything is "high priority", nothing is, and the list becomes a graveyard of ideas nobody will build. A deep backlog is well understood near the top and deliberately vague further down.

                                When did you last delete a backlog item?

                                agilepainrelief.com/glossary/p

                                  #agile boosted

                                  [?]Agile ♻️ Agilist.in » 🌐
                                  @agile@mastodon.online

                                  #agile boosted

                                  [?]Fake Scrum Stats Memes & Humor » 🌐
                                  @FakeScrumStats@techhub.social

                                  Wes Doobner shows Marge Simpson (labeled Leadership) a plate of pasta labeled Scrum. She responds "Eh..."
He then adds some butter to it and it then becomes "Scaled Agile Framework (Waterfall in disguise)" 
Marge then responds "Yowza!"

                                  Alt...Wes Doobner shows Marge Simpson (labeled Leadership) a plate of pasta labeled Scrum. She responds "Eh..." He then adds some butter to it and it then becomes "Scaled Agile Framework (Waterfall in disguise)" Marge then responds "Yowza!"

                                    #agile boosted

                                    [?]Agile ♻️ Agilist.in » 🌐
                                    @agile@mastodon.online

                                    #agile boosted

                                    [?]Toms Gedankenblog » 🌐
                                    @tomsgedankenblog.social@tomsgedankenblog.social

                                    #LINKSDERWOCHE | 29/2026: Produktivität, Lean, Agile, Politik und Gesellschaft, Satire

                                    PRODUKTIVITÄT

                                    KI im Alltag | Nur weil es technisch möglich ist, ist es noch lange nicht gut

                                    Nicht alles, was technisch möglich ist, ist auch sinnvoll oder wünschenswert. Das scheinen viele KI-Enthusiasten gerne zu vergessen. Daher spricht mir Michael Schenkel in seinem Blogartikel regelrecht aus dem Herzen. Es ist übrigens kein neues Muster, das wir hier erleben. Ich habe in den Tiefen meines Gedächtnisses nach Beispielen gesucht, bei denen übertriebene Technikgläubigkeit zu Desastern geführt hat. Mir sind auf Anhieb neben der Titanic und zwei gescheiterten Polarexpeditionen noch viele weitere Beispiele bewusst geworden. Und dabei habe ich noch nicht einmal tief gewühlt. Das Ganze führt mir vor Augen, dass bei aller Begeisterung für neue Ideen der bewusste, kritisch reflektierte Umgang extrem wichtig ist. Offensichtlich ist der Mensch nicht in der Lage, aus der Geschichte zu lernen (was man übrigens auch im Umgang mit der Nicht-Alternative in einem anderen Kontext erleben und lernen darf). Falls sich jetzt jemand fragt, weshalb ich das Thema unter Produktivität verlinke: Ich sehe die Fähigkeit zur Selbstreflexion und den kritischen Umgang mit KI in erster Linie bei uns als Individuen. Wir entscheiden, ob wir unsere und die Zeit unserer Mitmenschen mit sinnlosen Aktionen „verschwenden”.

                                    https://t2informatik.de/blog/technisch-moeglich-inhaltlich-zweifelhaft/

                                    Erfolg und Demut | Sich trotz Erfolg in Demut zu üben erdet

                                    In seinem Blogbeitrag erinnert Dan Rockwell daran, dass Erfolg sehr flüchtig sein kann und wir uns daher – bei allem Erfolg – in Demut üben sollten. Damit trifft er bei mir einen Nerv (was die Leser meiner „Gedankenblitze” vermutlich schon wissen). Ich halte es für sehr essentiell, sich immer wieder bewusst zu machen, dass Erfolg auch etwas mit „Zufall”, der Mitwirkung anderer Menschen sowie beständiger Reflexion und Lernen zu tun hat. Erfolg ist flüchtig und kann schnell kippen. Besonders, wenn wir uns in unserem Erfolg baden und in Arroganz abdriftet.

                                    https://leadershipfreak.blog/2026/07/16/the-unexpected-blunder/

                                    Schreiben | Schreiben hilft beim Denken, Strukturieren und schafft Verbindungen.

                                    Ich habe es endlich geschafft, eine Folge von Anna Koschinskis Podcast „Verbindungen schaffen” anzuhören. Im Fokus steht das Schreiben von Texten. Ich weiß, wie schwer es ist und wie viel Überwindung es kostet. Mein schriftstellerisches Talent würde ich nicht gerade als herausragend bezeichnen, und dann muss man auch noch ein Thema finden. Nach langer Übung bin ich da etwas entspannter geworden. Mir hilft das Aufschreiben beim Reflektieren. Ich notiere meine Gedanken sehr häufig, meist in Obsidian. Dadurch erhalte ich mehr Klarheit. Wenn dann mal etwas herauskommt, von dem ich denke, dass es eine sinnvolle Reife erreicht hat, entsteht daraus öfter mal ein Gedankenblitz oder noch besser ein Beitrag für den Blog des Forums Agile Verwaltung. Gut, ich schreibe nicht mit einer „professionellen” Zielsetzung. Toms Gedankenblog dient in erster Linie der eigenen Reflexion und der „verrückten” Idee, mit Gleichgesinnten in Austausch zu treten. Das ist etwas anderes. Hört einfach mal rein. Es ist auf jeden Fall hilfreich, auch wenn man selbst nicht regelmäßig Texte produzieren muss. Schreiben ist Denken und Strukturieren. Das hilft in vielen anderen Kontexten ebenso.

                                    https://verbindung-schaffen.podigee.io/74-verbindung-schreiben

                                    Vom Wissen zur Umsetzung | Wie wir es schaffen, Erkenntnisse in die Umsetzung zu bringen

                                    Ivan Blatter schafft es immer wieder, dass ich mich beim Hören seines Podcasts ertappt fühle. 😉 So auch bei der aktuellen Folge, in der es darum geht, wie wir unser neu erworbenes Wissen umsetzen. Die Erkenntnis zu haben, ist zwar der erste Schritt. Von der Erkenntnis in die Umsetzung zu kommen, ist allerdings oft viel herausfordernder, denn jede Erkenntnis bedeutet auch, an unseren Gewohnheiten zu arbeiten. Neue Erkenntnisse und neues Wissen in die Praxis umzusetzen, ist eben nicht ganz so einfach.

                                    https://share.transistor.fm/s/c986b589

                                    LEAN

                                    Umgang mit Fehlern | Echte Verantwortungsübenahme ist der Schlüssel

                                    Mark Graban bringt es auf den Punkt. Gute Führung sucht nicht nach Schuldigen, sondern übernimmt Verantwortung. Sie erkundet, wo im System Ursachen für Fehler und Probleme schlummern, und versucht, diese zu beheben. In meiner beruflichen Vergangenheit habe ich immer wieder die Erfahrung gemacht, dass nach einem Fehler ein Schuldiger gesucht und verantwortlich gemacht wurde. Damit war die Sache dann erledigt. Und was für eine Überraschung – der Fehler trat wieder auf. Denn die Ursache wurde nicht behoben. Genau das schätze ich sehr am Toyota Production System. Man sucht nicht nach Schuldigen, sondern nach Ursachen und versucht, diese zu beseitigen. Leider reicht es nicht aus, eine positive Fehlerkultur zu entwickeln, wenn die dazugehörige Lern- und Verantwortungskultur nicht vorhanden ist und die tieferliegenden Ursachen nicht beseitigt werden.

                                    https://www.leanblog.org/2026/07/how-to-react-to-a-mistake/

                                    AGILE

                                    Workshops | 3 Formate für einen guten Abschluss

                                    Ich bin immer wieder dankbar für Ideen und Ansätze, mit denen sich Workshops, Besprechungen und Austauschrunden sinnvoll gestalten lassen. Es geht darum, Formate so zu gestalten, dass sie einen erkennbaren Mehrwert schaffen. Der Blogartikel von Simon Flossmann enthält drei interessante Formate für die Abschlussrunde von Workshops, von denen ich eines tatsächlich noch nicht kannte. Sehr interessant.

                                    https://www.scrum.org/resources/blog/3-workshop-methoden-so-gestaltest-du-das-ende-deines-workshops-so-dass-es-erinnerung-bleibt

                                    Scrum-Kumbaya | Zu viel des Guten oder Scrum Master über das Ziel hinausschießen

                                    Ich bin begeisterter Lean- und Agile-Enthusiast. Mit selbstorganisierten Teams zu arbeiten, ist das Größte für mich. Das macht mir mehr Freude als alles andere. Ich gehe davon aus, dass ich es mit mündigen Erwachsenen zu tun habe. Erwachsene und mündige Menschen in einem Team. Die „gescheiterten Sozialarbeiter-Scrum-Master” sind mir daher schon öfter unangenehm aufgefallen. Scrum ist kein Selbstzweck. Und es braucht auch kein „Scrum Kumbaya”, wie Mary Iqubal es treffend überschrieben hat (den Begriff muss ich mir merken). Noch einmal: Wir haben es mit erwachsenen, mündigen Fachleuten zu tun, die lösungsfokussiert zusammenarbeiten und hochwertige Ergebnisse erzielen wollen und sollen. Meine Aufgabe als Scrum Master ist es, den Rahmen dafür zu schaffen, dass ein Team produktiv zusammenarbeiten kann. Mein Job ist es nicht, ein Team zu „betüdeln”. Ganz im Gegenteil. Ich muss einen Rahmen schaffen, damit das Team produktiv arbeiten kann, und es auch herausfordern, wenn die Ergebnisse nicht stimmen. Eine positive Arbeitsatmosphäre kann dabei helfen, aber man kann auch deutlich über das Ziel hinausschießen. „Scrum Kumbaya” ist ein Beispiel dafür.

                                    https://www.scrum.org/resources/blog/scrum-kumbaya

                                    Explore vs Exploit | Eine Simulation für das Lernen als Team

                                    Thomas Schissler stellt in seinem Beitrag eine sehr praxisnahe Simulation mit Verbindungen zur Praxis in vielen Teams vor. Im Fokus stehen die Arbeitsmodi „Explore” und „Exploit”. Das Interessante an seinem Beitrag ist, dass er nicht nur das spielerische Format ins Spiel bringt, sondern auch gleich die Brücke zur gelebten Teampraxis schlägt und somit aufzeigt, wie diese Simulation Teams dabei helfen kann, das richtige Maß zwischen „Explore” und „Exploit” zu finden. Das ist mit Sicherheit etwas, das sich für den einen oder anderen Workshop nutzen lässt. Mal sehen, ob ich Gelegenheit bekomme, es selbst auszuprobieren.

                                    https://www.scrum.org/resources/blog/explore-vs-exploit-ein-kleines-spiel-uber-zwei-fundamentale-arbeitsmodi

                                    Schätzung | Schätzungen sind Wetten mit hoher Unsicherheit

                                    Ich persönlich halte vom Schätzen der „Liefergeschwindigkeit” in komplexen Kontexten wenig. Schätzen ist hingegen sehr gut geeignet, um die Größe von Produktinkrementen einzuordnen. Für die Prognose eines Liefertermins taugt es hingegen wenig, da wir hier von einer Wette ausgehen, die auf vielen Unbekannten basiert. Liegt die Schätzung daneben, kommt es meist zu der von Dave West beschriebenen Reaktion. Verlässliche Prognosen erhalte ich in der Regel erst durch aussagekräftige historische Daten, die bei Entwicklungsprojekten – je nach Art der zu erledigenden Arbeit – oft nicht vorliegen. Während ich repetitive Aufgaben, für die ich vergleichbare Daten habe, sehr gut prognostizieren kann, ist es bei explorativen Tätigkeiten gerade wegen der fehlenden Qualität der Daten ein sehr unsicheres Spiel. Sehr erfahrene Teams haben zwar mit der Zeit aufgrund von historischen Daten und Erfahrungen ein gutes „Gefühl” dafür entwickelt, wie verlässlich sie liefern können, aber auch hier steckt sehr viel Erkenntnis aus der Vergangenheit drin. Und diese ist bei einem hochkomplexen Projekt nicht vorhanden. Prognosen sollten daher als „Wetten” mit hoher Unsicherheit verstanden werden, die im Laufe der Zeit aber immer genauer und präziser werden können. Nicht als exakter Plan. Regelmäßige Kommunikation über neue Erkenntnisse und deren Auswirkungen auf die Prognose ist daher extrem wichtig.

                                    https://www.scrum.org/resources/blog/your-team-isnt-bad-estimating-planning-just-harder-we-admit

                                    Umgang mit Fehlern | Wenn niemand die Wahrheit sagt, weil das System bestraft

                                    Steve Denir beschreibt ein Problem, das Kurt Tucholsky einst in einem anderen Kontext sehr treffend umschrieben hat: „Im Übrigen gilt hier ja derjenige, der auf den Schmutz hinweist, als viel gefährlicher als derjenige, der den Schmutz macht.“ Die Wirkung sollte jedem klar sein. Wer auf einen Fehler hinweist und dafür an den Pranger gestellt wird, wird es nie wieder tun. Und alle, die so etwas auch nur im Geringsten mitbekommen haben, werden es dieser Person gleichtun. Lernen für die Zukunft? Keine Chance. Ich kann mich gut an die Idee eines Lean-Enthusiasten erinnern, jeden entdeckten Fehler zu feiern. Anstatt einen Schuldigen zu suchen, sollte man sich auf die strukturellen Ursachen konzentrieren und eben diese beseitigen. Das ist übrigens etwas, das ich an „echten” Lean-Adaptionen sehr schätze, bei denen ich den Eindruck habe, dass Kaizen gelebte Realität ist. Nur mal so nebenbei.

                                    https://www.scrum.org/resources/blog/your-people-stopped-telling-you-truth-you-trained-them

                                    POLITIK UND GESELLSCHAFT

                                    Doppelmoral | Wenn Politik im Elfenbeinturm den Kompass verliert

                                    Zu den Blogs, die ich fast täglich lese, gehört der von Heinrich Kümmerle. Er sagt, was er denkt. Und das gefällt mir. Wir kennen uns auch persönlich. Nicht immer bin ich seiner Meinung, aber das weiß er auch. Er gehört zu den wenigen Menschen, bei denen ich weiß, dass ein Meinungsaustausch nicht dazu führt, dass man hinterher – auch bei einem Dissens – kein Bier miteinander trinken gehen kann. Was uns beide eint, ist, dass wir überzeugte Demokraten und europäische Föderalisten sind. Mit dem verlinkten Blogartikel trifft er aktuell einen Nerv: die Doppelmoral mancher Politiker, die offenbar seit vielen Jahren nicht mehr aus ihrem Elfenbeinturm herausgekommen sind. An dieser Stelle ein kurzer Einschub: Bei aller berechtigter Kritik gibt es keinen Grund, einer Partei die Stimme zu geben, die auf die Abschaffung der freiheitlich-demokratischen Grundordnung abzielt. Noch dazu übertrifft sie in puncto krimineller Energie selbst die genannten Vertreter der Doppelmoral.

                                    https://kuemmerle.name/doppelmoral/

                                    Visionen | Uns fehlt es an handlungsleitenden Zukunftsbildern

                                    Roland Dürre bringt es auf den Punkt: „Wir leben in einer Welt, die arm an Visionen geworden ist.“ Und das ist ein Problem. Wir brauchen klare Leitbilder. Positiv formulierte Leitbilder für die Zukunft, die es schaffen, die „Spaltung“ zu überwinden und Hoffnung zu stiften. Das ist ein schöner Denkanstoß, der mich diese Woche auch schon zu einem Gedankenblitz verleitet hat und den ich an dieser Stelle gerne weitergeben möchte.

                                    https://www.if-blog.de/rd/visionen/

                                    SATIRE

                                    AInüchterung | Über die „Überhöhung“ der KI

                                    Ich gebe zu, die Flut an Blogartikeln, die um jeden Preis etwas mit KI einbauen müssen, geht mir gewaltig auf den Nerv. Die „KI-Euphorie” scheint bei einigen schon fast neurotische Züge anzunehmen. Wenn ich mir so manchen von der KI glattgebügelten Artikel durchlese, vergeht mir auch langsam die Lust, so manchen Blog zu lesen. Es ist schön, wenn jemand das Ganze mal humoristisch auf die Hörner nimmt, wie „Buddy Müller” in seiner Agentursatire. So wie „Buddy Müller” in seiner Agentursatire. Ich habe herzhaft gelacht, auch wenn mir angesichts der Tatsache, was manche Manager meinen, durch KI günstiger machen zu können, eigentlich das Lachen vergehen müsste. Nur weil etwas technisch möglich ist, muss es nicht gut sein – damit schließt sich der Kreis zu den heutigen Links der Woche. 😉

                                    https://agentursatire.blog/2026/07/18/folge52-diegroseairnuchterung/

                                      #agile boosted

                                      [?]Thomas 🔜 Manage Agile 2026 » 🌐
                                      @nobsagile@mastodon.social

                                      Man verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.

                                      Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.

                                      VERANTWORTUNG
ohne Befungnis

                                      Alt...VERANTWORTUNG ohne Befungnis

                                        #agile boosted

                                        [?]Richard Griffiths » 🌐
                                        @dectentoo@mastodon.ie

                                        Estimates aren't promises

                                        An estimate is our best understanding of the effort involved based on what we know today.

                                        It isn't a contract.
                                        It isn't a deadline.
                                        It isn't a guarantee.

                                        As we learn more, the estimate may change. That's good engineering, not poor planning.

                                          Cat Hicks boosted

                                          [?]ralf warümme tauscher » 🌐
                                          @derralf@friends.librescrum.org

                                          oh, a new book arrived in germany
                                          thanks @grimalkina for writing it.

                                          @agile

                                          the psychology of software teams by cat hicks on a wooden table

                                          Alt...the psychology of software teams by cat hicks on a wooden table

                                            #agile boosted

                                            [?]Sebastian Stautz » 🌐
                                            @SebastianSolidwork@mastodon.social

                                            RE: hachyderm.io/@mlevison/1169303

                                            From Mark: "There are many cases where I don’t love the language of the Scrum Guide. It can be too formal and heavy."

                                            enteresc.net/done-is-not-just-

                                            [?]Mark Levison » 🌐
                                            @mlevison@hachyderm.io

                                            @SebastianSolidwork I just pushed a change to the “Done" glossary entry. I added: compromising on Done (and thereore quality)

                                            I can also see the relationship idea you offer in your post.

                                            There are many cases where I don’t love the language of the Scrum Guide. It can be too formal and heavy.

                                                #agile boosted

                                                [?]Retro Point » 🌐
                                                @retropoint@mastodon.moscow

                                                Что делать, если команда обсуждает не только прошедший спринт, но и тревожится о будущем?

                                                Glad, Sad, Mad, Afraid добавляет к знакомой эмоциональной ретроспективе четвёртый вопрос: чего мы опасаемся дальше. В новой статье разбираем четыре колонки, правила безопасного разговора и сценарий встречи на 55 минут.

                                                Читать: retropoint.ru/news/glad-sad-ma

                                                  #agile boosted

                                                  [?]Mark Levison » 🌐
                                                  @mlevison@hachyderm.io

                                                  🧭 By default we humans spend about 5% of our time planning and 95% implementing. The research says it should be closer to 20% planning, 80% action.

                                                  I found that in Chris Bailey's Intentional. In Scrum, Sprint Planning, Review, Retrospective, and Daily Scrum are all about planning and goal attainment, about 10% of the Sprint. Scrum anticipated that research by more than a decade.

                                                  The usual "too much planning" pushback is misplaced.

                                                  agilepainrelief.com/newsletter

                                                    [?]Mark Levison » 🌐
                                                    @mlevison@hachyderm.io

                                                    ✅ The 2020 Scrum Guide made Definition of Done a formal commitment. Done is not optional: it's the team's promise about what "complete" means.

                                                    The hardest problem is pressure to deliver more. As it builds, teams compromise on Done. Short term it looks fine, they get more finished. Long term the bugs offset the value, and each shortcut accumulates as technical debt that slows future work.

                                                    Only take on work you can bring to truly Done.

                                                    agilepainrelief.com/glossary/d

                                                      [?]Mark Levison » 🌐
                                                      @mlevison@hachyderm.io

                                                      📋 The Sprint Backlog is Scrum's most misunderstood artifact. It's not a list of tickets or tasks (thanks, JIRA), it's a tool for the team to see what's going on and how it's progressing.

                                                      Two quiet anti-patterns: pre-assign every item in Sprint Planning and you've planned for the first bottleneck. Use it for reporting and leadership starts looking over shoulders, so transparency dies.

                                                      It's a plan by and for the Developers.

                                                      agilepainrelief.com/blog/the-h

                                                        [?]Thomas 🔜 Manage Agile 2026 » 🌐
                                                        @nobsagile@mastodon.social

                                                        Eine Story, die 20 Tage dauert, ist keine Story. Das ist ein Projekt im Ticket-Kostüm.

                                                        Die üblichen Argumente für große Stories ("einfacheres Handling", "Kontext bleibt erhalten") sind alle Projektmanagement-Denke. Der Sinn einer Story ist aber Wert liefern und Feedback holen. Dauert das länger als zwei Wochen, ist sie zu groß.

                                                        Kleiner schneiden. Immer.

                                                        KEINE STORY
EIN PROJEKT IM TICKET-KOSTUM

                                                        Alt...KEINE STORY EIN PROJEKT IM TICKET-KOSTUM

                                                          #agile boosted

                                                          [?]Agile ♻️ Agilist.in » 🌐
                                                          @agile@mastodon.online

                                                          #agile boosted

                                                          [?]Agile ♻️ Agilist.in » 🌐
                                                          @agile@mastodon.online

                                                          #agile boosted

                                                          [?]Retro Point » 🌐
                                                          @retropoint@mastodon.moscow

                                                          🏖 В RetroPoint появился новый модуль «Отпуска и дни рождения»!

                                                          Теперь команда может видеть отпуска, Day-Off и больничные на общей временной шкале, а сотрудники — подавать заявки на отсутствие. Тимлид или мастер согласует их прямо в сервисе.

                                                          🎂 Календарь покажет ближайшие дни рождения коллег.
                                                          🔔 Email-напоминания помогут не пропустить важную дату и вовремя проверить остаток отпуска.

                                                          Меньше отдельных таблиц и переписки, больше прозрачности при планировании работы команды.

                                                          Подробнее: retropoint.ru/news/absences-bi

                                                          @rf @Russia@3zi.ru @russia@lemmy.ml

                                                            #agile boosted

                                                            [?]Agile ♻️ Agilist.in » 🌐
                                                            @agile@mastodon.online

                                                            #agile boosted

                                                            [?]Retro Point » 🌐
                                                            @retropoint@mastodon.moscow

                                                            Команда набирает высоту, но что помогает ей лететь, что тянет вниз и какие бури уже видны на горизонте? 🎈
                                                            В новой статье разбираем ретроспективу Hot Air Balloon. Объясняем зоны Hot air, Sandbags и Storms, даём сценарий встречи примерно на 50 минут и показываем, как перейти от метафоры к конкретным действиям. ⛈️

                                                            Готовый шаблон уже есть в RetroPoint 🚀
                                                            retropoint.ru/news/hot-air-bal

                                                              #agile boosted

                                                              [?]Thomas 🔜 Manage Agile 2026 » 🌐
                                                              @nobsagile@mastodon.social

                                                              „Feedback ist keine Information. Es ist erst dann Feedback, wenn das nächste Stück Arbeit dadurch verändert wird."

                                                              no-bullshit-agile.de/nbak09-wo

                                                                #agile boosted

                                                                [?]Thomas 🔜 Manage Agile 2026 » 🌐
                                                                @nobsagile@mastodon.social

                                                                Wirf allen Ballast ab: Zertifikate, Rollen, Rituale und es bleiben zwei Begriffe: Work und Feedback.

                                                                Deine Agilität misst sich nicht an Zertifikaten oder Code-Zeilen, sondern an der Geschwindigkeit dieses Kreislaufs.

                                                                Der wichtigste Satz: Feedback ist erst dann Feedback, wenn es die nächste Arbeit verändert. Passiert das nicht, ist das kein Mindset- sondern ein Kopplungsproblem.

                                                                Neue Folge NBA Kompakt:
                                                                no-bullshit-agile.de/nbak09-wo

                                                                Alt...NBAK09: Work – Feedback. Der einzige Kreislauf, der zählt

                                                                  #agile boosted

                                                                  [?]Agile ♻️ Agilist.in » 🌐
                                                                  @agile@mastodon.online

                                                                  #agile boosted

                                                                  [?]Leanpub » 🌐
                                                                  @leanpub@mastodon.social

                                                                  NEW! Leanpub Book LAUNCH 🚀 Deliver What Matters When It Matters: Value-Driven Product Delivery through Clarity, Timing, and Flow by Ryan

                                                                  youtu.be/yIV0KO8KV6c

                                                                    Back to top - More...