No Bullshit Agile

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/27-nba12-vertrauen-geben

Zusammenfassung

In Folge 12 von No Bullshit Agile beschäftigt sich Thomas mit dem zentralen, aber herausfordernden Thema Vertrauen. Er erläutert, wie entscheidend Vertrauen für die Effektivität und Effizienz eines Teams ist und wie das Fehlen von Vertrauen zu Mikromanagement, Kommunikationsproblemen und einer verringerten Teamleistung führen kann.

Thomas betont, dass Vertrauen ein Vorschuss ist, den man selbst geben muss, ohne auf andere zu warten. Er erläutert, dass fehlendes Vertrauen oft auf persönliche Unsicherheiten, frühere negative Erfahrungen oder die Angst vor Kontrollverlust zurückzuführen ist. Um Vertrauen aufzubauen, sollten Führungskräfte ihre Teammitglieder in Entscheidungsprozesse einbinden, Feedback einholen und ein unterstützendes Umfeld schaffen.

Er gibt praktische Tipps, wie man Vertrauen fördern kann, und warnt vor den negativen Konsequenzen, die entstehen, wenn Vertrauen missbraucht wird, einschließlich verminderter Mitarbeiterbindung und Innovationsfähigkeit. Abschließend fordert er dazu auf, bei Vertrauensproblemen den Dialog zu suchen und gegebenenfalls Maßnahmen zu ergreifen, um das Vertrauen wiederherzustellen oder die Zusammenarbeit neu zu bewerten.

Links

Letzte Folge „NBA11: Wertvoll: One on One mit Teammitgliedern“

Agiles Radar

Artikel „Ohne Vertrauen keine Agilität: Tipps für eine vertrauensvolle Teamkultur“

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/25-nba11-wertvoll-one-on-one-mit-teammitgliedern

Zusammenfassung

In Folge 11 von No Bullshit Agile beleuchtet Thomas die Bedeutung und den Nutzen von One-on-Ones im agilen Umfeld. Diese regelmäßigen Einzelgespräche bieten jedem Teammitglied einen wichtigen Raum, um über aktuelle Herausforderungen, Entwicklungen und persönliche Anliegen zu sprechen.

Thomas erklärt, dass One-on-Ones nicht die klassischen Feedback-Formate wie Peer-Feedback oder Jahresgespräche ersetzen, sondern speziell dem Tagesgeschäft dienen. Die Regelmäßigkeit der Gespräche sollte angepasst werden: wöchentlich für kleine Teams und alle zwei Wochen für größere. Er empfiehlt, feste Termine zu etablieren, um einen zuverlässigen Rhythmus zu schaffen.

Der Schlüssel zu erfolgreichen One-on-Ones liegt im Zuhören. Thomas nutzt Leitfragen als Orientierung, um das Gespräch zu strukturieren und wichtige Themen anzusprechen. Diese Fragen helfen, Themen wie Hindernisse, Unterstützung, Motivation und Teaminteraktion zu erörtern, sollten aber flexibel gehandhabt werden.

Er betont, dass One-on-Ones ein wertvolles Führungsinstrument sind, auch wenn die Gespräche nicht immer produktiv erscheinen oder sofort zu Ergebnissen führen. Wichtig ist, den Teammitgliedern Raum zu geben und sicherzustellen, dass sie sich öffnen können. Die Gespräche bieten Einblicke in die Bedürfnisse und Perspektiven der Teammitglieder und stärken die Kommunikation und Zusammenarbeit im Team.

Links

Letzte Folge „NBA10: Ein allzu oft vernachlässigtes Instrument in der Führung“

Artikel zum aktiven Zuhören

Leitfragen One on One

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/22-nba10-ein-allzu-oft-vernachlaessigtes-instrument-in-der-fuehrung

Zusammenfassung

In Folge 10 von No Bullshit Agile widmet sich Thomas einem oft vernachlässigten, aber wesentlichen Führungstool: dem aktiven Zuhören. Er reflektiert seine eigene Schwierigkeit, wirklich zuzuhören, und teilt eine prägende Erfahrung aus einem Kommunikationsseminar, die ihm die Bedeutung des Zuhörens verdeutlichte.

