No Bullshit Agile

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/38-nba22-wer-treibt-agilitaet-im-unternehmen-voran

Zusammenfassung

In dieser Episode von „No Bullshit Agile“ (Folge 22) geht es darum, wie Agilität in Unternehmen effektiv vorangebracht werden kann. Thomas diskutiert, wer diesen Prozess vorantreiben sollte und welche Faktoren dabei entscheidend sind. Hier sind die Kernpunkte zusammengefasst:

Agilität als Mindset: Agilität ist mehr als nur die Anwendung von Methoden wie Scrum oder Kanban. Es ist ein Mindset, das durch das Verständnis und die Anwendung der Prinzipien des agilen Manifests getragen wird.

Top-Down und Bottom-Up: Beide Ansätze sind wichtig für die Einführung von Agilität. Unterstützung vom Management ist entscheidend, aber auch eine engagierte Gruppe von Mitarbeitern aus verschiedenen Bereichen sollte das Thema vorantreiben.

Bildung eines engagierten Teams: Ein kleines, heterogenes Team, das für Agilität brennt, sollte gebildet werden. Dieses Team muss die Prinzipien von Agilität klar verstehen und regelmäßig an der Weiterentwicklung arbeiten.

Iterative Verbesserung: Setzt erreichbare Ziele und plant in Iterationen. Feedback sollte kontinuierlich gesammelt und zur Verbesserung des Prozesses genutzt werden.

Transparenz und Kommunikation: Offenheit ist entscheidend. Der Plan, die Ziele und die Fortschritte müssen transparent kommuniziert werden, um Vertrauen und Unterstützung im gesamten Unternehmen zu fördern.

Unterstützung und Hilfe: Das Team sollte als Multiplikator fungieren, Schulungen anbieten und als Ansprechpartner für Fragen zur Verfügung stehen. Es ist wichtig, allen Mitarbeitenden die Möglichkeit zur Mitgestaltung und Unterstützung anzubieten.

Zusammengefasst betont Thomas die Notwendigkeit, Agilität als ganzheitlichen Ansatz zu verstehen und sowohl das Management als auch die Mitarbeitenden aktiv in den Prozess einzubeziehen.

Links

Letzte Folge NBA21: Fehlerkultur

NBA05: Das Agile Manifest

NBA06: Die 12 Agilen Prinzipien

NBA15: Agilität ist ein Mindset

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/37-nba21-fehlerkultur

Zusammenfassung

In Folge 21 von „No Bullshit Agile“ beleuchtet Thomas das Thema Fehlerkultur und deren Bedeutung für agile Unternehmen. Hier sind die zentralen Erkenntnisse zusammengefasst:

Fehler als Chance: Fehler sollten nicht als Schuldzuweisungen betrachtet werden, sondern als Gelegenheit zum Lernen und zur Verbesserung. Ein offener Umgang mit Fehlern fördert Wachstum und Innovation.

Vermeidung von Blaming: Anstatt Fehler zuzuweisen, sollte die Ursache des Problems analysiert werden, um herauszufinden, wie und warum der Fehler entstanden ist. Dies fördert eine konstruktive Fehlerkultur.

Fehlerkultur vorleben: Führungskräfte müssen eine positive Fehlerkultur vorleben, um Offenheit und Bereitschaft für Experimente im gesamten Team zu fördern. Fehlende Unterstützung auf Führungsebene kann den Fortschritt behindern.

Institutionalisierung des Lernens: Fehleranalyse und Learning-Identifizierung sind entscheidend. Das System sollte so gestaltet sein, dass aus Fehlern gelernt wird, sei es durch verbesserte Prozesse, bessere Dokumentation oder andere Maßnahmen.

Vertrauen und Offenheit: Eine gute Fehlerkultur ist eng mit Vertrauen verbunden. Vertrauen muss aufgebaut werden, damit Mitarbeiter offen über Fehler sprechen und sich gegenseitig unterstützen können.

Zusammengefasst, betont Thomas, dass der richtige Umgang mit Fehlern entscheidend für die Weiterentwicklung eines agilen Teams ist. Fehler sollten als Chance zur Verbesserung betrachtet werden, und eine offene, unterstützende Kultur ist unerlässlich, um dies zu erreichen.

Links

Letzte Folge NBA20: Product Owner kann nur der Kunde sein

Diskussionsbeitrag zu der Folge:

NBA12: Vertrauen geben

Jocko Willink „Good“

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/36-nba20-product-owner-kann-nur-der-kunde-sein

