I will give a short version of my presentation about "Definition of READY". For more information see the list of lightening talks.

See you in Kiev @ Agile Easter Europe 2011!

Der Grund für die Probleme ist ein halbherzig durchgeführter Umzug auf einen anderen Web-Account. Der Umzug wird erst in ein paar Tagen beendet sein und deshalb kann es nochmals zu kleineren Problemen kommen.

Ich bitte die Unannehmlichkeiten zu entschuldigen!

Auf dem nächsten Agile Breakfast werde ich einen Vortrag zum Thema “Definition of Ready – wann kann’s endlich losgehen?” halten. Den meisten ist die “Definition of Done”, kurz “DoD” bekannt, während die “Definition of Ready” (“DoR”) noch relativ wenig diskutiert wird. Dies hat verschiedene Gründe, je nach organisatorischem Umfeld birgt die DoR auch einiges an Konfliktpotential.

In meinem Vortrag werde ich die Motivation für die DoR erläutern und auf das existierende Spannungsfeld (Vorteile, Probleme) eingehen.

Das nächste Agile Breakfast in Konstanz findet am 5. Juli im Wasserturm Stromeyersdorf/Konstanz statt. Organisiert durch die Scrum User Group Lake Constance (SUGLC). Gesponsert von der Firma Sybit.

Es gibt einen Flyer – den könnt ihr bei euch im Unternehmen aushängen.

Anmeldung

Bitte vergesst nicht euch rechtzeitig anzumelden. Die Teilnahme ist kostenlos.

Glücklicherweise schreiben andere über mich, so hat mich Robert Wiechmann vor ein paar Tagen interviewt und jetzt das Interview auf seinem sehr lesenswerten Blog “Projekt-Log.de” veröffentlich:

Viel Spaß beim Lesen!

Auf Bitten meiner Schwester gibt es hier aber doch etwas Werbung für eine Sondersendung im Bayrischen Rundfunk (20.3., 14:35Uhr):

Lieber Katzenfreund,

es gibt wieder spannende Neuigkeiten:

Letzten Samstag wurde ich von einem Kamerateam des Bayrischen Rundfunkes bei meiner Arbeit begleitet. Gemeinsam waren wir zu Gast bei einer Klientin, die einen jungen, übererregten “Wildfang” (das ist sehr freundlich formuliert – er beisst in die Hände und die zweite Katze) bei sich zu Hause hat. Natürlich war es beim Dreh nicht ganz einfach Ruhe in die Situation zu bringen. Schließlich waren alle – Menschen und Katzen – etwas aufgeregt. Ich denke aber, dass Sie am Ende doch einen ersten und schönen Eindruck über meine Arbeitsweise erhalten werden und wieder etwas mehr über die faszinierende Katzenwelt erfahren.
Es lohnt sich also den Beitrag in der Katzensondersendung bei “Zeit für Tiere” anzuschauen (es gibt also noch eine Menge mehr spannende Katzenbeiträge). Auch gerade weil es noch so wenige Berichte über Katzen im Fernsehen gibt und die Sender nur über die Zuschauerzahlen merken, was gerne gesehen wird. Und ich persönlich will mehr über Katzen sehen und vor allem mehr über sie erfahren. Es wird Zeit, dass es neben dem “Hundeprofi” auch bald die “Katzenexpertin” gibt – das ist ein Traum von mir – bitte unterstützen Sie mich dabei, diesen Traum wahr werden zu lassen um mehr Leuten zugänglich zu machen, wie faszinierend unser kleines Raubtier ist.
Daher erzählen Sie möglichst vielen Katzenfreunden von dieser Sendung:

Samstag 20.03.2010 (Katzensondersendung)
BR, “Zeit für Tiere” 14:35 Uhr

Ganz liebe Grüße,
Ihre
Katja Rüssel

TheraFelis – Katzenverhaltensberatung
Ehrwalderstr. 88, 81377 München

Tel.: 089 / 122 09 418, Mobil: 0179 – 5 55 61 07
katja.ruessel@therafelis.de
http://www.thera-felis.de

Trotz anfänglicher Zweifel (“wassn das für ne komische Idee”) halte ich die Arbeit meiner Schwester für sehr sinnvoll und vor allem professionell. Es ist schon erstaunlich, wie viel sie in eine breite Weiterbildung investiert, um sich stetig zu verbessern. Mittlerweile hat sie sich einen gewissen Ruf erarbeitet – und nach einem ersten Fernsehauftritt in VOX gibt es nun das zweite Mal die Gelegenheit die Arbeit einer “Katzenpsychologin” im Fernsehen zu verfolgen.

Für mich ist hierbei immer interessant, wie in vielen Beratungsfällen schon eine kleine Veränderung im Verhalten der Besitzer oder in der Umgebung zu erstaunlichen Ergebnissen führen kann. Wer mehr erfahren möchte, der sollte sich unbedingt die Sendung ansehen.

