Folge 29: Teamgröße

Der Scrum Guide schlägt als optimale Entwicklungs-Teamgröße zwischen 3 und 9 Entwicklern vor. Unsere eigene Erfahrung zeigt aber teilweise, dass ein Team aus 9 Personen viel zu groß sein kann. Wir klären, was Gründe hierfür sind, warum ein Team aus 9 Entwicklern trotzdem die richtige Größe haben kann und was es mit dem 2-Pizza-Team auf sich hat.

Links

Picks

Folge 26: Verteilte Teams

Viele Teams arbeiten heutzutage verteilt, oft sogar über Landesgrenzen hinweg. Wir plaudern ein bisschen aus dem Nähkästchen über unsere Erfahrungen, Stolperfallen sowie Tipps für verteilt arbeitende Teams.

Links

Picks

Folge 24: Der Fall ROBASO (mit Christian Dähn)

Der Fall ROBASO hat für viel Kopfschütteln gesorgt: Eine Behörde führt ein vermeintlich agiles Projekt durch und stellt nach 60 Millionen Euro und 4 Jahren „Labor“-Phase fest, dass die Software unbenutzbar ist. Sebastian analysiert zusammen mit Christian Dähn von it-agile die Lage: Christian erzählt ein wenig von seiner Erfahrung mit Behördenprojekten. Zusammen betreiben wir eine höchst fundierte und garantiert verlässliche Ferndiagnose, diskutieren ob und wo Scrum hätte helfen können und welche Dinge vielleicht doch nicht ganz so agil waren, obwohl ROBASO gern als agiles Projekt präsentiert hat.

Links

Folge 21: Kann der Product Owner ein Team sein?

Nicht selten tritt es auf, dass der Product Owner keine einzelne Person ist, sondern eine Gruppe von Personen. Das ist nicht immer sinnvoll, aber auch nicht immer schlecht, es hängt aber auch maßgeblich davon ab, wer Product Owner ist oder wie konsensfähig das Product Owner Team ist. Wir überlegen außerdem, wer idealerweise überhaupt Product Owner wird und ob Consultants geeigneter für die Rolle sind.

Links

Picks:

Folge 16: Produktentwicklung (feat. Tim Hartwig)

Tim hat uns vor ein paar Wochen mit einer ausführlichen Email mit vielen Fragen zum Thema Produktentwicklung und MVP angeschrieben. In der letzten Folge für dieses Jahr unterhalten wir uns mit ihm zusammen über das Thema und klären, wie man die Produktentwicklung gut visualisieren und verwalten kann. Außerdem werfen wir einen Blick auf das Minimum Viable Product (MVP) und ein paar seiner Eigenschaften und geben außerdem Hilfestellung dazu, wie man Scope Creep entgegenwirken kann.

Links

Picks

Folge 14: Retrospektiven (feat. Marc Löffler)

Auf den XP Days 2016 haben wir uns Marc Löffler, Autor des Buchs „Retrospektiven in der Praxis“(Affiliate Link) geschnappt, um zusammen mit ihm über Retrospektiven-Anti-Patterns, Inspect & Ignore sowie Popcorn zu reden.

Tools für Remote-Retrospektiven

Links

marc-loeffler

Folge 11: Was macht einen agilen Coach aus? (feat. Armin Schubert)

Wir versuchen uns mit unserem Gast Armin Schubert von der Firma Emendare zu definieren, was eigentlich ein Agiler Coach ist. Im Laufe des Gesprächs reden wir darüber, welche Aufgaben ein Agile Coach hat, was ihn vom Scrum Master unterscheidet und wie man überhaupt Agile Coach wird.

Links

Folge 10: Das Sprint Review

Auf Wunsch von Patrick unterhalten wir uns heute über das Sprint Review. Wir klären die Definition, tauschen uns darüber aus, was bei uns gut und was auch nicht so gut funktioniert hat und ob PowerPoint Folien in Reviews eigentlich zugelassen sind oder nicht. Recht ausführlich geht es außerdem darum, wie man sein Sprint Review konstruktiv und effektiv gestalten kann.

Links

Picks

Folge 9: Der Weg zur agilen Organisation (feat. Johann-Peter Hartmann & Daniel Hallmann)

Wir waren diese Woche auf der IPC unterwegs und haben uns Johann-Peter Hartmann und Daniel Hallmann geschnappt, um mit ihnen über Schmerzen und Erfolge beim Weg zur agilen Organisation zu reden. Die beiden erzählen, wie bei Mayflower Entscheidungen getroffen werden, wie bei ihnen Communities of Practice entstehen, welche Erfahrungen sie mit Agil und Führung gemacht haben und warum Mayflower 1x im Jahr ein firmeninternes Barcamp macht.

Links

Picks

Folge 7: Definition of Done

Wir tauschen heute Anekdoten über die „Definition of Done“ aus, in denen es darum geht, wer die DoD beeinflussen kann und darf, wie wir sicherstellen, dass die DoD auch verwendet wird und wie man die DoD kontinuierlich weiterentwickeln kann. Zuletzt erörtern wir noch die Sinnhaftigkeit einer „Release Definition of Done“.

Pick der Woche