Ü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

Ü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/4-nba02-rollen-in-kanban-sdm-und-srm

Zusammenfassung

In Folge 2 von No Bullshit Agile widmet sich Thomas den spezifischen Rollen innerhalb von Kanban, insbesondere dem Service Delivery Manager (SDM) und dem Service Request Manager (SRM). Hier sind die Kernaussagen:

Kanban-Rollen: Im Gegensatz zu Scrum, das klare Rollen wie Scrum Master und Product Owner definiert, gibt es im Kanban Guide keine festgelegten Rollen. Stattdessen basiert Kanban auf selbstorganisierten Teams, doch in der Praxis haben sich zwei wichtige Rollen herausgebildet: der SDM und der SRM.

Service Delivery Manager (SDM): Der SDM, auch Flowmaster genannt, hat die Aufgabe, den Flow im Delivery zu managen. Ähnlich wie der Scrum Master unterstützt der SDM das Team dabei, effizient zu arbeiten, indem er den kontinuierlichen Verbesserungsprozess fördert, das Kanban-Board überwacht, blockierte Aufgaben identifiziert und Kanban-Meetings organisiert.

Service Request Manager (SRM): Der SRM kümmert sich um die Vorbereitung der Arbeit, indem er Kundenanforderungen sammelt, priorisiert und bereitstellt, sodass diese für das Team zur Entwicklung bereit sind. Er ist kundenorientiert und fungiert als Schnittstelle zwischen den Anforderungen und der Umsetzung. Diese Rolle ist in der Praxis weniger verbreitet, wird jedoch oft von Product Managern oder Account Managern übernommen.

Praktische Relevanz: Beide Rollen unterstützen das Team in verschiedenen Phasen und tragen zur effizienten Bearbeitung und Übergabe von Aufgaben bei. Während der SDM den Fokus auf die interne Effizienz legt, ist der SRM auf die Kundenseite und die Vorbereitung der Arbeit spezialisiert.

Thomas empfiehlt, diese Rollen zu berücksichtigen, insbesondere wenn das Team noch nicht vollständig selbstorganisiert ist.

Links

Letzte Folge „Das große Ganze“

Kanban Guide

Scrum Guide

Rollen in Kanban - SDM / SRM

Über Feedback freue ich mich immer: [email protected]

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/3-nba01-das-grosse-ganze

Zusammenfassung

In der ersten Folge von No Bullshit Agile bietet Thomas einen Überblick über die Themen, die im Podcast behandelt werden. Er stellt die fünf großen Kategorien vor: Menschen, Teams, Kunden, Projekte und Agilität.

Menschen: Die menschliche Komponente ist zentral. Themen wie Rollenverteilung, lebenslanges Lernen, Kommunikation und Führung stehen im Fokus.

Agilität: Hier werden die Grundprinzipien, das Agile Manifest und verschiedene agile Methoden wie Kanban und Extreme Programming besprochen.

Teams: Es geht um selbstorganisierte Teams, Kapazitätsplanung, Continuous Delivery und den Umgang mit Feedback.

Kunden: Die Zusammenarbeit mit Kunden, das Management von Angeboten und das Einbinden klassischer Budgetplanungen sind wichtige Themen.

Projekte: Methoden zur Planung und Gestaltung von Projekten mit Kunden, inklusive User Stories, User Story Mapping und Refinement.

Der Podcast legt großen Wert auf Praxisnähe und will agile Prinzipien auf verständliche Weise vermitteln.