David Anderson über Agile Coaches

Scharfe Worte zu “manchen Agilen Coaches/Consultant” von David J. Anderson in seinem Artikel “What Kanban Coaches Do, and don’t Do“:

At its worst Agile is a religion – a belief system with zealots who are beyond logical reasoning or debate. They have blind faith that Agile is better and worse they believe that they have sent to convert the heathen and turn them into true believers.

Ach, was habe ich denn hier entdeckt: “Scrum und Religion” sowie “Cargo Cult & Scrum ..” ;-).

Seine Empfehlungen für Kanban Coaches:

  • Nichts aufzwingen und nicht missionieren sondern beobachten und Hilfestellung anbieten
  • Ist-Situation akzeptieren und nicht verurteilen
  • Erst prüfen, ob Kanban geeignet ist bevor es empfohlen wird
  • Im ersten Schritt schwierige Themen die viel Widerstand auslösen vermeiden
  • Widerstand gegen Veränderung berücksichtigen und nicht mit “Gewalt” überwinden wollen

 

Rosskur für neue Scrum Teams

Schock! … lass nach? Nicht wenn es nach Scott Downey bzw. Jeff Sutherland geht.

In dem Artikel Scrum “Shock Therapy” How To Change Teams FAST beschreibt Scott, wie er Teams schnell auf den richtigen Weg bringt. Seine Rosskur sieht wie folgt aus:

  • Jeder wird in Scrum geschult
  • Sprints sind eine Woche lang
  • Definition of Done wird vorgegeben und resultiert in “produktionsreif”
  • Schätzungen nur in Story Points
  • Physischer Information Radiator / Scrum Board und KEINE PM Software
  • Sprint “Planning” (naja, eigentlich alle “großen Scrum Meetings” zusammen) dauert 4 Stunden, jede Woche
    • Demo
    • Retrospektive
    • Vorstellung Planung / Product Backlog
    • Schätzungen und Verhandlungen
    • Committment auf Sprint Planung

Jupp, passt. Jeder, der eine solche Rosskur einmal erfolgreich mitgemacht hat, versteht welches Potential darin verborgen ist, schnell vorhandene Denkmuster, Widerstände und Verhaltensweisen zu durchbrechen. Hierbei hilft es sehr, ein externer Coach zu sein und nicht der Scrum Master mit dem das Team dann langfristig zusammen arbeitet.

Cheers!

 

Tauchen und Agilität

Seit einiger Zeit tauche ich als Sporttaucher. Nicht besonders professionell aber immer mal wieder. Nicht nur als Schönwettertaucher (Ägypten) sondern auch im Trüben (deutsche Seen, 30 cm Sicht).

Mathis Christian scheint auch zu tauchen und nutzt dies als Einstieg zu seinem Artikel “Schätztauchen”.

Soweit so gut, allerdings stören mich ein paar Details.

Er schreibt:

“In dem Boot auf dem Roten Meer in Ägypten, kurz vor meinem allerersten Tauchgang [..]”

Es ist doch sehr unüblich den ersten Tauchgang von einem Boot zu unternehmen. Selbst wenn man bereits etwas Taucherfahrung hat, so sollte doch ein Checkdive in flachem Wasser stattfinden. Naja, manche mögen das Risiko …

“habe ich nicht mit meinem Tauchlehrer diskutiert, ob es die richtige Methode ist, auf die Innenseite der Taucherbrille zu spucken und meinen Speichel zu verteilen. Damit sie nicht beschlägt, während ich mich in 25 m Tiefe befinde und ich dann blind herumschwimme. Mein Tauchlehrer hat lediglich die kurze Anleitung gegeben, ist abgetaucht und … ich habs einfach gemacht.”

OK, übertragen wird das auf unser Geschäft: In einem Projekt in dem potentiell Leben auf dem Spiel stehen (25m unter Wasser!) wird eine grundlegende Entwicklungspraktik (Spucke in Brille!) nicht verstanden und auch nicht hinterfragt. Man vertraut blind dem Senior-Supervisor-Manager-Mentor-Specialist Zwinkerndes Smiley. Aha.

Wäre es nicht sinnvoll gewesen die Praktik in einem kleinen Projekt (-> Schwimmbecken) einmal auszuprobieren und selbst Erfahrungen damit zu sammeln?

Und warum kennt man die grundlegende Entwicklungspraktik (Spucke in Brille!!!!) nicht? Vielleicht ist man noch nicht erfahren genug für die große Aufgabe (25m unter Wasser!!!)? Nicht ohne Grund bleiben Tauchtiefen unterhalb von 18/20m Neulingen, die lediglich den Einstiegstauchkurs hinter sich haben, verschlossen.

