Das Nikolausgeschenk im digitalen Stiefel: Open Space Rap

Wer gestern seine digitalen Stiefel geputzt und vor die Tür der eigenen Website gestellt hat, der darf sich über ein kleines Geschenk freuen.

Auf dem Community Day der diesjährigen XP Days Germany in Karlsruhe habe ich gemeinsam mit Jens Coldewey, Christian Dähn und Urs Reupke die wesentlichen Ideen und Elemente des Open-Space-Formats in einen Sprechgesang verpackt. Wieder zu Hause, nahm jeder seinen Rap auf. An dem Rohentwurf der Melodie wurde in den folgenden Tagen weiter gefeilt. Dann wurde gemischt, gelauscht, illustriert und produziert. Das Ergebnis:

Der Open Space Rap

 

Ich wünsche viel Spaß beim Lauschen und einen schönen Nikolaustag!

XP Days Germany 2011: Im Süden wenig Neues

Nach zwei Vortragstagen (17./18.11.) und einem Community Day (19.11.) fuhr ich ein wenig ernüchtert von den XP Days 2011 aus Karlsruhe zurück nach Hamburg. Nicht, dass mir die Veranstaltung nicht gefallen hätte. Sie war auch in diesem Jahr wieder gut organisiert. Auch habe ich viele Freunde und Bekannte wiedergetroffen und neue interessante Menschen kennen gelernt. Es fehlte mir jedoch das „Aha!“-Erlebnis, die ungewöhnliche Idee, die neue Perspektive, der frische Wind. Alles irgendwie schon mal da gewesen, schon mal gehört oder gelesen, schon mal erlebt – zumindest an den beiden „klassischen“ Vortagstagen. Es fehlte das „Extreme“. Johannes Link stellte im Interview mit Matthias Lübken fest, dass die XP Days im Mainstream angekommen sind. Das ist nicht unbedingt schlecht, aber es fühlt sich einfach anders an als in den vergangenen Jahren. Weiterlesen

SEACON 2011: Meisterschule des Softwareingenieurwesens

Logo der SEACON 2011Am 27. und 28. Juni 2011 findet in Hamburg die SEACON 2011 statt. Die Konferenz steht in diesem Jahr unter dem Motto „Softwareengineering als Handwerk. Meisterhaft!“ Dahinter steht die Frage, welche Werte und Tugenden des Handwerks auf die Softwareentwicklung übertragen werden können. Mit anderen Worten: Wie wird ein Softwareentwickler vom Gesellen zum Meister? Weiterlesen

XP Days Germany 2010: Tolle Tage in Hamburg

Nicht nur die Karnevalisten haben ihre drei tollen Tage, sondern auch die agile Community. Deren Karneval heißt „XP Days Germany“ und fand in diesem Jahr turnusmäßig in Hamburg statt. Die Veranstalter hatten die altehrwürdigen Räume der Handwerkskammer als Veranstaltungsort auserkoren – ein passender Rahmen, ging es doch unter dem Motto „All about Agile“ auch um die handwerklichen Aspekte der Softwareentwicklung.  Weiterlesen

SEACON 2010: Der Blick hinter die Schlagwörter geht weiter

Nach dem letztjährigen Premierenerfolg der Software-Engineering-Konferenz SEACON betrat ich gestern das Hotel Atlantic in Hamburg mit hohen Erwartungen. Damit war ich nicht allein. Die ersten Gäste, die ich im Ausstellungsraum traf, waren allesamt Wiederholungstäter. Und so blickten wir gespannt den zwei Tagen voller Vorträge und spannender alternativer Formate entgegen, die 2009 den Reiz dieser kleinen, aber feinen Konferenz ausgemacht hatten. Weiterlesen

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…

Scrumtisch Hamburg: Aller guten Dinge sind drei

