#agile — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #agile, aggregated by home.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.https://no-bullshit-agile.de/warum-daily-standups-oft-scheitern-und-wie-man-sie-wiederbelebt.html
-
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.https://no-bullshit-agile.de/warum-daily-standups-oft-scheitern-und-wie-man-sie-wiederbelebt.html
-
I am looking for archives of early #pattern/ #OOP mailinglists, like the University of Illinois ones linked on https://hillside.net/patterns/mailing-lists
Aside of general interest in the history of #agile methods, I would also be curious about discussions about @k9ox ’s C2 wiki. -
I am looking for archives of early #pattern/ #OOP mailinglists, like the University of Illinois ones linked on https://hillside.net/patterns/mailing-lists
Aside of general interest in the history of #agile methods, I would also be curious about discussions about @k9ox ’s C2 wiki. -
His tags: #infosec, #agile, #systemsthinking
Thank you very much for your work as a volunteer and your support in organizing the Open Security conference
-
His tags: #infosec, #agile, #systemsthinking
Thank you very much for your work as a volunteer and your support in organizing the Open Security conference
-
RE: https://mastodon.social/@Berufebilder/116990885908664913
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.
-
RE: https://mastodon.social/@Berufebilder/116990885908664913
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.
-
Avec @pablopernot nous ouvrons à tous la masterclass Scrum et agilité
#scrum #agile
https://claudeaubry.fr/post/2026/masterclass-for-free/ -
Avec @pablopernot nous ouvrons à tous la masterclass Scrum et agilité
#scrum #agile
https://claudeaubry.fr/post/2026/masterclass-for-free/ -
@nobsagile Ja. KI kann man nicht mehr ignorieren und doch noch nicht als selbstverständlich annehmen. Aus eigener Anschauung kenne ich ein großes Unternehmen, bei dem sich KI auf einen hauseigenen Chatbot und Copilot-Chat beim Coden beschränkt. Ich nehme an, dass dies nicht der berühmte bedauerliche Einzelfall ist. Die Chancen und Limits fürs Coding sind lang und breit beschrieben, die für Wissensarbeit wie #Agile, #Projektmanagement, Team-#Coaching und #Organisationsentwicklung m.E. noch nicht.
-
@nobsagile Ja. KI kann man nicht mehr ignorieren und doch noch nicht als selbstverständlich annehmen. Aus eigener Anschauung kenne ich ein großes Unternehmen, bei dem sich KI auf einen hauseigenen Chatbot und Copilot-Chat beim Coden beschränkt. Ich nehme an, dass dies nicht der berühmte bedauerliche Einzelfall ist. Die Chancen und Limits fürs Coding sind lang und breit beschrieben, die für Wissensarbeit wie #Agile, #Projektmanagement, Team-#Coaching und #Organisationsentwicklung m.E. noch nicht.
-
Wie jeden Montag: Eine sehr gute "Presseschau".
-
Wie jeden Montag: Eine sehr gute "Presseschau".
-
#LINKSDERWOCHE | 30/2026: Produktivität, Lean, Agile, Mangement und Leadership
Photo by Pixabay on Pexels.comPRODUKVITIÄ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 #Führung #Impediments #Kaizen #Leadership #Lean #Mangement #Obsidian #Produktivität #Prototypentest #Scheitern #Scrum #Standardisierung -
#LINKSDERWOCHE | 30/2026: Produktivität, Lean, Agile, Mangement und Leadership
Photo by Pixabay on Pexels.comPRODUKVITIÄ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 #Führung #Impediments #Kaizen #Leadership #Lean #Mangement #Obsidian #Produktivität #Prototypentest #Scheitern #Scrum #Standardisierung -
Ansible for DevOps by Jeff Geerling is on sale on Leanpub! Its suggested price is $9.99; get it for $6.99 with this coupon: https://leanpub.com/ansible-for-devops/c/LeanPublishingDaily20260723 #agile #software #startups #ansible #devops #cloud_computing
-
Ansible for DevOps by Jeff Geerling is on sale on Leanpub! Its suggested price is $9.99; get it for $6.99 with this coupon: https://leanpub.com/ansible-for-devops/c/LeanPublishingDaily20260723 #agile #software #startups #ansible #devops #cloud_computing
-
4 days in, #AgileConfessions 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 #AgileConfessions.
-
4 days in, #AgileConfessions 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 #AgileConfessions.
-
Нужна ли проектная документация в 26 году и что если ты пришел на новый проект, а там хаос и пустота?
«Это же бюрократия, у нас и так всё работает!» / «Документация — это отлично, но у нас есть задачи поважнее» / «Катя, я пришла на проект, а у них ничего, а у нас аудит». Эти фразы и еще много подобного я слышала так много раз, что кажется, время этой статьи пришло). Мой путь от скептика к как меня в шутку называют коллеги «документатору‑злодею» и мысли о том, зачем же нам все таки нужно уметь и делать проектную документацию. Путь от скептика к «документатору-злодею»
https://habr.com/ru/articles/1062894/
#документация_проекта #требования_заказчика #требования_к_системе #agile #аналитика #системный_анализ #системный_анализ_2026 #бизнесанализ #управление_проектами #itстандарты
-
Dein Team ist nicht langsam. Euer Feedback kommt zu spät.
Feedback hat ein Verfallsdatum. Ein Signal, das erst nach Monaten ankommt, lenkt keine Entscheidung mehr.
Der Engpass ist nie das Signal. Es ist die Zeit bis zur Entscheidung.
Frag dich: Wie lange dauert es bei euch von Idee bis echtem Feedback?
https://no-bullshit-agile.de/nbak11-feedback-kommt-zu-spaet.html
-
Dein Team ist nicht langsam. Euer Feedback kommt zu spät.
Feedback hat ein Verfallsdatum. Ein Signal, das erst nach Monaten ankommt, lenkt keine Entscheidung mehr.
Der Engpass ist nie das Signal. Es ist die Zeit bis zur Entscheidung.
Frag dich: Wie lange dauert es bei euch von Idee bis echtem Feedback?
https://no-bullshit-agile.de/nbak11-feedback-kommt-zu-spaet.html
-
⏳ A counterpoint to a favourite Agile idea. The Last Responsible Moment says: delay a decision until failing to decide eliminates an important alternative.
But Rebecca Wirfs-Brock argues for the "most responsible moment", deciding when you know enough to choose well, not nervously delaying. "Last" keeps you flexible; "most" keeps you from brinkmanship.
Delaying to stay flexible, or to avoid deciding?
-
⏳ A counterpoint to a favourite Agile idea. The Last Responsible Moment says: delay a decision until failing to decide eliminates an important alternative.
But Rebecca Wirfs-Brock argues for the "most responsible moment", deciding when you know enough to choose well, not nervously delaying. "Last" keeps you flexible; "most" keeps you from brinkmanship.
Delaying to stay flexible, or to avoid deciding?
-
Dew Drop Weekly Newsletter 493 - Week Ending July 24, 2026
#dewdrop #newsletter #azure #javascript #css #aspnetcore #blazor #cpp #xaml #windowsdev #csharp #dotnet #ai #mcp #devops #agile #agents #python #appdev #dotnetmaui #podcasts #m365 #data #sqlserver #cli #terminal
-
Dew Drop Weekly Newsletter 493 - Week Ending July 24, 2026
#dewdrop #newsletter #azure #javascript #css #aspnetcore #blazor #cpp #xaml #windowsdev #csharp #dotnet #ai #mcp #devops #agile #agents #python #appdev #dotnetmaui #podcasts #m365 #data #sqlserver #cli #terminal
-
what a nice start today to appear on the same page with @JuttaEckstein and
@kareni assume we were always on the same page. and now visible to anyone 🥰
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.
-
what a nice start today to appear on the same page with @JuttaEckstein and
@kareni assume we were always on the same page. and now visible to anyone 🥰
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.
-
@andre Die These kann ich aus der Praxis bestätigen.
Crossfunktionale Teams, Anwendernähe, Transparenz, Feedback Loops, Service Safaris, gemeinsames Lernen, schnelle Entscheidungen, angemessene Komplexität.
Wenn man echtes agiles Arbeiten in der Organisation zulässt, kann man Software in sehr kurzer Zeit herstellen.
KI kann unterstützen, ist für mich aber nicht der Schlüssel.
Die Verzögerung kommt nicht durch die Technik, sondern die Strukturen.
-
@andre Die These kann ich aus der Praxis bestätigen.
Crossfunktionale Teams, Anwendernähe, Transparenz, Feedback Loops, Service Safaris, gemeinsames Lernen, schnelle Entscheidungen, angemessene Komplexität.
Wenn man echtes agiles Arbeiten in der Organisation zulässt, kann man Software in sehr kurzer Zeit herstellen.
KI kann unterstützen, ist für mich aber nicht der Schlüssel.
Die Verzögerung kommt nicht durch die Technik, sondern die Strukturen.
-
🫧 I've survived every Gartner Hype Cycle, and GenAI is the noisiest. It reminds me of the dot-com bubble: built on the promise the internet would change everything. It did, just later than Pets.com and WebVan expected.
Here's what's clarifying: if it's a bubble, we still keep tools like today's. If not, the changes are much larger. Either way, we adapt. Agile is more relevant than ever.
https://agilepainrelief.com/newsletter-subscribe/?utm_source=mastodon&utm_campaign=archive-reshare
-
🫧 I've survived every Gartner Hype Cycle, and GenAI is the noisiest. It reminds me of the dot-com bubble: built on the promise the internet would change everything. It did, just later than Pets.com and WebVan expected.
Here's what's clarifying: if it's a bubble, we still keep tools like today's. If not, the changes are much larger. Either way, we adapt. Agile is more relevant than ever.
https://agilepainrelief.com/newsletter-subscribe/?utm_source=mastodon&utm_campaign=archive-reshare
-
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 https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
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 https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
RE: https://mastodon.social/@workchronicles/116968690478302316
That's what I mean when I say that politics in systems are stronger that economical decisions. There is not such thing as Homo oeconomicus. Only in small companies...
Look at this fact if you try to figure out why #agile is not working -
RE: https://mastodon.social/@workchronicles/116968690478302316
That's what I mean when I say that politics in systems are stronger that economical decisions. There is not such thing as Homo oeconomicus. Only in small companies...
Look at this fact if you try to figure out why #agile is not working -
-
-
RE: https://troet.cafe/@Asterix_Archiv/116967765118507770
Wenn Scrum Master zu Hause leise weinen.....
-
RE: https://troet.cafe/@Asterix_Archiv/116967765118507770
Wenn Scrum Master zu Hause leise weinen.....
-
"Yes, you can have better and faster and cheaper, it just takes discipline."
-
"Yes, you can have better and faster and cheaper, it just takes discipline."
-
Monthly SIP inflows in India hit 26,000 crore in March 2026, and this milestone has an unexpected parallel in cloud cost management. https://hackernoon.com/cloud-spend-needs-regular-review #agile
-
Confession time.
Years ago I rolled Scrum out with my team strictly by the Guide. Sprints, points, standups, all of it. Truth is, I hadn't understood the first thing about agile. Pure cargo cult, and I couldn't even see it at the time.
Your turn: what's the most anti-agile thing you've done, and what did it teach you?
Answer in any language. Tag #AgileConfessions so we find each other.
If you like, nudge 1 to 3 people you'd want to hear from. No pressure.
#programming #coding #agile