War das überhaupt ein Tauchlehrer – ähm ich meine “Senior-Supervisor-Manager-Mentor-Specialist?

Der Rest vom Artikel ist gut – Magic Estimation, Unsicherheit zulassen, Erkenntnisse gewinnen, Diskussion der Themen im Vorfeld.

Aber bitte, bitte … keine Harakiri-Tauchstory als Einstieg Zwinkerndes Smiley

Achja: Es gibt natürlich auch andere Mittelchen als Spucke. Aber das ist ja schon wieder zu viel Tooling Zwinkerndes Smiley

 

So, genug gemeckert!

AgileEE2011: Videos der Keynotes online

Die wichtigsten Vorträge der Agile Eastern Europe 2011 werden jetzt nach und nach ins Netz gestellt. Die Videos sind alle sehr gelungen und die Präsentationen sind ebenfalls abrufbar.

Neben den Keynotes von Alistair Cockburn (Effective Software Development In The 21st Century: The New Face Of Software Engineering), J. B. Rainsberger (The Extreme Decade: Progress, Pain, Paradox”) und Jurgen Appelo (“How to Change the World”) jetzt auch die Keynote von

Elisabeth Hendrickson (Blog).

Ihre Session mit dem Titel "Agile Testing, Uncertainty, Risk, and Why It All Works" ist deshalb so interessant, da sehr eindrücklich der Wert von kurzer Zyklen und echten Auslieferungen erläutert wird.

Die Argumentation ist in etwa wie folgt:

  • No roll out to real customers –> Speculation build up –> big tank of toxic stuff
  • Speculation we are basing our decisions on
  • Fact is: Empirical Evidence trumps Speculation. Every. Single. Time.

 

Keynote by Elisabeth Hendrickson from AGILEEE on Vimeo.

Es gibt noch viele weitere Anregungen in dem Talk, weshalb ich empfehle das Video und die Präsentation in Ruhe anzusehen.

Technische User Stories

Das letzte Treffen der SCRUM User Group Karlsruhe hatten das Product Backlog als Thema.

Es dauerte nicht lange, bis auch darüber diskutiert wurde, ob Dinge, die keine User Stories sind, in ein Product Backlog gehören. Dies ist nicht ungewöhnlich – an der Frage, ob es technische Stories in einem Scrum Product Backlog geben darf scheiden sich bekanntlich die Geister.

Ich schaue mir das Hin- und Her jetzt mehr als 6 Jahre an und ehrlich gesagt – mich langweilt es. Die einen verkaufen den Ansatz “nur Kundenanforderungen im Backlog”, die anderen beharren darauf, dass auch technische Themen explizit im Backlog zu platzieren sind.

Die einen sagen “technische Themen müssen autmatisch miterledigt werden”, die anderen weisen darauf hin, dass dies bei vielen Themen nicht möglich ist.

Continue reading

Erinnerung: Treffen SCRUM User Group Karlsruhe am 5.10.

Eine kurze Erinnerung an das Treffen der SCRUM User Group Karlsruhe am 5.10.

Anmelden via EVENT in XING.

Beginn: 05.10.2011, 20:00
Ort: Restaurant Großer Kurfürst, Sophienstrasse 80, 76135 Karlsruhe

Thema dieses Mal: WorldCafé zum Thema “Unser Product Backlog”.
“Wir erleben täglich Fragen nach Backlogtools, Granularität, Ausrichtung auf PO oder eher auf Teambedürfnisse,… ”

Wichtig: Wer etwas essen möchte, sollte spätestens 19:30 Uhr im Restaurant sein, da für das WorldCafe die Tische gebraucht werden.

 

AGILE since 2002

Wenn man mich fragt, seit wann ich mit agilen Methoden Erfahrungen sammle, ist meine Antwort meist “so ab 2004”.

Nun, dies ist nicht ganz richtig.

2003 – ERSTE SIG IN KARLSRUHE ZUM THEMA “AGILE”

Bereits ab 2002 waren Themen rund um Agilität (und hier besonders XP) etwas, was meine Interesse wecken konnte. imageMitte 2003 habe ich schließlich mit ein paar weiteren “Early Adopters” (u.a. Ilja Preuss, Malte Finsterwalder, Johanness Link, …) eine Special Interest Group in Karlsruhe gegründet: “Methoden der agilen Softwareentwicklung” (KAgile).

Diese Karlsruher Gruppe war eine Zeit lang recht aktiv, es gab einige sehr interessante Treffen zu den unterschiedlichsten Themen rund um “Agile”. Ende 2005 ging aus verschiedenen Gründen die Aktivität zurück und mittlerweile wurde die Gruppe de facto durch die viel später gegründete “SCRUM User Group Karlsruhe” abgelöst.

Continue reading