Thank you and bye bye

Scrum und Kanban sind sicherlich wichtige Methoden, um Software schnell und effizient zu erstellen – es reicht aber bei weitem nicht aus.

Neben einer agilen Philosophie und Werten wie Commitment, Focus, Openness, Respect und Courage braucht gute Software mehr! Dazu gehören exzellente Anforderungen, moderne Technik, und damit meine ich Architektur, Design und Code; genau so wie automatisierte Tests und ein schlankes Versions- und Releasemanagement.

Alles zusammen führt zu einer agilen Entwicklung – oder umgekehrt: Scrum und Kanban allein machen kein Projekt agil. Ich werde mich daher in Zukunft wieder mehr mit anderen Themen rund um die Softwareentwicklung beschäftigen und denke, dass dies nicht mehr unter das Label Agile Zeiten passt.

Mein Dank an alle, die es bis hier durchgehalten haben.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

The Edge of Chaos

oder was ist der Unterschied zwischen ‚complex‘ und ‚complicated‘?

Gerade bin ich über die Agreement & Certainty Matrix von Ralph Stacey gestolpert. Sie kommt aus seinem Buch Complexity and Creativity in Organizations (1999).

Die Agreement & Certainty Matrix kann dazu benutzt werden, Vorgänge in Organisationen zu verorten. Ganz hübsch, der Bereich ‚Anarchy‘ ist aus Management Sicht übrigens zu vermeiden…

Vereinfachte Form der Agreement & Certainty Matrix von Ralph Stacey, angepasst von Brenda Zimmermann
Vereinfachte Form der Agreement & Certainty Matrix von Ralph Stacey, angepasst von Brenda Zimmermann

Im Artikel wird der Streifen, der hier ‚complex‘ benannt wird auch als The Edge of Chaos referenziert. Aber wie würde man das definieren?

Robert Paterson: More on Complex versus Complicated schreibt dazu:

  • complicated = not simple, but ultimately knowable
  • complex = not simple and never fully knowable. Just too many variables interact.

‚complicated‘ ist ‚kompliziert‘.

‚complex‘ liegt am Übergang zwischen einem geordnetem System und Zufälligkeit oder Chaos. Das Wort gibt es auch im deutschen. Ein komplexes System ist in seinem Gesamtverhalten nicht beschreibbar, selbst wenn man vollständige Informationen über seine Einzelkomponenten und ihre Wechselwirkungen besitzt.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Termine Februar / März 2011

Folgende Termine in Hamburg finde ich im Februar und März interessant (bei denen mit * will ich dabei sein).

Termin Veranstaltung
* 3.3. 

18:00-19:00

How to Create Products Customers Love – Marty Cagan von silicon valley product group – via XING 

Marty Cagan erklärt in seinem Vortrag, warum XING ganz begeistert von seiner Methode ist. Wahrscheinlich kann man es auch hier nachlesen.

8.3. Story Maps als StrukturierungshilfeMarcus Winteroll – Open Oose (kostenpflichtig!) 

Eine Story Map ist in unserem Kontext eine zweidimensionale Darstellung des Product Backlogs. Der Erfinder der Story Maps ist Jeff Patton. Es handelt sich dabei um ein Verfahren, um effizient und effektiv mit umfangreichen Backlogs zu arbeiten.

15.3. 

19:00

Akzeptanztestgetriebene Entwicklung – Markus Gärtner – ObjektForum Nord 

„Obwohl Testen der Flaschenhals (Bottleneck) in den meisten traditionellen Projekten zu sein scheint, ist das eigentliche Problem eher, dass Projektentscheider gar nicht wissen, was in der Flasche drin ist.“ – Markus Gärtner

Die Akzeptranztestgetriebene Entwicklung (ATDD) ist eine Methode, um das gemeinsame Verständnis zwischen Product Owner und Entwicklungsteam weiter zu vertiefen.

15.3. 

19:00

Scrummtisch der Scrum User Group Hamburg

Findet erneut im betahaus | hamburg statt. Leider konnte ich letztes mal nicht dabei sein – und auch diesmal bin ich nicht in Hamburg. Schade. Absolut empfehlenswert für jeden Scrum Interessierten in der Stadt.