Thomas hebt hervor, dass es zwei Hauptarten von Meetings gibt: Informationsveranstaltungen und Workshops, bei denen gemeinsam Wissen erarbeitet wird. Besonders bei Workshops und One-on-Ones ist aktives Zuhören entscheidend, um relevantes Feedback und Ideen zu erfassen.

Er empfiehlt, in One-on-Ones möglichst wenig zu kommentieren und stattdessen durch Fragen wie „Was noch?“ den Gesprächspartner zum weiteren Reden zu ermutigen. Diese Technik hilft, verborgene Informationen und Potenziale zu entdecken und verbessert die Qualität der Kommunikation.

Zusammengefasst ist aktives Zuhören ein unverzichtbares Instrument, um wertvolle Informationen zu erhalten und die Kommunikation im Team zu stärken.

Links

Letzte Folge „NBA09: Agilität von SpaceX“

Spielkarten

NBA06: Die 12 Agilen Prinzipien

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/19-nba09-agilitaet-von-spacex

Zusammenfassung

In Folge 9 von No Bullshit Agile beleuchtet Thomas, wie SpaceX Agilität in der Hardware-Entwicklung umsetzt, insbesondere bei der Entwicklung des Starship. Er vergleicht den iterativen Ansatz von SpaceX mit den traditionellen, langwierigen Methoden der Raumfahrtindustrie, wie beim Space Shuttle.

SpaceX verfolgt eine agile Methode durch den Einsatz von iterativen Schritten und kontinuierlichem Lernen. Die Entwicklung beginnt mit kleinen, schnellen Tests wie dem Star Hopper, um erste Erkenntnisse zu sammeln. Diese iterativen Tests ermöglichen schnelle Anpassungen und Verbesserungen, wie etwa bei den ersten erfolgreichen und weniger erfolgreichen Startversuchen des Starship.

Die schnelle Abfolge der Tests und die Anpassungen an der Infrastruktur zeigen, wie Agilität nicht nur in der Software-, sondern auch in der Hardware-Entwicklung effektiv eingesetzt werden kann.

Er schließt mit der Beobachtung, dass SpaceX eine agile Methodik verfolgt, die es ihnen ermöglicht, kontinuierlich zu lernen und ihre Technologie zu verbessern, was eine spannende Parallele zur Agilität in der Softwareentwicklung darstellt.

Links

Letzte Folge „NBA08: Prioritäten sind quatsch und ich erklär dir auch warum“

Webseite

Forum

Falcon 9

Starship

Super Heavy

Space Shuttle

Raptor

Starhopper

Starbase (Boca Chica)

Youtube Empfehlungen

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/12-nba08-prioritaeten-sind-quatsch

Zusammenfassung

In Folge 8 von No Bullshit Agile stellt Thomas die traditionelle Praxis von Prioritäten in Frage und argumentiert, dass sie oft nicht zielführend ist. Er erklärt, dass Prioritäten nur zu einem bestimmten Zeitpunkt sinnvoll sind, da sich Anforderungen und Umstände ständig ändern können.

Thomas kritisiert, dass die Priorisierung von Aufgaben nicht die Kapazitätsgrenzen eines Teams berücksichtigt und oft zu unrealistischen Erwartungen bei Kunden führt. Statt sich starr an einen Prioritätenplan zu halten, plädiert er für eine kontinuierliche Anpassung und Priorisierung von Aufgaben basierend auf dem aktuellen Kontext und den sich entwickelnden Anforderungen.

Er bevorzugt einen flexiblen Ansatz, wie ihn Kanban bietet, und betont die Bedeutung von regelmäßiger Kommunikation mit dem Kunden, um gemeinsam eine sinnvolle Reihenfolge von Aufgaben zu bestimmen. Prioritäten sollten nicht als feste Vorgaben betrachtet werden, sondern als dynamisches Werkzeug, das regelmäßig überprüft und angepasst wird.

Thomas fordert dazu auf, mit Kunden darüber zu diskutieren, wie Prioritäten in der Praxis sinnvoller gestaltet werden können und zeigt sich offen für alternative Ansätze und Erfahrungen von anderen.