Zusammenfassung

In Folge 20 von „No Bullshit Agile“ diskutiert Thomas die Rolle des Product Owners im Kontext von Kundenprojekten und Agenturen. Hier sind die zentralen Punkte zusammengefasst:

Product Owner als Kunde: Thomas argumentiert, dass der wahre Product Owner in Kundenprojekten der Kunde selbst ist. Der PO in der Agentur fungiert eher als Vermittler und Sortierer von Anforderungen, aber die tiefere Verantwortung und Vision für das Produkt liegt beim Kunden.

Herausforderungen im Scrum-Ansatz: Der Scrum Guide beschreibt den Product Owner als verantwortlich für die Maximierung des Produktwerts und die Priorisierung der Backlog-Elemente. Thomas kritisiert, dass diese Aufgaben in einer Agenturumgebung schwierig zu erfüllen sind, da der PO in der Agentur nicht die gleiche Tiefe an Marktkenntnis und Verantwortung wie der Kunde hat.

Unzureichende Autorität des Agentur-POs: Der Agentur-PO hat oft nicht die notwendige Autorität oder die umfassende Sicht auf das Produkt, die erforderlich ist, um klare Ziele zu setzen und Prioritäten zu bestimmen. Diese Rolle ist stark auf Kommunikation und Abstimmung mit dem Kunden angewiesen, was die Effektivität beeinträchtigen kann.

Probleme mit der „Hero-Rolle“: Der Scrum Guide verlangt, dass der PO als Einzelperson Entscheidungen trifft und nicht als Komitee handelt. Thomas kritisiert diesen Ansatz als unvereinbar mit agilem Arbeiten, da er den PO in eine isolierte „Hero-Rolle“ drängt, anstatt kollaborative Entscheidungsfindung zu fördern.

Dualität im Agenturmodell: Thomas sieht das Modell problematisch, wenn der PO beim Kunden sitzt und das Entwicklungsteam von einer Agentur kommt. Diese Dualität kann zu Konflikten und Missverständnissen führen, da die Agentur und der Kunde unterschiedliche Interessen und Perspektiven haben können.

Zusammengefasst stellt Thomas in Frage, ob das traditionelle Verständnis der Product Owner-Rolle in Agenturumgebungen wirklich praktikabel ist, und schlägt vor, dass der Kunde selbst die zentrale Rolle des Product Owners übernehmen sollte.

Links

Letzte Folge NBA19: Entscheidungen im Team treffen

Artikel „Die Rolle des Product Owners in agilen Projekten: Eine kritische Analyse für kundenorientierte Teams“

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/35-nba19-entscheidungen-im-team-treffen

Zusammenfassung

In der 19. Folge von No Bullshit Agile diskutiert Thomas, wie herausfordernd es sein kann, Entscheidungen innerhalb eines Teams zu treffen. Oft kommt es zu Schwierigkeiten, weil Diskussionen nicht immer offen sind, dominante Persönlichkeiten sich durchsetzen oder Scheindiskussionen geführt werden. Thomas stellt verschiedene Gründe vor, warum Entscheidungsprozesse stocken können, wie Unsicherheiten oder versteckte Agenden.

Er empfiehlt, Probleme offen anzusprechen und bietet konkrete Methoden zur Verbesserung des Entscheidungsfindungsprozesses an:

Konsens vs. Konsent: Während Konsens die Zustimmung aller Teammitglieder erfordert, prüft Konsent lediglich, ob jemand vehement gegen die Entscheidung ist.

Six Hats: Diese Methode fordert alle Teammitglieder auf, verschiedene Perspektiven (analytisch, emotional, kritisch, optimistisch, kreativ, und auf Meta-Ebene) einzunehmen, um umfassendere Einblicke zu erhalten.

Experimentieren: Entscheidungen können als Experimente betrachtet werden, um nach einer bestimmten Zeit zu bewerten, ob der gewählte Ansatz erfolgreich war.

Thomas betont, dass die Kenntnis der Teamdynamik und der Einsatz geeigneter Methoden entscheidend sind, um Entscheidungsfindungen zu verbessern. Er lädt Hörer ein, ihre eigenen Erfahrungen und Feedback zu teilen.

Links

Letzte Folge NBA18: Den Kunden mitnehmen

NBA11: Wertvoll: One on One mit Teammitgliedern

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/34-nba18-den-kunden-mitnehmen

Zusammenfassung