Team Management = Katzen hüten?

Dies ist kann auch als die Verbindung in die IT-Welt angesehen werden. So gibt es ein Buch “Herding Cats: A Primer for Programmers Who Lead Programmers ”, in dem das Management von Entwicklerteams mit dem hüten von Katzen verglichen wird. Sicherlich nicht der schlechteste Vergleich!

Update: Details zur Sendung können via BR-ONLINE abgerufen werden. Für ein paar Tage ist dort auch eine Aufzeichnung der Sendung hinterlegt.

Hier ein paar Impressionen:

Halifax Waterfront

Halifax Zitadelle

Leuchtturm an der Lighthouse Route

Impression aus dem Kejimkujik Nationalpark

Ich kann jedem empfehlen, einmal 2-3 Wochen Urlaub in Nova Scotia zu verbringen. Vieles ist mit dem Auto zu erreichen, sobald man etwas zu Fuß läuft ist man meist alleine (in der Nebensaison).

Gerade in konservativen Unternehmen, die auf solide Softwareentwicklung setzen, werden Minimallösungen sehr kritisch betrachtet. Schnell wird in Wiederverwertbarkeit, Konfigurierbarkeit und sehr solide Lösungen investiert ohne genau das Endstadium zu kennen.

Ich sehe dies zunehmend kritischer.

Ich habe nichts gegen Qualität und gute Software. Ich habe allerdings etwas gegen Investitionen, die nie eine Rendite erwirtschaften.

In der Softwareentwicklung wird bei “Verschwendung” gerne auf die Implementierung von Features verwiesen, die (fast) nie benutzt werden. Zu selten werden jedoch auch die inneren Werte der Software kritisch hinterfragt. Häufig wir ausschließlich mit Beispielen argumentiert, in denen überhaupt keine Rücksicht auf die interne Struktur genommen wurde. Diese dienen dann als Begründung für umfangreiche Umbauarbeiten. Die Auswirkungen dieser Änderungen auf die Gesamtkosten wird dann häufig nicht mehr betrachtet.

Es ist doch meist so, dass ein Kunde für Features zahlt, die er beauftragt hat und dann nie nutzt. Für mögliche Verbesserungen an der internen Struktur der Software zahlt er typischerweise nicht, diese erwirtschaften eine Rendite, indem die Wartungskosten sinken. Leider ist dies zu häufig nicht der Fall.

Beispiel: “Wir mussten das konfigurierbar machen (1), da wir sonst bei jeder Änderung an der Darstellung der Seite drei weitere Dateien hätten anpassen (2) müssen!” ist eine typische Begründung von Entwicklern.

Meiner Meinung nach steckt hinter (1) oft der Spaß, etwas “solides” zu bauen. Hier ist der Ingenieur gefragt. “Wofür habe ich denn sonst studiert?”. Zudem kommt oft noch eine Brise Angst hinzu, sich bei einer einfachen Lösung später rechtfertigen zu müssen “(“Warum habt ihr nicht … ?”).

Bei (2) geht es darum etwas am Laufen zu halten. Ein pragmatischer Handwerker zimmert etwas zusammen. Die Aufgabe ist nicht sonderlich spannend und wir wissen alle, dass früher oder später etwas noch einmal angepasst werden muss. Leider ist dies auch oft die Quelle von Fehlern, die lange gesucht werden müssen – Fehler die entstehen, wenn man die “langweilige Handwerksarbeit” nicht sorgfältig durchführt.

Leider führt eben auch (1) oft zu hohen Folgekosten, beispielsweise wenn während einer Entwicklung etwas zu früh verallgemeinert wurde. Später werden weitere Aspekte hinzugefügt und die Annahmen für die Verallgemeinerung ändern sich. Das Konstrukt funktioniert nicht mehr, es muss angepasst und mit Balkonen versehen werden. Plötzlich wird aus einer soliden Ingenieursleistung eine immer weniger wartbare Ansammlung von Sonderfällen.

Code-Duplizierung doch  nicht böse?

Vor diesem Hintergrund sehe ich Code-Duplizierung – gerade bei bestimmten Teilen von Webseiten in Portalprojekten – nicht immer kritisch. Solange es handhabbar bleibt, kann man (sollte man?!) die Entscheidung, was als Verallgemeinerung extrahiert werden soll, hinausschieben. Zu einem späteren Zeitpunkt, wenn sich die Anforderungen in dem betroffenen Teil der Anwendung wirklich nicht mehr im großen Umfang ändern, kann schließlich eine Verallgemeinerung vorgenommen werden.

Hier der Song dazu:

… every build you break ….

Der Song hat es auch zur Tech-Ed 2008 geschafft, wie ein weiteres Video zeigt.

Muss ich mir wohl demnächst zulegen … ;-)