Links

Letzte Folge „NBA07: Selbstorganisation in der Praxis“

Webseite

Forum

Spielkarten Agiles Manifest

Illusion Priorität

NBA04: Scrum: Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/9-nba07-selbstorganisation-in-der-praxis

Zusammenfassung

In Folge 7 von No Bullshit Agile widmet sich Thomas dem Thema Selbstorganisation und gibt praktische Tipps, wie man persönliche Aufgaben und Anforderungen effizient managen kann. Er unterscheidet zwischen terminlich gebundenen und nicht terminlich gebundenen Aufgaben, wobei ersteres leichter zu handhaben ist, während letztere ein verlässliches System benötigen.

Thomas plädiert dafür, Aufgaben in ein einfach zugängliches System aufzunehmen, das schnell und effizient zu nutzen ist – unabhängig davon, ob es sich um eine App oder eine andere Form der Notizführung handelt. Er kritisiert komplexe Systeme wie Notion oder Obsidian, die oft nicht benutzerfreundlich sind. Stattdessen empfiehlt er, Aufgaben in kleine, konkrete Schritte zu zerlegen und regelmäßig zu überprüfen, um den Überblick zu behalten.

Er betont, dass der konkrete Plan oft nicht exakt eingehalten werden kann und dass das Planen selbst, nicht der Plan, von Wert ist. Praktische Tipps umfassen die Nutzung von Apple Notes für Aufgaben, das Festhalten von Notizen auf Papier und regelmäßige Überprüfungen des Systems. Thomas empfiehlt in bestimmten Situationen, aber nicht immer, feste Zeiten für die Bearbeitung von Aufgaben im Kalender einzuplanen und betont, dass Disziplin und regelmäßige Pflege des Systems entscheidend für den Erfolg sind.

Links

Letzte Folge „NBA06: Die 12 Agilen Prinzipien

GTD

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/8-nba06-die-12-agilen-prinzipien

Zusammenfassung

In Folge 6 von No Bullshit Agile beleuchtet Thomas die 12 agilen Prinzipien aus dem Agile Manifest und deren praktische Relevanz. Er geht auf jedes Prinzip ein und erklärt, wie es in der Praxis umgesetzt werden kann:

Frühe und kontinuierliche Auslieferung: Kunden sollen frühzeitig und regelmäßig wertvolle Software erhalten, um Feedback zu integrieren und kontinuierlich Mehrwert zu schaffen.

Anforderungsänderungen willkommen heißen: Veränderungen, auch spät im Projekt, sollen genutzt werden, um dem Kunden einen Wettbewerbsvorteil zu verschaffen.

Regelmäßige Lieferung funktionierender Software: Kurze Lieferzyklen fördern schnelles Feedback und ermöglichen es, die Software regelmäßig anzupassen und zu verbessern.

Tägliche Zusammenarbeit von Fachleuten und Entwicklern: Idealerweise sollten Fachleute und Entwickler regelmäßig, auch täglich, zusammenarbeiten, um direktes Feedback und schnelle Anpassungen zu ermöglichen.

Motivierte Individuen: Projekte sollten um motivierte Personen herum aufgebaut werden, die das nötige Umfeld und Vertrauen erhalten, um ihre Aufgaben erfolgreich zu erledigen.

Gespräch von Angesicht zu Angesicht: Die effektivste Kommunikationsmethode ist der direkte persönliche Austausch, um Missverständnisse zu vermeiden und schnelle Entscheidungen zu treffen.

Funktionierende Software als Fortschrittsmaß: Der Fortschritt wird an der Funktionsfähigkeit der Software gemessen, nicht an abstrakten Kennzahlen wie Velocity.

Nachhaltige Entwicklung: Ein gleichmäßiges und nachhaltiges Arbeitstempo ist wichtiger als kurzfristige Schnelligkeit.

Technische Exzellenz und gutes Design: Höchste technische Qualität und gutes Design fördern die Agilität und Anpassungsfähigkeit.