In der 18. Folge von No Bullshit Agile beleuchtet Thomas, wie wichtig es ist, den Kunden während eines Projekts umfassend aufzuklären. Er betont, dass Kunden oft nur oberflächlich mit agilen Methoden vertraut sind und dass es unsere Aufgabe ist, ihnen die Prinzipien und Vorteile der Agilität klar und verständlich zu vermitteln.

Thomas teilt eine persönliche Erfahrung, in der trotz ausführlicher Erklärungen und Diskussionen der Kunde immer noch nach dem Enddatum des Projekts fragte, was auf eine unzureichende Aufklärung hinweist. Dies verdeutlicht, dass kontinuierliche Kommunikation und Aufklärung unerlässlich sind, um sicherzustellen, dass der Kunde die agile Vorgehensweise wirklich versteht und schätzt.

Er hebt hervor, dass Kunden unterschiedlich weit in ihrer Agilität sind, und dass es wichtig ist, deren Verständnis regelmäßig zu überprüfen und anzupassen. Effektive Aufklärung geht über das Fachliche hinaus und sollte auch potenzielle Werte und Nutzen der agilen Methoden verdeutlichen.

Thomas lädt Hörer ein, ihre eigenen Erfahrungen und Tipps zum Thema Kundenaufklärung zu teilen und bietet verschiedene Kontaktmöglichkeiten für Feedback an.

Links

Letzte Folge NBA17: Wer agil ist muss nicht planen?

NBA13: Agile Projektplanung

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/33-nba17-wer-agil-ist-muss-nicht-planen

Zusammenfassung

In Folge 17 von No Bullshit Agile diskutiert Thomas die häufige Missverständlichkeit, dass Agilität keine Planung erfordere. Er stellt klar, dass Agilität im Gegenteil kontinuierliches und flexibles Planen bedeutet. Während traditionelle Projekte oft langfristige Pläne ohne Anpassungen nutzen, verfolgt Agilität einen iterativen Ansatz, der ständiges Überprüfen und Anpassen des Plans beinhaltet.

Thomas erklärt, dass am Anfang eines Projekts eine Vision und Ziele definiert werden müssen, aber das eigentliche Planen in kleinen Schritten und durch regelmäßiges Feedback erfolgt. Der mythos, dass agile Projekte keine Planung erfordern, ist ein Missverständnis. Vielmehr ist der Planungsprozess selbst wertvoll, wie das Zitat von Eisenhower treffend beschreibt: „Plans are worthless, but planning is everything.“

Er betont, dass agile Planung hilft, unnötigen Waste zu vermeiden und echten Mehrwert für den Kunden zu schaffen. Die Kunst liegt darin, den Plan kontinuierlich anzupassen und zu verfeinern, um flexibel auf Veränderungen reagieren zu können.

Links

Letzte Folge NBA16: Kleine Stories machen Sinn

NBA13: Agile Projektplanung

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/32-nba16-kleine-stories-machen-sinn

Zusammenfassung

In Folge 16 von No Bullshit Agile erklärt Thomas, warum es sinnvoll ist, Stories klein zu halten. Kleine Stories bieten viele Vorteile, darunter einfacheres Handling, besseren Fokus, höhere Transparenz, Flexibilität, erhöhten Durchsatz und effektiveres Risikomanagement.

Thomas widerlegt die Argumente für große Stories, wie einfachere Handhabung oder Erhalt des Kontexts, und betont, dass der eigentliche Wert in der schnellen Lieferung und dem regelmäßigen Feedback liegt. Kleine Stories ermöglichen es Teams, schneller Wert zu schaffen und Anpassungen vorzunehmen. Er empfiehlt, Stories so klein wie möglich zu halten, um die Agilität zu maximieren und den gesamten Prozess zu optimieren.

Links

Letzte Folge NBA15: Warum so viele scheitern: Agilität ist ein Mindset!

Umfrage "Zufriedenheit mit Agilität" auf Mastodon

Umfrage "Kleine Stories" auf Mastodon

Practical Guide to User Story Splitting

NBA13: Agile Projektplanung

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/31-nba15-warum-so-viele-scheitern-agilitaet-ist-ein-mindset

Zusammenfassung

In Folge 15 von No Bullshit Agile geht Thomas der Frage nach, warum viele Agile-Implementierungen scheitern und erklärt, dass Agilität vor allem eine Denkweise, ein Mindset ist. Viele Organisationen missverstehen Agilität und verwechseln sie mit der Nutzung von Frameworks wie Scrum oder Kanban, ohne das zugrunde liegende Prinzip zu verstehen.