* 29.3. 

19:30-22:00

Kanban User Group Hamburg

Das zweite Treffen der neu gegründeten User Group und ebenfalls im betahaus | hamburg. Open Space zur Vertiefung der im ersten Treffen vorgeschlagenen Themen.

* 31.3. 

16:00-17:00

Agile Teamsteuerung – Björn Jensen und Malte Sussdorff -Webinar 

Die Referenten werden über Werkzeuge zur Unterstützung des Projektmanagements in agilen Projekten sprechen.

Veröffentlicht unter Veranstaltung | Kommentar hinterlassen

XP Days Germany 2010 – Tag 2

Zweiter Tag der xpdays in Hamburg. Die Atmosphäre ist super. Die Sessions sind kreativ und inspirierend gestaltet und binden die Teilnehmer geschickt ein. Das macht Spaß und fördert die Kommunikation untereinander. Leider bin ich zu spät für die Keynote gekommen.

10:45 Kata – Der tägliche Schattenkampf des Programmierers – Marko Schulz, Arne Roock, Sebastian Sanitz, Bernd Schiffer (it-agile)

Eine exzellente Session. Arne Roock beginnt mit einer Vorführung einer Shotokan Kata. Schon eine abgefahrene Sache.

‚Katas helfen Grundschritte zu verinnerlichen um sie ohne Nachenken anzuwenden.‘ Z.B. Karate, Tanzen, Gitarre und eben auch Programmieren. Warum Kata? (1) Alternative Lösungswege ausprobieren, (2) verschiedene Einschränkung ‚erleben‘ (z.B. mal ohne Maus arbeiten), (3) selbst-Reflexion beim Betrachten einer aufgezeichneten Kata, (4) Übung der ‚Griffe‘ auf der Tastatur, (5) Erreichen von technischer Exzellenz, (6) Verinnerlichung des TDD Zyklus.

Dann folgt die Vorführung einer Programmier Kata von Marko Schulz: TDD, JavaScript, Tests mit jspec. Nach 10 Sekunden ist er beim Programmieren – denn auch das Starten der ‚IDE‘ gehört zur Kata. Er nimmt TextMate, das geht schnell. Es ist sehr interessant, ihm beim Programmieren zuzuschauen. Zum Schluss löscht er den Code. Ich hätte nicht so kleinschrittig gearbeitet, aber so gelingt es ihm (fast) immer beim Refaktoring grün zu bleiben. Marko sagt, er habe die Kata ca. 40 mal gemacht und vor einer Woche war sah sie noch ganz anders aus.

Täglich 20 Minuten Zeitnehmen und die Kata Wiederholen, Wiederholen, Wiederholen. Das klingt ein wenig komisch, oder? Aber ich werde es nächste Woche probieren – so als Start-in-den-Tag.

Slides mit weiteren Links: http://www.slideshare.net/BerndSchiffer/kata-der-tgliche-schattenkamof-des-programmierers

12:00 Enterprise Kanban bei mobile.international GmbH – Markus Andrezak, Stefan Roock

Ein Vortrag als Rollenspiel, sehr gut gemacht, da denke ich die ganze Zeit mit. Die Idee ist, das Meta-Projektmanagement mit einer Kanban ähnlichen Darstellung zu visualisieren. Die einzelnen Spaltentitel sind: Idee, Vision, Envisioning, Development, Live, Vision und Envisioning noch mit Unterteilung Ongoing / Done, das ist wichtig für ‚Pull‘. Mit verschiedenen Farben wird die Projektklasse visualisiert, beispielsweise, ob es für die internationale Plattform oder für das allgemeine Tooling ist. Mir gefällt die Idee, auch wenn es kein Kanban ist, denn es geht hier nicht darum Artefakte (also Ideen/Projekte) möglichst schnell Live zu bringen, sondern aufzuzeigen, wo man gerade steht. Projekte können auch sterben oder sich zurückbewegen, wichtigere Projekte können unwichtigere verdrängen und Projekte können geparkt werden. Die Idee ist super und ich würde sie vielen Firmen zur Nachahmung empfehlen.