Es heißt ja, dass ein Scrum-Projekt nach drei Iterationen die Phase der Eingewöhnung überwunden hat und so richtig durchstartet. Vielleicht liegt es an der Scrum-Affinität der Teilnehmer, dass sich der dritte Hamburger Scrumtisch so anfühlte, als wäre dies eine im positiven Sinne alteingesessene Institution. Die Organisation klappte wieder reibungslos (dafür mein besonderer Dank an die Organisatoren). Die kurze Vorstellungsrunde zu Beginn bestätigte die hohe Zahl an Stammgästen. Es hatten aber auch einige Erstbesucher den Weg ins P.I.A.-Kesselhaus in Ottensen gefunden. Überraschend hoch war die Zahl derer, die offen bekannten, derzeit auf Jobsuche zu sein. Eine Auswirkung der Finanzkrise? Oder Zeichen dafür, dass agil Infizierte sich nicht einfach über ihr Arbeitsumfeld beschweren, sondern tatsächlich die Konsequenzen ziehen, wenn sie feststellen, dass sie die agilen Ideen in diesem Umfeld nicht verwirklichen können?

Der inhaltliche Teil begann mit zwei Vorträgen. Zunächst stellte Markus Wittwer (oose) kurz die Ergebnisse der Studie „Einfluss klassischer und agiler Techniken auf den Projekterfolg“ vor. Anschließend präsentierte Sebastian Neus (itemis) ein Konzept, wie man Product Backlogs noch besser (im Sinne der Maximierung des Geschäftswertes) machen kann. Da beide Vorträge intensiv diskutiert wurden, machte es auch nichts, dass sie für meinen Geschmack etwas zu lang waren.

Persönliches Schmunzel-Highlight war die von Sebastian vorgestellte Idee des „Build-Breaker-T-Shirts“. Diese Idee war in einem seiner Projekte von der Entwicklungsmannschaft eingeführt worden und bestand aus nur zwei Regeln:

  1. Wer den Build bricht, der muss dieses T-Shirt tragen.
  2. Das T-Shirt wird nie gewaschen.

Eine einfache Methode, um schlechte Entwicklungsdisziplin förmlich zu riechen…

Frisch gestärkt ging’s anschließend in bewährter Weise mit Open Spaces weiter. Ich nahm an zwei spannenden Diskussionen teil. In der ersten ging es um die Frage, ob man „messen“ kann, wie geeignet eine Person für die Arbeit in einem agilen Team ist. Die Transparenz und die Ergebnisorientierung agiler Projekte decken fachliche und soziale Defizite schonungslos auf, und nicht jeder kann und mag sich darauf einstellen. Im Team wird man fast immer ein fachliches Leistungsgefälle vorfinden. Das lässt sich mit Praktiken wie Pair Programming und Coaching/Mentoring einigermaßen nivellieren – vorausgesetzt, die „Lehrer“ besitzen die nötige Sozialkompetenz, um ihr Wissen vermitteln zu können (und zu wollen), und die „Schüler“ sind stark genug, diese Hilfe vor den Augen des restlichen Teams anzunehmen. Was aber tun mit Teammitgliedern, sie sich überhaupt nicht integrieren können? Immer wieder hört man den Rat. „Nehmt diese Menschen aus dem Team heraus.“ Leichter gesagt als getan. Oft sind die organisatorischen Voraussetzungen für eine flexible Jobrotation nicht gegeben. Außerdem wechseln sich in der IT Personal- und Geldknappheit in schöner Regelmäßigkeit ab, und beide Restriktionen sind nicht gerade förderlich für die Entwicklung „idealer“ Teams. Das weitaus größere Problem ist allerdings das (typisch deutsche?) Ideal der gradlinigen Karriere. Wer im Laufe seiner beruflichen Entwicklung in fachfremde Bereiche wechselt oder vermeintlich einen Schritt zurück macht, der gilt auch heute noch als schwach und wird fortan Probleme haben, auf der Karriereleiter unbeschwert nach oben zu klettern. Damit ist die These, dass es sich um ein Generationsproblem handelt, vom Tisch, denn auch die heutigen Berufsanfänger werden (zumindest in den konservativ strukturierten großen und mittelständischen Unternehmen) an demselben Maß gemessen wie die Generationen vor ihnen.