Thomas hebt hervor, dass Agilität nicht einfach bedeutet, Methoden oder Tools zu verwenden, sondern eine Haltung erfordert, die Flexibilität und kontinuierliches Lernen betont. Die Essenz von Agilität liegt darin, sich an sich ändernde Anforderungen und neue Erkenntnisse anzupassen, anstatt starr an vorab definierten Plänen festzuhalten.

Er erklärt, dass Agilität besonders dann wichtig ist, wenn Projekte Neuland betreten, unklare Anforderungen bestehen und kontinuierliches Feedback notwendig ist. In solchen Fällen ist Agilität der effektivste Ansatz, um Verschwendung zu vermeiden und echten Wert zu schaffen.

Abschließend betont Thomas, dass die Implementierung von Agilität mehr ist als das Befolgen von Regeln; es erfordert das Verinnerlichen der Agilitätsprinzipien und des Agile Manifests. Um wirklich agil zu sein, muss man die Prinzipien verstehen und umsetzen, nicht nur die Praktiken übernehmen.

Links

Letzte Folge NBA14: Peer Feedback

NBA05: Ist das Agile Manifest noch relevant?

NBA06: Die 12 Agilen Prinzipien

Umfrage

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/30-nba14-peer-feedback

Zusammenfassung

In Folge 14 von No Bullshit Agile beleuchtet Thomas das Thema Peer Feedback als Alternative zum traditionellen Jahresendgespräch. Er erklärt, dass das klassische Modell oft zu oberflächlichem Feedback führt und sich hauptsächlich auf Gehaltsverhandlungen konzentriert. Peer Feedback hingegen bietet eine regelmäßige, detailliertere Rückmeldung und fördert kontinuierliches Lernen.

Das Peer Feedback-Modell sieht vor, dass jeder alle sechs Monate Feedback von drei ausgewählten Peers erhält. Diese Peers können Kollegen, Führungskräfte oder auch Personen aus anderen Teams sein. Die Feedbackgeber bereiten sich vor, indem sie das vergangene Halbjahr des Feedbacknehmers betrachten und sich zu drei Leitfragen Notizen machen:

Das Feedbackgespräch erfolgt in einem offenen und sicheren Raum, ohne Notizen oder Berichte an die Geschäftsführung. Der Fokus liegt auf ehrlichem Austausch und der persönlichen Weiterentwicklung, nicht auf Rechtfertigungen.

Thomas betont, dass regelmäßiges Peer Feedback oft wertvoller ist als sporadisches Feedback von Führungskräften, da es tiefere Einblicke und persönliches Wachstum ermöglicht. Er lädt die Zuhörer ein, ihre Erfahrungen mit Peer Feedback zu teilen und darüber nachzudenken, ob es eine geeignete Alternative für sie darstellen könnte.

Links

Letzte Folge „NBA13: Agile Projektplanung“

One on One

Die drei Leitfragen

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

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/29-nba13-agile-projektplanung

Zusammenfassung

In Folge 13 von No Bullshit Agile geht Thomas der Frage nach, wie agile Projektplanung funktioniert und wie man mit der Frage „Wann ist das Projekt fertig?“ umgeht. Im Gegensatz zum traditionellen Wasserfall-Modell, das detaillierte Pläne und Zeitvorgaben erstellt, verfolgt die agile Methode einen flexibleren Ansatz.

Thomas erklärt, dass in der agilen Welt die Planung kontinuierlich und in Phasen erfolgt. Um den Umfang und den Abschluss eines Projekts zu definieren, empfiehlt er zwei Methoden:

User Story Mapping: Diese Methode hilft dabei, die Anforderungen und Benutzererfahrungen zu visualisieren. Dabei werden große User Tests in kleinere Sub-Tasks zerlegt und nach Priorität geordnet, um eine klare Vorstellung von den notwendigen Features zu bekommen.

Dimensional Planning: Hierbei geht es darum, die Sub-Tasks aus dem User Story Mapping sinnvollen releasebaren Versionen zuzuordnen.

Diese Methoden unterstützen dabei, das Projekt in handhabbare Teile zu gliedern und kontinuierlich an Verbesserungen zu arbeiten, anstatt sich auf ein einmaliges Enddatum festzulegen. Thomas hebt hervor, dass agile Planung nicht bedeutet, auf Planung zu verzichten, sondern diese iterativ und flexibel zu gestalten.

Links

Letzte Folge „NBA12: Vertrauen geben“

Agil-O-Mat

Artikel „Agile Projektplanung“

Spielkarten „Das Agile Manifest“