Scrum – ein ehrliches Handwerk

…zumindest könnte man das annehmen, wenn der vierte Hamburger Scrumtisch in den Räumen der Hamburger Handwerkskammer stattfindet. Aufgrund der vielen Anmeldungen sahen sich die Organisatoren gezwungen, auf einen Veranstaltungsort auszuweichen, der mehr Raum bot als das kuschelige P.I.A. Kesselhaus in Ottensen, das bisher die Scrumtische beherbergte. Leider fanden gestern nur wenige Scrum-Interessierte den Weg zum Holstenwall. Diese „Mannschaft“, die sich aus alten Stammtisch-Hasen und Neulingen zusammensetzte, erlebte und gestaltete eine Veranstaltung, die ausschließlich das Open-Space-Format nutzte, um aus dem Gremium eingebrachte Themen in drei Runden an jeweils drei Tischen zu diskutieren. Das macht in Summe neun Diskussionsrunden. Vom „Gesetz der Füße“ wurde eher spärlich Gebrauch gemacht – vermutlich ein Indiz dafür, dass die Diskussionen zu fesseln vermochten. Ich musste früh aufbrechen und kam deshalb in den Genuss von nur zwei Open-Space-Runden.

Nachdem die Frage nach dem Wesen des User Story Mapping (Artikel|Video) in Ermangelung an Experten dieser Praktik nicht zufriedenstellend beantwortet werden konnte, vertagten wir dieses Thema auf den nächsten Stammtisch (glücklicherweise fand sich jemand, der das Thema mit dahin aufbereiten wollte) und widmeten uns stattdessen der Frage, wie man „gute“ Stories schreibt. Dem spontanen Schweigen nach zu urteilen, gibt es auf diese Frage keine schnelle Antwort. Wir versuchten deshalb, die Güte einer Story über deren Wert zu ermitteln. Natürlich schwirrte sofort der Begriff des Geschäftswerts im Raum. Als wir uns dann aber einigen konkreten Beispielen widmeten, mussten wir schnell feststellen, dass in bestimmten Projekten und allgemein in den ersten Sprints die Suche nach dem Geschäftswert recht schwierig ist. „Was spricht dagegen, den Geschäftswert in diesen Fällen durch einen anderen Nutzen zu ersetzen?“, fragten wir uns. Wie aber kann ein solcher Nutzen aussehen? Und wann entsteht dann der Geschäftswert? Nach einer „wert-vollen“ Diskussion mussten wir uns eingestehen, dass wir bei dem Begriff „Geschäftswert“ sofort an monetäre Größen denken. Es können aber tatsächlich ganz andere Aspekte eine Rolle spielen: Beispielsweise kann eine Story einen strategischen Wert besitzen, unter Umständen auch „nur“ einen ideellen Wert. Oder der Produktverantwortliche verbindet mit der hohen Priorisierung einer Anforderung einen zeitlichen Vorteil: Je früher das Feature verfügbar ist, umso länger hat man in diesem Bereich einen Vorsprung vor den Mitbewerbern. Ein Geschäftswert ist also mehr als nur Heller und Pfennig.

„Gute“ Stories sind immer überschaubar. Was aber, wenn der Kunde die Lösung mit dem Goldrand möchte, diese jedoch in einem Sprint nicht umsetzbar ist? Wie bricht man eine solche Story in kleinere Einheiten auf? Ein interessanter Vorschlag kam von Stefan Roock: Mittels Dimensional Planning. Darunter versteht man in der agilen Welt die Bewertung einer Story nach deren „Tiefe“, man könnte auch sagen: Komfort – vergleichbar dem System der Hotel-Sterne. Als Metapher für das Dimensional Planning nannte Stefan den Straßenbau. Um mit einem Fahrzeug von A nach B zu kommen, benötige ich eine Straße. Dabei kann es sich im einfachsten Fall um eine Schotterpiste handeln, über die ich mehr schlecht als recht mein Ziel erreiche. Eine mit Kopfsteinen gepflasterte Straße ist schon deutlich komfortabler, rüttelt mein Fahrzeug aber immer noch ordentlich durch. Das ist bei der asphaltierten Straße nicht mehr Fall. Trotzdem kann ich immer noch nicht so schnell fahren, wie ich eigentlich möchte. Das darf ich erst tun, wenn meine Straße zur Autobahn ausgebaut wurde. Ähnlich ist es beim Sterne-System im Hotelgewerbe: In einem Zwei-Sterne-Hotel kann man auch schlafen, weil der minimale Standard ein Bett umfasst. Im Fünf-Sterne-Grand-Hotel ist das Bett aber weicher, die Matratze nicht so durchgelegen, und der Service viel besser – das Frühstück wird mir direkt am Bett serviert. Kommen wir zurück zu den Stories: Diese lassen sich ebenfalls nach ihrem Komfort kategorisieren. Damit ist es möglich, in einem Sprint eine Story in der Drei-Sterne-Version umzusetzen, und zwei Sprints später dieses Feature mit Vier-Sterne-Komfort zu versehen.