Einfachheit: Die Kunst, möglichst wenig Arbeit zu erledigen, um Verschwendung zu minimieren, ist entscheidend für den Erfolg.

Selbstorganisierte Teams: Die besten Ergebnisse entstehen durch selbstorganisierte Teams, die Verantwortung übernehmen und eigenständig arbeiten.

Regelmäßige Reflexion und Anpassung: Teams sollten regelmäßig reflektieren, wie sie effektiver werden können, und ihr Verhalten entsprechend anpassen.

Thomas betont, dass diese Prinzipien oft in der Praxis zu wenig beachtet werden, obwohl sie essenziell für erfolgreiche agile Projekte sind.

Links

Letzte Folge „NBA05: Ist das Agile Manifest noch relevant?“

Die 12 Agilen Prinzipien

NBA03: Open Space

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/7-nba05-ist-das-agile-manifest-noch-relevant

Zusammenfassung

In Folge 5 von No Bullshit Agile diskutiert Thomas die Relevanz des Agile Manifests heute. Er beleuchtet die vier grundlegenden Werte des Manifests und teilt seine praktischen Erfahrungen dazu:

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge: Die direkte Kommunikation und Zusammenarbeit sind entscheidend für den Erfolg, wichtiger als das Festhalten an Prozessen oder Werkzeugen.

Funktionierende Software ist mehr als umfassende Dokumentation: Die Priorität liegt auf der Bereitstellung funktionierender Software, nicht auf umfangreicher Dokumentation. Dokumentation ist wichtig, aber nicht das Hauptziel.

Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen: Flexibilität im Umgang mit Kundenwünschen und Veränderungen ist essenziell, anstatt starr an vertraglichen Vereinbarungen festzuhalten.

Reagieren auf Veränderungen ist wichtiger als das Befolgen eines Plans: Anpassungsfähigkeit ist entscheidend. Ein ursprünglicher Plan muss flexibel genug sein, um auf Veränderungen reagieren zu können.

Thomas stellt fest, dass das Agile Manifest auch nach über 20 Jahren nach wie vor relevant ist. Es bildet die Basis für agile Prinzipien, wird aber oft durch moderne Tools und Zertifizierungen verdeckt. Er empfiehlt, das Manifest als ständigen Referenzpunkt für agile Entscheidungen zu nutzen und plant, in der nächsten Folge die zwölf agilen Prinzipien näher zu betrachten.

Links

Letzte Folge „NBA05: Scrum: Warum Es Zeit ist, Ein anderes Agiles Vorgehen zu Erwägen“

Das Agile Manifest

Die 12 Prinzipien der agilen Softwareentwicklung

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/6-nba04-scrum-warum-es-zeit-ist-ein-anderes-agiles-vorgehen-zu-erwaegen

Zusammenfassung

In Folge 4 von No Bullshit Agile wirft Thomas einen kritischen Blick auf Scrum und diskutiert, warum es sinnvoll sein könnte, andere agile Methoden in Betracht zu ziehen. Hier sind die Kernaussagen:

Scrum als Management-Tool: Thomas sieht Scrum eher als Werkzeug für das Management, das bei der Planung und Durchführung von Projekten hilft, als ein echtes Entwicklungsframework. Er hebt hervor, dass Scrum stark auf Rollen, Prozesse und Reporting fokussiert ist, was es mehr zu einem Management-Framework macht als zu einem Werkzeug zur Verbesserung der Softwareentwicklung.

Erfahrungen mit Scrum: Nach fast fünf Jahren intensiver Nutzung von Scrum im Team stellt Thomas fest, dass Scrum oft auf Projekte und weniger auf die tatsächliche Softwareentwicklung fokussiert ist. Dies kann in der Praxis dazu führen, dass die tatsächliche Lieferung funktionierender Software in den Hintergrund tritt.

Kritik an der Velocity und Iterationen: Thomas beschreibt, dass die Velocity-Messung und das Commitment auf Iterationen in der Praxis schwierig sein können, besonders bei neuen oder unbekannten Aufgaben. Die Geschwindigkeit, mit der ein Team arbeitet, kann durch Storypoint-Schätzungen und Task-Splitting besser verstanden werden, ist jedoch nicht immer zuverlässig, wenn sich die Rahmenbedingungen ändern.