Bemerkenswert: Das Vorgehen hat bei mobile.de gezeigt, dass es Fokusproblem im Business gab (40 Ideen für Projekte on Board bei 120 Mitarbeiter) und dass vorher vermutete Kapazitätsprobleme in der Entwicklung so gar nicht auftreten.

12:30 Pause

Aus parallelen Vorträgen: Traian Kaiser soll gesagt haben, dass 10%-20% der Mitarbeiter den Umstieg in ein Lean Enterprise gar nicht schaffen und im Vortrag von Jens Himmelreich wurden Erklärungen dazu aufgezeigt, u.a. weil ganz neue persönliche Eigenschaften wie Kommunikationsgeschick, Kooperationsfähigkeit und Umgänglichkeit gefragt sind.

13:30 Erfahrungsbericht einer Team-Entdeckungsreise zum Agilen Testen – Andreas Ebbert-Karroum (codecentric)

Tool: Robot Framework, Andreas findet es Fitnesse überlegen, weitere Tools JMeter, Sonar (Tool zur Visualisierung von Testmetriken)

Interessant: (1) Es gibt praktisch keine Toolunterstützung für das Refaktoring der Tests. Tests in Randbereichen (z.B. Versand automatisch generierter PDFs per Email) sind nach wie vor viel Arbeit. (2) Bei Robot Framework kann man Tests als kritisch/unkritisch taggen. Unkritische Tests führen nicht mehr dazu, dass der Build als fehlgeschlagen betrachtet wird. (3) Automatisierte Akzeptanztests bescheren dem Team Entspannung, wenn die Anwendung Live geht.

Andere Lösungsidee für Timeout bedingte Fehler: Einen solchen Test bis zu dreimal automatisch wiederholen und nur bei drei Fehlversuchen als fehlgeschlagen markieren. Echt kreativ.

15:40 Die entscheidende Session – Bernd Schiffer

Exzellent und viele Gedanken zum Weiterverfolgen.

Satisficing – Hilfsmittel zur Entscheidungsfindung: Nicht die beste Lösung finden, sondern die erste passende.

Das Problem mit Abstimmung im Team ohne Konsens: Es gibt Verlierer, die sich vielleicht auch so fühlen. Evtl. bilden sich auch zwei gegeneinander positionierte Gruppen.

Konsent funktioniert gut im Team: Thumbvoting, ja, nein (Veto mit Begründung) oder Mittragen der Entscheidung für einen gewissen Zeitraum.

Experten können dank Intuition sehr gute Entscheidungen treffen. Aber Achtung vor der Konterintuition: Logik- und Statistikprobleme lassen sich nicht intuitiv lösen. Viele Menschen lassen sich auch leicht in verbale Fallen locken. Disziplinierte Menschen können risikoreiche Entscheidungen besser treffen, weil sie nicht nur der Intuition vertrauen.

16:50 Magic Estimation – Sven Röpstorf

Sven stellt Magic Estimation als eine Weiterführung von Affinity Estimation vor. Die Idee dahinter, wie auch bei Team Estimation: In einem ersten Schritt schätzt jeder Teilnehmer ein Subset des zu schätzenden Backlogs alleine ab und in einer zweiten Runde werden diese Ergebnisse durch die Gruppe begutachtet und eventuell korrigiert. Ich denke, damit kann man sinnvoll viele Schätzworkshops beschleunigen. Sven sagt, dass er Planning Poker seit einem Jahr nicht mehr eingesetzt hat und nur noch mit Team Estimation arbeitet.

17:45 fin

und jetzt ab zur Weihnachtsfeier…

Veröffentlicht unter Scrum, XP | Kommentar hinterlassen

XP Days Germany 2010 – Tag 1

Heute sind die xpdays in Hamburg. Ich bin auf eine kommunikative Community mit vielen engagierten Menschen getroffen. Im Programm finden sich viele Scrum Themen, das Niveau der Sessions war allerdings durchweg zu niedrig. Wettgemacht wird dies dadurch, dass ich mich wirklich auf ein Thema fokussiere (das macht immer Spass) und durch die interessanten Gespräche zwischendurch.

9:30 Communities of Practice – Workshop von Christoph Mathis