Der Change Agent für agile Teams ist der Scrum Master – aber ist er überhaupt dazu in der Lage? Und wer kann das beurteilen? Das war das Thema einer weiteren Open-Space-Diskussion (an der ich leider nicht teilnehmen konnte). Hier wurde der Frage nachgegangen, ob man eine Supervision für Scrum Master etablieren sollte. Dieses Konzept ist in anderen Bereichen etabliert, insbesondere bei Lehrern und Sozialarbeitern, und verfolgt das Ziel, über Selbst- und Fremdreflexion zu lernen und das eigene Verhalten zu verbessern. Klingt nach einer persönlichen Retrospektive, oder? Liegt es da nahe, auch für Scrum Master eine Supervision zu fordern? Ein spannendes Thema…

Ich habe mich dann in der zweiten Open-Space-Runde des Abends der Frage gewidmet, was man gegen „Ermüdung“ im Scrum-Team unternehmen kann. Die konkrete Situation: Das Team befindet sich im zwanzigsten Sprint, alles läuft wie geschmiert, fühlt sich aber mehr nach täglichem Trott als nach dem sagenumwobenen „Flow“ an. Wo aber hört der Flow auf und fängt die Ermüdung an? Sobald die agilen Werte vernachlässigt werden? Wenn das Team keine Lust mehr hat? Und wer empfindet die Situation als ermüdend? In unserer Diskussionsrunde war es der Scrum Master, der aber zugeben musste, dass das Team durchaus zufrieden mit der neuen Gemütlichkeit war. Damit steckte er in der Zwickmühle: Wissend, dass aus dem Team mehr Leistung herauszuholen wäre, andererseits fühlend, dass er seinem Team diese Ruhe durchaus gönnen sollte. Die Ideen, die wir aus dieser Situationsbeschreibung entwickelten, hatten letztendlich alle dasselbe Ziel: Etwas Überraschendes zu tun bzw. zu fordern. So könnte man die Sprint-Dauer verkürzen, um den Trott zu durchbrechen und das Team neu zu stimulieren. So geschehen in einem konkreten Projekt – mit dem erstaunlichen Ergebnis, dass das Team im verkürzten Sprint genauso viel erledigt hatte wie im längeren Sprint. Eine andere (tatsächlich praktizierte) Möglichkeit ist die Ausschreibung eines „Hackathlon“-Wettbewerbs. Drei Tage lang wurden die Entwickler aller Scrum-Teams von ihren Aufgaben befreit und bekamen stattdessen das Ziel formuliert, innovative technische Lösungen zu ersinnen und prototypisch zu entwickeln. Die Ergebnisse wurden gegeneinander bewertet, und den Siegern winkte ein Preis. Ähnliches kann man erreichen, indem man den Sprint nicht verkürzt, aber nur vier Tage pro Woche auf das Sprint-Ziel verwendet. Den fünften Tag nutzt man dann für die Evaluierung neuer Technologien, konsequentes Refactoring und andere innovative und die Qualität verbessernde Maßnahmen. Dieses „4+1“-Prinzip hat den Vorteil, dass es ohne nach außen sichtbare Prozessveränderung auskommt – die Projektcontroller wird das freuen… Um die Kundenorientierung zu verbessern, kann man regelmäßige Hospitationen bei den Nutzern des Softwareprodukts durchführen (deren Einverständnis vorausgesetzt). Nichts hilft besser, als den Endanwendern bei deren Arbeit über die Schulter zu schauen und Fragen zu stellen.

Der Hamburger Scrumtisch wurde abschließend von allen Teilnehmern für seine offene Atmosphäre gelobt. Das nächste Treffen soll in drei Monaten stattfinden und wird wie üblich in der XING-Gruppe „Scrum User Group Hamburg“ angekündigt.

SEACON, Tag 2

Heute hatte ich etwas mehr Zeit, um Vorträge zu besuchen. Zwischendrin durfte ich noch eine spannende Open-Space-Diskussion moderieren. Aber der Reihe nach:

Dirk Krafzig hat sehr schön die Rolle des Service Owners in einer serviceorientierten Organisation skizziert. Hier geht es nicht um die Kompatibilität von Web Services, sondern um die Vermarktung von wertschöpfenden Diensten. Letzteres ist ungleich schwieriger (vielleicht sogar komplex?) und verlangt nach einer charakter-und durchsetzungsstarken Person. Mich hat der „Steckbrief“ für den idealen Service Owner an den Product Owner aus Scrum erinnert, der eine ähnlich anspruchsvolle inne hat. Wer allein die technischen Unzulänglichkeiten der SOA-Werkzeuge für den schleppenden Erfolg einer SOA-Initiative verantwortlich macht, der hat laut Krafzig die wahren Probleme noch nicht erkannt. Diese These konnten einige Zuhörer mit konkreten Beispielen illustrieren.

Die von mir moderierte Open-Space-Diskussion trug den schönen Namen „Ohne gute Namen keine gute Software“. Dahinter steht die These, dass die „ungeschickte“ Benennung von Codeelementen einen beachtlichen (negativen) Einfluss auf die Qualität und folglich die Akzeptanz von Software hat. Inspiriert von Wolf Lotters Eröffnungsrede am Vortag machten wir uns daran, die Wurzeln des Übels der nachlässigen Namensgebung zu finden. Schlamperei, fehlende Erfahrung, bewusste Verschleierung und fehlende Freude am Umgang mit Sprache waren einige der Gründe, die wir herausgearbeitet haben. Und wir stellten uns die Frage, ob es immer eine Terminologie gibt, die von Fachbereich und IT-Abteilung gemeinsam benutzt werden kann. Eine große Herausforderung bei der Suche nach einer solchen gemeinsamen Sprache ist die von der IT geforderte Formalisierung, die vielen Fachbereichen schwerfällt. Die interdisziplinär besetzte Runde (eine Diplom-Übersetzerin und ein paar sprachaffine Informatiker) war am Ende überrascht, wie vielschichtig sich die Diskussion zu einem ursprünglich sehr technisch anmutenden Thema entwickelt hatte.

Den tollen Vortrag von Horst Zuse, in dem er anhand vieler Anekdoten und Originaldokumente die Pionierleistung seines Vaters Konrad auf dem Gebiet der Computertechnik lebendig werden lässt, hatte ich schon auf der diesjährigen JAX gehört. Diesen Vortrag möchte ich jedem IT-geschichtlich Interessierten ans Herz legen.

Der Regatta-Sieger in der Klasse „Einer ohne PowerPoint (oder Keynote)“ war Stefan Tilkov. Dessen MacBook Air hatte Kommunikationsprobleme mit der Präsentationstechnik, die Stefan ganz pragmatisch löste: Er hielt den Vortrag folien- und einwandfrei. Jetzt weiß auch ich mit dem Akronym REST etwas anzufangen.

Von den Kurzvorträgen erhaschte ich nur zwei. Die bestätigten, dass es enorm schwer ist, ein Thema in nur zehn Minuten umfassend genug darzustellen. Dann hieß es auch schon: Messestand einpacken! Die erste SEACON war zu Ende. Das Stimmungsbild, das ich im Laufe des Tages ermittelt habe, war durchweg positiv. Die meisten Pluspunkte sammelte die SEACON durch die „alternativen“ Formate Open Space und Fishbowl, aber auch der reibungslose Service und die Küche des Hotel Atlantic wurden mehrfach lobend erwähnt. Mir gefiel die überschaubare Größe, die ich auch bei der SET in Zürich so angenehm finde. Auch aus Sicht eines Konferenz-Sponsors (ich war für meinen Arbeitgeber Holisticon im „Gründerkreis“ der SEACON aktiv, für uns war dies zugleich die erste Konferenzausstellung mit eigenem Stand) war die SEACON eine attraktive Veranstaltung. Nun bin ich gespannt auf die Nachbesprechung und freue mich auf die hoffentlich stattfindende SEACON 2010!

SEACON 2009

Und das sagen andere zur SEACON:

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.