Aber was genau macht denn nun eine „gute“ Story aus? Auf diese Frage haben wir leider keine allgemein gültige Antwort gefunden – vermutlich deshalb, weil es keine einfache Antwort auf diese Frage gibt.

Henning Wolf stellte in der zweiten Diskussionsrunde eine interessante These in den Raum: Mit Blick auf das agile Schätzen hinterfragte er den Sinn der Fokussierung auf die Größe einer Story. Seiner Meinung nach sollte man auch die Komplexität einer Story berücksichtigen. Eine saubere Definition des Begriffs „Komplexität“ bildete sich in der nachfolgenden Diskussion zwar nicht heraus (ist aber auch ganz schön kompliziert), aber die Idee, die hinter dem Schätzen von Komplexität steht, wurde dennoch deutlich. So sollte die Anzeige von Kundendaten in der Benutzungsoberfläche aus fachlicher Sicht genauso groß (d.h. aufwendig zu implementieren) sein wie die Anzeige von Lieferantendaten. Wenn letztere jedoch aus verschiedenen Datenquellen zusammengestellt werden müssen, dann dürfte die Komplexität dieser Aufgabe (im Sinne von miteinander in Beziehung zu setzenden Komponenten) höher sein als im Falle der Kundendaten, die aus einer einzigen Datenbank bezogen werden. Gleiche Aufgabe (Anzeige von Daten), aber unterschiedliche Komplexität (Datenzugriff): Wenn man das dem Kunden bewusst machen kann, dann besteht die Hoffnung, dass auf diese Weise die Erklärungen (bzw. Rechtfertigungen) agiler Teams ihrer vermeintlich zu hohen Größenschätzungen in Zulunft entfallen oder zumindest deutlich seltener vorkommen werden.

Die Komplexität kann aber multidimensional sein. Im genannten Beispiel hat der Zugriff auf Daten für verschiedene Domänen (Kunden, Lieferanten) eine unterschiedlich hohe Komplexität. Der Mechanismus für die Anzeige von Daten und den damit verbundenen Datenzugriff quer durch alle Systemschichten hat eine eigene Komplexität. Erst die Kombination dieser beiden Komplexitätswerte liefert für die Stories „Anzeige von Kundendaten“ und „Anzeige von Lieferantendaten“ eine realistische Gesamtkomplexität.

Ein weiterer Vorteil der „Komplexitätsorientierung“ wurde nur kurz andiskutiert und müsste meiner Meinung nach noch vertieft werden: Wie wirken sich Refactorings auf Größe und Komplexität einer Story aus? Ich hege die Hoffnung, dass es mit der kombinierten Bewertung von Größe und Komplexität möglich ist, unseren Kunden den Wert eines Refactorings nachzuweisen. Damit gehört dann hoffentlich eine weitere Diskussionskategorie („Was soll dieses teuere Refactoring? Ich sehen doch gar keine Veränderung!“) der Vergangenheit an. Unrealistisch? Vielleicht. Aber man wird doch wohl mal träumen dürfen…

SEACON, Tag 1

Das Experiment, eine Konferenz rund um Software Engineering im Norden zu wagen, kann man nach dem ersten Konferenztag als geglückt bezeichnen. Das war auch der Tenor meiner (nicht repräsentativen) Umfrage unter Teilnehmern, Ausstellern und Veranstalter. Das Geheimnis der SEACON liegt in der Mischung. Man beginne mit feinsinnigem Journalismus. Wolf Lotter, Mitbegründer von brand eins und Verfasser der Leitartikel zu den Schwerpunktthemen dieses Wirtschaftsmagazins, fragte in seinem Eröffnungsvortrag: „Worüber reden wir hier eigentlich?“ Sein Plädoyer für einen bewussten und pfleglichen Umgang mit Sprache war eindringlich und humorvoll zugleich. „Wenn Ihre Kunden [aufgrund der vielen Buzzwords] nur noch Bahnhof verstehen, dann werden sie wegfahren – das tut man schließlich an Bahnhöfen.“ Wie wahr…