Wir kennen sie alle: User Groups sind CoPs oder die Arbeitskreise innerhalb einer Firma. Ich fand es interessant, dass eine CoP ein Gesicht braucht (den Koordinator), dass sie immer auch einen Mehrwert für alle Beteiligten liefert; dass man für firmeninterne CoPs den Gewinn für die Firma herausstellen kann und so auch Unterstützung ‚von oben‘ erhält.

11:15 Pause

Im Gespräch habe ich von einem Multi-Team Projekt gehört, das sehr gute Erfahrungen mit Feature Branches unter SVN gemacht hat. Automatisierte Tests laufen auf den Branches und auf dem Trunc und jedes Team ist dafür verantwortlich – bei Erreichen einer gewissen Reife – seine Entwicklung in den Trunc zu mergen.

11:30 Agile Requirements Engineering mit Scrum – Roman Pichler

Roman ist ein exzellenter Redner. Aber inhaltlich gab es nicht viel Neues. Schön fand ich ‚Emergenz‚, und interessant seine Aussage, dass in einem Multi-Team Scrum Projekt nur ein Produkt Backlog existieren soll (man baut ja auch nur ein Produkt) und die Product-Owner sich Teile des Backlogs heraussuchen. Wichtig auch: Es muss einen verantwortlichen Product-Owner für das gesamte Backlog geben. Sonst fokussieren sich die Product-Owner auf ihre ‚eigenen‘ Ziele und verlieren das Gesamt-Projektziel aus dem Auge.

13:30 Selbstorganisation von Teams – Uwe Friedrichsen

Fishbowl – ich habe noch nie eine erlebt und sie funktioniert prima, das habe ich nicht erwartet. Interessant Aussagen: (1) Die Frage ist nicht, ob Menschen sich selbstorganisieren können/wollen oder nicht, sondern wie wir es schaffen, dass sie es tun; denn es gibt keine Alternative. (2) Selbstorganisation funktioniert besser mit Generalisten, aber die besten eines Gebietes sind Spezialisten. Wenn diese nicht teamfähig sind, funktioniert Selbstorganisation nicht. Man muss die Verbindung zwischen den Menschen fördern. (3) Ein Team ist eine Gruppe von Menschen mit einem gemeinsamen Ziel. (4) Viele Dinge sind hart vorgegeben. Das Team muss Verantwortung übernehmen. Wenn die Ziele des Teams nicht erreicht werden, dann muss es schmerzhaft sein. Diese Schmerzen kann der Coach dem Team zu fügen. (5) Bei Semco organisieren die Teammitglieder sogar ihr Gehalt selbst.

15:00 Clinic Gespräch über das Review und seine Funktion

Sollen die Stories beim Review abgenommen werden? Nein, der Product-Owner soll die Stories schon während des Sprints abnehmen. Im Review zeichnet das Team und der Product-Owner ein aktuelles Gesamtbild des Produktes für sich und die Stakeholder. Das Review ist ist ein konstruktives Arbeitsmeeting und schafft die Grundlage für die weitere Planung.

16:15 Übung: „Automatisierung von Akzeptanztests“ – Alexandra Imrie, Hans-Joachim Brede (Bredex)

Akzeptanztests sind black-box Tests und testen das Produkt mit Hilfe der Oberfläche, aber nicht die Oberfläche selbst. Im Anschluss habe ich mit Kollegen gesprochen, die sagten, dass sowohl Selenium als auch WebDriver noch viele Macken haben und man immer wieder (hauptsächlich durch zeitliche Inkonsistenzen beim Test asynchroner Abläufe) falsch negative Testergebnisse erhält.

17:30 Fin

Veröffentlicht unter Scrum, XP | Kommentar hinterlassen

Termine Dezember 2010

Folgende Termine in Hamburg finde ich im Dezember interessant (bei denen mit * will ich dabei sein).

Termin Veranstaltung
* 9.12. 18:30 Die Scrum User Group Hamburg trifft sich im betahaus zum Scrumtisch, um über Scrum und agile Methoden zu diskutieren. Die Teilnehmer sammeln am Anfang des Abends bei einem Feierabendbier die Themen und Sessions und diskutieren diese dann im Open Space.
* 24.12. bis 26.12. Heiligabend und Weihnachten
Veröffentlicht unter Veranstaltung | Kommentar hinterlassen