Vergleich zu Kanban und Extreme Programming: Andere Methoden wie Kanban und Extreme Programming stehen näher an der Realität der Softwareentwicklung. Sie erkennen an, dass die Entwicklung oft unbekanntes Terrain ist und bieten daher flexiblere Ansätze, die besser an die tatsächlichen Bedürfnisse der Softwareentwicklung angepasst sind.

Positives an Scrum: Thomas räumt ein, dass Scrum klare Regeln und Strukturen bietet, was es anfänglich leichter macht, agile Praktiken zu implementieren. Es kann als Einstiegspunkt für Agilität dienen, aber es ist nicht immer die beste Lösung für alle Anforderungen.

Kanban als flexible Alternative: Im Vergleich zu Scrum bietet Kanban mehr Flexibilität, da es sich auf den kontinuierlichen Flow von Entwicklungsanforderungen bis zum Release konzentriert, ohne feste Zyklen oder Iterationen. Dies kann besonders nützlich sein für die Unterstützung von älterer Software und die Priorisierung von Support-Tätigkeiten.

Insgesamt sieht Thomas Scrum als nützliches, aber begrenztes Werkzeug. Er empfiehlt, das Agile Manifest als Grundlage für Agilität beizubehalten und offen für alternative Methoden wie Kanban und Extreme Programming zu bleiben.

Links

Letzte Folge „NBA03: Open Space“

Folge 1 „Das große Ganze“

Agile & Scrum

Why Scrum sucks

Über Feedback freue ich mich immer: [email protected]. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile

Kommentare und Diskussionen gerne hier: https://forum.no-bullshit-agile.de/d/5-nba03-open-space

Zusammenfassung

In Folge 3 von No Bullshit Agile stellt Thomas das Format "Open Space" vor, ein effektives Austauschformat für Teams, das Wissensverbreitung und kontinuierliches Lernen fördert. Hier sind die Kernaussagen:

Was ist Open Space? Open Space ist ein flexibles Format, das sich von traditionellen Konferenzen unterscheidet. Im Gegensatz zu festen Agenden und festgelegten Sprechern ermöglichen Open Space-Events den Teilnehmern, die Themen und Inhalte selbst zu gestalten. Es ist eine Plattform für Wissensaustausch, Diskussionen und Entscheidungsfindung.

Vergleich zu Barcamps: Wie Barcamps sind Open Space-Veranstaltungen dezentral organisiert. Teilnehmer schlagen Themen vor, die dann in offenen Slots bearbeitet werden. Im Gegensatz zu Konferenzen, bei denen die Agenda im Voraus festgelegt wird, können Open Space-Veranstaltungen spontan angepasst werden.

Praktische Umsetzung: Thomas beschreibt, wie Open Space in seiner Firma organisiert wird: Alle zwei Wochen gibt es einen Timeslot mit zwei parallelen Sessions, in denen vier Themen behandelt werden. Teilnehmer pitchten ihre Ideen, und die Themen werden nach Interesse in den verfügbaren Slots verteilt. Die Sessions sind offen und können von jedem besucht oder verlassen werden.

Teilnahme und Flexibilität: Das „Gesetz der zwei Füße“ erlaubt es Teilnehmern, den Raum zu wechseln, wenn sie sich nicht wohlfühlen oder den Eindruck haben, dass sie keinen Beitrag leisten können. Diese Flexibilität wird als normal und nicht unhöflich betrachtet.

Zusätzliche Features: Die Sessions werden aufgezeichnet, um auch denen den Zugang zu ermöglichen, die nicht teilnehmen konnten. Wiederkehrende Themen oder weiterführende Diskussionen sind ebenfalls möglich und werden berücksichtigt.

Thomas empfiehlt, Open Space auszuprobieren, um Wissensaustausch in Teams zu fördern. Das Format ist leicht zu organisieren und erhält positives Feedback für seine Flexibilität und Teilnehmerorientierung.

Links

Letzte Folge „NBA02: Rollen in Kanban? SDM und SRM“

Open Space