Dass die SEACON keine Kopie der großen deutschen IT-Konferenzen sein sollte, wurde den Teilnehmern spätestens beim Open-Space-Marktplatz bewusst. Hier war Mitarbeit gefragt. Und es wurde fleißig mitgearbeitet – sogar so schnell, dass Bernd Oestereich und Jochen Meyer den Marktplatz aufgrund der beschränkten Raumkapazität vorzeitig schließen mussten. Die Open-Space-Diskussionen selbst verliefen nach den Aussagen der Moderatoren recht gut. Morgen gibt’s die Ergebnispräsentation, dann wissen wir mehr.

War der Open Space aus Sicht der Teilnehmer noch eines der einfacheren Formate, so gehörte beim Fishbowl schon eine Portion Mut dazu, um sich aus dem Plenum auf einen der fünf Diskussionsplätze zu begeben – und damit einen der anderen vier Diskutierenden zu verdrängen. Um so überraschter war ich, als sich sehr schnell und ganz natürlich eine lebhafte Fishbowl-Diskussion über komplizierte und komplexe Probleme entwickelte.

Schließlich durfte ich noch an einer Expertenbefragung zum Thema Agilität teilnehmen. Es gibt aus meiner Sicht bessere Formate, um Inhalte zu vermitteln – zwei habe ich oben bereits genannt.

Natürlich gab es auch die klassischen Fachvorträge, von denen ich nur Klaus Marquardts Ausführungen über den Umgang mit Komplexität in Projekten gelauscht habe. Mir gefiel die Mischung aus Thesen und Indikationen für Komplexität, die zum Nachdenken anregte, wenngleich ich ein etwas anderes Verständnis von komplexen und komplizierten Problemen habe (siehe Fishbowl).

Ich war sehr zufrieden mit dem ersten Tag dieser neuen Konferenz. Natürlich gibt es hier und da noch Verbesserungsmöglichkeiten, aber dem Anspruch, etwas anders zu sein als die anderen Konferenzen (aber mindestens genau so gut), ist die SEACON schon an Tag 1 gerecht geworden.

Fishbowl: Unterscheide komplizierte und komplexe Probleme und finde die dazu passenden Methoden, Prozesse und Strategien

Gemeinsam mit Klaus Marquardt, Bernd Oestereich und Jutta Eckstein durfte ich dem ersten Fishbowl auf der SEACON Starthilfe geben. Die Diskussion drehte sich zunächst um die Frage, wie man die Begriffe „kompliziert“ und „komplex“ definieren kann, ohne allerdings eine von allen akzeptierte Definition zu finden. Einige Diskussionsteilnehmer verwendeten beide Begriffe synonym und fanden es wichtiger, mit der Problemlösung zu beginnen, als sich mit der Kategorisierung zu beschäftigen. Das andere Lager (dem auch ich angehöre) würde zur Lösung komplizierter Probleme einen Experten zu Rate ziehen. Bei komplexen Problemen reicht das nicht aus. Hier gibt es nicht „die richtige Antwort“, weil sich der Problemraum unvorhersehbar verändert. Was tun? Einfach anfangen und auf die Kraft der Emergenz vertrauen. Die wenigen Regeln und Prinzipien, die agilen Verfahren zugrunde liegen, reichen aus, um dem Projektteam einen Rahmen zu bieten, innerhalb dessen es dem Problem zu Leibe rücken kann. Und damit sind wir plötzlich bei der Agilität. Das war dann auch das dominierende Thema in der zweiten Hälfte des Fishbowl.

Am Ende fehlte vielen Teilnehmern der rote Faden und ein Ergebnis. Das lag sicherlich daran, dass man ohne Definition in die Diskussion über komplizierte und komplexe Probleme gestartet war. Vielleicht hätte sich die „Startmannschaft“ im Vorfeld ein wenig abstimmen sollen. Haften blieb aber eine sehr pragmatische Definition der beiden Begriffe, die einer der Fishbowl-Teilnehmer wie folgt formulierte: „Kompliziert sind die Probleme, für die ich keine Zeit habe. Komplexe Probleme sind jene, für die ich keine Lösung kenne.“