Gestern bei Lehmanns: Dierk König – Groovy für Java Projekte: Sieben Einsatzmuster

Dierk König hat ziemlich zu Anfang in seinen Vortrag gestern Groovy für Java Projekte: Sieben Einsatzmuster gesagt (sinngemäß): „Was passiert wenn man einem Ruby- und einem Java Entwickler eine Story zum Implementieren gibt? Der Ruby Entwickler fängt mit der Funktionalität an, der Java Entwickler baut erstmal ein Framework“.

So ganz unrecht hat er nicht, obwohl es immer auch eine Frage der Persönlichkeit ist, wie eine Aufgabe gelöst wird. Auf jeden Fall beleuchtet es das Ziel Agilität von einer anderen Seite: Es ist nicht nur wichtig, das richtige Vorgehensmodell zu wählen, um agil zu entwickeln, sondern auch die richtigen Programmiersprachen und Frameworks. Wer seine Software in C++ entwickelt wird langsamer vorankommen, als in Ruby, das gleiche gilt auch für Änderungen.

Ein guter Grund sich als Java Entwickler mit Groovy zu beschäftigen: An agile dynamic language for the Java Platform. Es ist die ‚Erweiterung‘ von Java, die mir schon oft gefehlt hat, für schnelle Tests, für die schnelle Entwicklung. Groovy hat eine einfache Syntax und Closures, Groovy kann auf Java Objekte zugreifen und umgedreht, Groovy ist (zumindest in der IntelliJ IDE, das haben wir im Vortrag gesehen) voll in das Refactoring integriert, d.h. Änderungen an Java wirken sich auf den Groovy Code aus und umgekehrt.

Der Vortrag in der Java User Group Hamburg war großartig: Dierk König ist ein Präsentationstalent, er hat aus dem Vortrag eine Show mit ungefähr neun Folien und einer genialen live Programmierung gemacht. Vielen Dank!

Im Vortrag hat er sieben Einsatzmuster vorgestellt:

  • Alleskleber
    Erstelle Views and controller mit Groovy, den Rest mit Java.
  • Weiches Herz
    Nicht das Business ändert sich schnell, sondern unser Verständnis des Businesses. Groovy kann für das Skripting der Business Rules eingesetzt werden. So bleibt die Geschäftslogik flexibel.
  • Endoskop
    Minimal invasive Operation „in vivo“. Bei Bedarf mit einer Backdoor in den laufenden Server Groovy Scripte einspielen, um Fehler zu patchen ohne den Server runter fahren zu müssen; und so Zeit für eine ‚richtige‘ Lösung zu finden.
  • Kluge Anpassung
    Konfiguration um Logik erweitern.
  • Grenzenlose Offenheit
    Die ganze Anwendung in Ruby.
  • Heinzelmännchen
    Delegate the housework. Beispielsweise Build scripte zur Automatisierung. Sehr beeindruckend war das Beispiel zum Laden einer WebSite mit HtmlUnit. Auch wenn HtmlUnit gar nicht im Pfad vorhanden war: Mit @Grab im Script wurde aus einem Maven Repository die jars für HtmlUnit geladen und in den Klassenpfad gelegt. So kann man sehr einfach gute Dinge wiederverwenden und quasi aus den maven Repositories heraus benutzen.
  • Ideal
    Put a Layer of beauty on top of powerful libraries. Das Schillersche Ideal stand Pate für den Namen.

Er ist noch auf gradle eingegangen: Mächtiger als ant und flexibler als maven, optimal für inkrementelle Builds. Und auf grape, einem command line tool zur Installation von jars – analog zu apt-get.

Und zur Frage Groovy weigere sich gegen eine Standardisierung: Es sei doch schon viel im JSR 241 standardisiert.

Fazit: Ich würde Groovy in einem nächsten Projekt gerne einen Versuch geben.

Zum Schluss noch eine interessante Idee und Angebot von Dierk König bzw. canoo: Share a canooi – Ein Entwickler von canoo kommt für einen Tag und programmiert mit dem Team – kostenlos (bis auf Spesen).

Veröffentlicht unter Java | Verschlagwortet mit | 1 Kommentar