Diese Frage blieb aus meiner Sicht beim Treffen in der Berliner Kalkscheune unbeantwortet. Klar war nur, dass man eine Zielgruppe nicht wie geplant erreicht hatte: der Prozentsatz an Teilnehmern aus größeren Unternehmen war nach Angaben des Veranstalters knapp zweistellig. Das mag daran gelegen haben, dass die Kommunikation im Vorfeld nicht zielgruppengerecht gewesen ist. Es liegt aber mit hoher Wahrscheinlichkeit daran, dass die Titel der Beiträge oft wenig über den zu erwartenden Inhalt aussagten. Statt sprechender Titel hatte man auf markige Worte gesetzt, und damit kann in einem größeren Unternehmen niemand seinen Chef überzeugen. Das weiß ich aus eigener Fachbereichsarbeit für die SEACON-Konferenz in Hamburg. Ein Beispiel: hinter dem Titel “I AM THE NEXT INDUSTRIAL REVOLUTION” verbarg sich eine spannende Podiumsdiskussion über den nächsten Innovationsschub. Den sahen Tore Meyer und Christian Bogatu in der Technologie und der technologiegestützten Kommunikation. Rogier van der Heide von Philips vertrat hingegen die These, dass Technologie nur mittel zum Zweck ist; der eigentliche Zweck sei es, den Menschen mit Hilfe der Produkte ein bestimmtes Gefühl zu vermitteln. So sollen die Philips-Beleuchtungskonzepte nicht einfach erleuchten, sondern beispielsweise eine Wohlfühl-Atmosphäre schaffen. Philips experimentiert mit Straßenbeleuchtungen, die Muster anstelle von einfarbigem Licht produzieren und damit bei Passanten eine Stimmung erzeugen wollen. Die Innovation steckt nicht im Leuchtmittel, sondern in der Erforschung geeigneter Muster. Hier sind weniger die Technologen als vielmehr die interdisziplinäre Arbeit verschiedener Disziplinen (z.B. Psychologen) gefragt. Als real existierendes Beispiel einer Symbiose von Groß und Klein nannte van der Heide die Öffnung der Philips-Reinräume für kleine Firmen. Startups können diese teuren Räumlichkeiten mieten, um ihre eigenen Chips zu produzieren. Umgekehrt lernt Philips von den Ideen, die diese Startups mitbringen und realisieren. Es waren diese Momente, in denen die Idee der Uber B2B Wirklichkeit wurde. Davon hätte ich gerne mehr gehabt.

Den Workshop “I CAN FLIRT AT THE OFFICE, WITHOUT DRAMA” ersparte ich mir (und vor allem meinen Kolleginnen) und nahm lieber am Design-Thinking-Crashkurs von Christian Beinke und Fried Große-Dunker (beide von Dark Horse) teil, der sich hinter dem unscheinbaren Namen “I CAN ACT LIKE A STARTUP” versteckte. Dort entwickelten wir gegenseitig in rund 20 Minuten ein neues Portemonnaie, das auf die jeweiligen Bedürfnisse zugeschnitten war. Wie man diese Bedürfnisse ermittelt? Durch Zuhören, offene Fragen, Abstraktion und Storytelling (ohne Selling). Die Session hat allen fünf Teilnehmern viel Spaß gemacht. Nur fünf Teilnehmer? Ja, leider. Auch für die anschließende Session, in der ich das eigentlich für Change Management konzipierte Spiel Fearless Journey auf ein Startup-Szenario adaptierte und moderierte, konnten sich nur sechs Teilnehmer begeistern. Denen aber hat das Spiel viel Spaß gemacht und einige neue Erkenntnisse gebracht. Bevor ich’s vergesse: diese Session firmierte unter “I CAN IMPLEMENT ALL I LEARNED TODAY”.

Warum waren die Workshops so mager besucht – und wo waren die ganzen Teilnehmer in dieser Zeit? Entweder beim Netzwerken – oder in den Panel-Diskussionen und Präsentationen. Dort war es nach Aussage einiger Teilnehmer deutlich voller. Ich war überrascht: von der Startup-Szene hätte ich einen deutlicheren Wunsch nach interaktiven Formaten erwartet. Stattdessen ließen sich viele klassisch berieseln.

Überrascht, aber noch nicht restlos überzeugt trat ich am Abend die Heimreise an. Ich glaube, dass die zweite Auflage der Uber B2B von der Mund-zu-Mund-Propaganda der Erstbesucher und einem gezielteren Marketing profitieren dürfte. Das lockt dann hoffentlich auch die Großen an – und dann hat man den Mix, nach dem sich viele sehnen und der diese Konferenz zu etwas Besonderem machen kann.

Jetzt hat mit ein Leser der “Geschichten vom Scrum” eine recht ausgefallene Quelle verraten: er ist auf das Buch über die Google-Bildersuche gestoßen. Ein Indiz dafür, dass PLAYMOBIL-Figuren bei der Zielgruppe anschlussfähig sind?

Die Mechanik des agilen Projektmanagement-Frameworks Scrum ist schnell beschrieben: drei Rollen, vier Meetings und drei Artefakte. Das Kennen und Beherrschen dieses Instrumentariums reicht aber nicht aus, um mit Scrum wirklich erfolgreiche Projekte durchzuführen. Ein agiles Wertesystem erschließt den Menschen in Scrum-Projekten neue Handlungsmöglichkeiten, fördert Innovation und eine ergebnisorientierte Arbeitsweise. Außerdem muss ein Scrum-Projekt in die wertschöpfenden Prozesse der Produktentwicklung eingebettet werden. Und schließlich gibt es neben den Kernelementen von Scrum noch weitere Methoden, Prinzipien und Praktiken, die sich in den vergangenen zehn Jahren im praktischen Einsatz bewährt haben. Die Summe dieser Aspekte und Perspektiven ergibt ein Ökosystem, in dem ein Produkt gut gedeihen kann. Unser Schalenmodell ist ein Versuch, dieses Ökosystem zu beschreiben. Ausgehend vom Produkt haben wir in unserem Vortrag das Schalenmodell (Halb-)Schale für (Halb-)Schale entwickelt. Anschließend baten wir die Teilnehmer in einer 20-minütigen Fishbowl um ihre Meinung.

Das obige Foto zeigt unser Schalenmodell, annotiert mit den Erkenntnissen aus der Fishbowl-Diskussion. Sehr lange und intensiv wurde über die untere Hälfte des Modells diskutiert. Hier sind die Teamaspekte beschrieben, von den Entwicklungstechniken bis hin zur Zusammenarbeit zwischen agilen Teams. Die zentrale Frage war (wie so oft): wie kommt man zu einem agilen Team? Schafft man lediglich den Rahmen, oder sucht man die “Richtigen” aus? Was tun mit Menschen, die nicht eigenverantwortlich arbeiten wollen? Gut gefallen hat mir der Vorschlag, wie man das aus dem Scrum Guide verbannte Commitment wieder einführen kann: als Selbstverpflichtung zum Engagement im Entwicklungsteam. Leichter gesagt als getan…

Aber auch die Management-Halbschale unseres Modells wurde diskutiert (berechtigte Frage aus dem Publikum: warum muss diese oben stehen, und die Team-Halbschale unten?). An der Schnittstelle zwischen “agiler Insel” und nicht agilem Organisationsumfeld kamen Alibi-Pläne zu Einsatz, der Wert guter User Stories wurde betont und mit der Frage verknüpft, wie man einen Product Owner dazu befähigen kann, seiner anspruchsvollen Rolle gerecht zu werden.

Spannend auch die Frage, ob man Agilität lediglich als Arbeitsmethodik betrachten kann und darf, oder ob es sich zwangsläufig um eine innere Einstellung und Geisteshaltung handelt, die sich nicht auf das Arbeitsleben beschränken lässt. Anders gefragt: kann eine Entwicklern oder ein Entwickler nur zwischen 9 und 17 Uhr agil sein? Ich glaube, dass das nicht geht, freue mich aber über Gegenargumente – z.B. als Kommentar auf diesen Blogartikel.

Die Erkenntnisse aus der SEACON des vergangenen Jahres hatte den Fachbeirat dazu veranlasst, die thematische Vielfalt besser zu ordnen und zu drei thematischen Tracks zusammenzufassen: Projektmanagement (auch agiles), Geschäftsprozesse und Softwarearchitektur. Die Entscheidung für letzteres Thema ist im Wesentlichen auf den großen Erfolg des letztjährigen Architekturtags zurückzuführen, der somit in diesem Jahr ins SEACON-Programm integriert wurde. Der Themenvielfalt hat die Track-Struktur aus meiner Sicht nicht geschadet – hier hat der Fachbeirat (dem ich in diesem Jahr erstmals nicht mehr angehörte – eine ungewohnte Situation) wieder eine tolle Arbeit geleistet. Den Teilnehmern bot die neue Struktur im Vorfeld offenbar die vielfach gewünschte Orientierung – mit dem Effekt, dass die Besucherzahlen im Vergleich zum Vorjahr leicht angestiegen sind.

Nicht nur die Track-Struktur war neu, sondern auch der Veranstaltungsort. Nach den Hotels Atlantic und Grand Elysée war in diesem Jahr das Radisson Blu am Dammtor der SEACON-Heimathafen. Eine neue Location ist immer ein Wagnis, und so war ich gespannt auf die Meinungen der Teilnehmer. Die fielen am ersten Konferenztag eher verhalten aus. Insbesondere der Ausstellerbereich gefiel nicht auf Anhieb. Dieser schlängelte sich entlang der Konferenzräume und bot wenig Freiraum, weshalb sich schnell ein Gefühl der Enge einstellte. Interessanterweise wandelte sich das Bild am zweiten Konferenztag, als die Teilnehmer einander besser kennengelernt hatten (ein Verdienst der interaktiven Formate, allen voran des Open Space) und außerdem feststellen konnten, dass die Aussteller mehr am Erfahrungsaustausch als am schnellen Abschluss eines Vertrages interessiert waren. Plötzlich hatte die Enge etwas heimeliges und führte dazu, dass man noch besser miteinander ins Gespräch kam. Und so wurde eifrig genetzwerkelt – ein eindeutiges Indiz für eine gelungene Konferenz. Ich führte viele gute Gespräche, verpasste dadurch aber sicherlich viele gute Vorträge. Einige habe ich dann aber doch besucht.

Marc Schachtel berichtete in der ersten Keynote vom agilen Weg am Beispiel der Entwicklung einer App für das Partnersuche-Portal PARSHIP. Viele Erkenntnisse waren nicht neu, wurden aber dank des offenen und ehrlichen Bekenntnisses vom Publikum interessiert aufgenommen und werden hoffentlich den einen oder anderen IT-Leiter in einer vergleichbaren Situation davor bewahren, ähnliche Fehler zu begehen.

Anschließend stellten meine ehemaligen Kollegen Carsten Sahling und Malte Sörensen das agile Vorgehensmodell DSDM Atern vor. Das ist etwas mächtiger als Scrum, aber könnte genau deshalb in größeren Projekten und traditionellen Domänen leichter Anhänger finden. Malte gelang es sehr gut, die Organisationsstruktur seines aktuellen Projekts auf die Rollen und Prinzipien von DSDM Atern abzubilden und damit auch jenen Zuhörern Anschluss zu bieten, die ihre Projekte heute noch traditionell organisiert haben.

Nachmittags war ich dann dran und durfte in der ersten Pecha-Kucha-Session mit Geschäftsprozessen und gesundem Menschenverstand für 6 Minuten und 40 Sekunden in den Ring steigen.

Tag zwei der SEACON begann mit meinem persönlichen Highlight. Wolfgang Wopperer ging der Frage nach, wie sich die Herausforderungen “Disruption” und “Skalierbarkeit” bei Innovationsprojekten zueinander verhalten. Ausgehend von Kleiber’s Law entwickelte er Ideen für organisatorische Rahmen, in denen eine Innovationskultur gedeihen kann. Da Großkonzerne empirischen Untersuchungen zufolge unterproportional innovativ sind, kann man beispielsweise durch Ausgründung kleinerer Einheiten adäquatere Rahmenbedingungen schaffen. Dieser Vortrag hatte alles, was ich an der SEACON mag: (für mich) neue Erkenntnisse und somit ein Blick über den Tellerrand, und trotzdem ein deutlicher Bezug zu meinem beruflichen Alltag (hier gibt’s die Folien).

Anschließend ließen Rolf Dräther und ich den Tausendsassa Heinz von Foerster in einem gelesenen Gespräch zu Wort kommen und diskutierten über dessen Vorstellungen vom Begriff der Selbstorganisation.

Ralf Sigmund begann seinen Vortrag über den Zusammenhang zwischen Architekturen und agilem Vorgehen mit einer Frage, die meiner Meinung nach viel zu selten gestellt wird: warum wollen wir eigentlich agil werden? Gibt es einen guten Grund? Ist der gefunden, dann kann es losgehen. Auf dem Weg sind viele Architekturentscheidungen zu treffen, und auch hier gilt: erst überlegen und Trade-offs abwägen, dann entscheiden. Ein Plädoyer für bewussten Fortschritt in Projekten.

Der zweite und letzte SEACON-Tag endete mit einer weiteren Pecha-Kucha-Session, die ähnlich bunt, informativ und kurzweilig war wie jene am Tag zuvor. Dieses Format findet mittlerweile so viel Zuspruch, dass sich mehrere Teilnehmer fürs nächste Jahr wünschten, dass parallel zum Pecha Kucha keine weitere Session angeboten wird. Mal sehen, was der Fachbeirat aus diesem Wunsch macht. Ich bin gespannt und freue mich schon auf die SEACON 2014.

Ausgehend von den Problemen, die hierarchische Ansätze mit sich bringen, stellten wir die Frage, was Foersters These “Jeder ist ein Manager” bedeutet und was eine Heterarchie ist. Hilft uns das weiter? Was ist dann Selbstorganisation? Und welche Rolle spielt Kommunikation in diesem Kontext, welche Schwierigkeiten können dabei entstehen und wie wirkt sich das hermeneutische Prinzip (“Die Bedeutung einer Aussage entsteht beim Empfänger, nicht beim Sender”) aus? Welche Schlussfolgerungen ziehen wir daraus für die Kommunikation im Unternehmen (Feedback-Schleifen, iterative Kommunikation)? Und wo bei all dem sind dann die Parallelen zu agilen Prinzipien und Werten?

Welche Rolle hat dann der Manager in einer Organisation, wenn doch jeder ein Manager ist?

Als mein Festnetzanschluss streikt, muss ich mich per Mobiltelefon bei meinem Telefonanbieter melden. Der fragt nach dem Status meines NTBA. Auf dem Weg in den Keller bricht die Telefonverbindung ab. Wieder zurück im Wohnzimmer, warte ich auf den Rückruf des Call-Center-Agenten (der meine Rufnummer mit Sicherheit gesehen und vielleicht sogar gespeichert hat) – vergeblich. Also drehe ich erneut ein paar Runden in der Warteschleife, um mit einem anderen Agenten verbunden zu werden, der sich den Minuten zuvor erstellten Vorgang aus der Datenbank laden kann und dort allerlei Informationen findet – nur nicht meine Handynummer – oder hat er diese vielleicht sogar vorliegen, darf mich aber aus Kostengründen nicht anrufen?

Mein neues Mobiltelefon kommt mit einer generischen SIM-Karte und dem Hinweis, dass die Aktivierung der Mobilfunk-Karte automatisch innerhalb von 24 Stunden erfolgt. In dieser Zeit muss das Handy ausgeschaltet sein. Schön und gut – aber ab wann tickt die Zeit? Ein Anruf bei der Hotline schafft Klarheit. Auf meine Frage, warum man diesen Startzeitpunkt nicht auf dem Lieferschein vermerkt habe, bekomme ich zur Antwort: “Ja, ich weiß, das müssten wir mal tun”. Tut aber keiner – vermutlich, weil der Prozess keine Rückkopplung vorsieht.

Aber es geht auch anders. Als ich meinen Skype-Account löschen möchte, erfahre ich, dass das nur über den Online-Support geht. Also starte ich einen Chat mit einer Support-Agentin, die mir die Voraussetzungen zum Löschen eines Accounts mitteilt: E-Mail-Adresse sowie Monat und Jahr, in dem der Account angelegt wurde. Das Jahr weiß ich noch, den Monat nicht mehr. Eine “unscharfe” Antwort (ein Zeitraum von vier Monaten) in Kombination mit einer ausführlichen Begründung wird schließlich akzeptiert. Das Vertrauen, das wir in diesem kurzen Chat aufbauten, war groß genug, um eine ungenaue Antwort zu akzeptieren. Versuchen Sie das mal in einem Customer-Self-Service-Prozess.

Warum beginnt die Automatisierung oft schon dort, wo ich als Kunde mit gesundem Menschenverstand und echtem Problemlösungsbewusstsein besser bedient wäre?

Kein Prozess ist so gut wir ein geschulter und motivierten Kundenbetreuer. Trotzdem scheinen viele Unternehmen eher den vom Geschäftsprozessmanagementsystem ausgespuckten Kennzahlen Glauben zu schenken, anstatt einmal die Geschichten anzuhören, die Mitarbeiter im Call Center tagtäglich erleben. Diese Geschichten handeln von Kunden – und deren Zufriedenheit sollte doch eigentlich das höchste Ziel sein. Solange die Kunden das Attribut “potenziell” tragen, mag das auch noch so sein. Aber kaum haben sie unterschieben, werden sie oft in ein Prozesskorsett gesteckt. Und Prozesse, das weiß man ja, enden oft mit der Verurteilung der Unschuldigen.

Heute war ich beim Girls’ Day von AstraZeneca.

Morgens wurden wir am Eingang abgeholt und in einen Seminarraum gebracht. Dort stellte sich jeder kurz vor. Dann erzählten die beiden Betreuer von den Berufen, die es bei AstraZeneca gibt: FachlageristIn, MechatronikerIn und Industriekauffrau/mann. Sie fragten uns, ob wir schon eine Idee hätten, was wir später einmal werden möchten. Dann kam ein Mann vom Sicherheitsdienst und sprach mit uns über Feuer: wie es entsteht und wie man sich bei einem Brand verhalten sollte. Anschließend gingen wir raus und durften mit einem Feuerlöscher ein kleines Feuer löschen. Danach wurde uns gezeigt, was passiert, wenn man eine Spraydose anzündet. Sie explodiert mit einem lauten Knall! Dann wurde noch gezeigt, warum man brennendes Öl nicht mit Wasser löschen sollte. Ein großer Feuerball würde in die Luft steigen und die ganze Küche abfackeln!

Mittagessen gab es in der großen und schönen Kantine von AstraZeneca. Den ganzen Tag über wurden wir mit Getränken versorgt. Danach wurde uns im Seminarraum erklärt, was AstraZeneca überhaupt macht. Die Firma stellt Medikamente her und verkauft sie anschließend an Apotheken, Krankenhäuser usw. Außerdem forscht sie an neuen Medikamenten. AstraZeneca ist in 100 Ländern vertreten. Der Hauptsitz ist in London, der Hauptforschungssitz ist in Schweden. Gleich nach der Präsentation wurden wir durch das Gebäude und in das Lager geführt. Wir konnten sehen, wie die Roboter im Hochregallager die Kartons einsortieren und wie die Medikamente in die Versandkartons gelangen – nämlich von Hand. Dafür gibt es ein raffiniertes System. Ein Aufkleber auf dem Karton wird gescannt. Daraufhin fährt der Karton auf einem Fließband zu dem Regal mit dem Medikament, das in den Karton soll. Dort steht ein Mitarbeiter und scannt den Karton noch einmal. Daraufhin leuchtet ein kleines Lämpchen grün oder rot. Grün bedeutet, dass sich das Medikament auf der linken Seite des Ganges befindet, rot auf der rechten Seite. Unter dem gesuchten Medikament leuchtet ebenfalls die entsprechende Farbe auf und neben dem Lämpchen steht auf einer Anzeige, wie viele Packungen in den Karton müssen. So geht das immer weiter bis der Karton fertig gepackt ist. Dann fährt er zur Versandstation. Dort wird um den Karton ein lila Band gewickelt, das kennzeichnet, dass der Karton von AstraZeneca ist. Nun wird der Karton verschickt.

Nach der Führung schauten wir noch einen kleinen Film, in dem gezeigt wurde, was die einzelnen Mitarbeiter machen und beachten müssen. Danach füllte jeder Teilnehmer noch einen Feedback-Bogen aus und dann war der Girls’ Day auch schon zu Ende. Ich fand ihn sehr spannend und lehrreich!

Montag, 22. April, 13:45 Uhr: Es herrscht gespannte Stille im Gutenbergsaal 1+2. Erwartungsvoll starren neun Personen in leuchtenden Warnwesten auf die großen Flügeltüren, die sich in diesem Moment öffnen und rund 250 JAX-Teilnehmern Einlass gewähren. Die Gäste sind nicht minder gespannt auf das, was sie in den kommenden 100 Minuten erwartet. Eine furchtlose Reise hatte man ihnen versprochen, und von Veränderung und dem Aufbruch zu neuen Ufern war verheissungsvoll die Rede gewesen. Aber was hat das mit agiler Softwareentwicklung zu tun?

Fearless Journey ist ein Kartenspiel, in dem sich ein Team auf die Reise begibt, um ein großes Ziel zu erreichen. Auf dem nicht immer geradlinigen Weg gilt es, verschiedene Hindernisse aus dem Weg zu räumen, die das Team zuvor selber gefunden und beschrieben hat. Um diese Hindernisse zu überwinden, helfen keine Zaubersprüche, sondern Strategien – und zwar jene, die Linda Rising und Mary Lynn Manns in ihrem Buch “Fearless Change: Patterns for Introducing New Ideas” beschrieben haben. Die Bandbreite der Strategien reicht von “Corridor Politics” (Flurfunk) über “External Validation” (Externe Bestätigung) bis hin zu “Time for Reflection” (Zeit zum Überdenken). Entwickelt wurden diese Strategien, um Veränderung im Unternehmen in Bewegung zu bringen und zu halten.

Was sind die Minimalvoraussetzungen für Veränderung? Ein Standpunkt (Start), eine Vision (Ziel) und der Wille, sich auf den Weg zu machen. Deshalb formulierten die Teilnehmer zunächst ein herausforderndes Ziel, z.B. “wir wollen unser Unternehmen zu einer agilen Organisation entwickeln”. Anschließend wurde der Status Quo niedergeschrieben. Dann durften alle Teammitglieder Gedanken darüber grübeln, welche Hindernisse ihnen auf dem Weg wohl begegnen könnten. Schließlich machten sich alle Teams auf den Weg. Die Hindernisse wurden wie Ereigniskarten gezogen und blockierten immer wieder die Zielerreichung, bis entweder ein Umweg gefunden oder das Hindernis beseitigt wurde. Die Muster (Patterns) aus oben genanntem Buch kamen einzeln oder in beliebiger Kombination zum Einsatz. Stets wurde gemeinsam entschieden, ob die Musterkombination tatsächlich geeignet war, das Problem zu lösen. Und schon ging es weiter, auf mitunter schlängelnden Pfaden dem Ziel entgegen.

Zur Unterstützung der Spieler standen neun erfahrene Fearless Journeywomen und -men bereit, um Fragen zu beantworten, Impulse zu geben, neugierige Blicke über Schultern zu werfen – und sich daran zu erfreuen, dass so viele Menschen gemeinsam spielten. Auch ich gehörte zu diesem Reiseleiter-Team. Ich war von der Größe der Gruppe und der Aufgabe anfangs ein wenig eingeschüchtert und ahnte, dass es vielen Teilnehmern ähnlich ging. Meine Reisebegleiterin Christine beruhigte mich mit dem Hinweis “Je größer die Gruppe, desto leichter kann sich jeder auf dieses Wagnis einlassen, da niemand exponiert dasteht.” Und tatsächlich wich die anfängliche Aufregung an den Tischen sehr schnell einem von Neugier dominierten Teamgeist. Es wurde diskutiert, verhandelt, geplant und vor allem viel gelacht. Meiner Beobachtung nach war die Laune umso besser, je weniger IT-lastig das gesteckte Gruppenziel war. Ein Team hatte sich die hundertprozentige Pünktlichkeit der Bahn zum Ziel gesetzt. Hier war die Stimmung nicht etwa deshalb so gut, weil man sich über die Bahn lustig machte – ganz im Gegenteil: die Teammitglieder hatten aus ihrer Erfahrung als Bahnreisende heraus sehr realistische Hindernisse zusammengetragen. Sie freuten sich darüber, wie gut die Veränderungsmuster auf die problematischen Situationen passten, sobald man deren abstrakter Beschreibung ein wenig Leben einhauchte. Dieser Transfer vom Muster in die Praxis gelang den meisten Teilnehmern sehr gut – Musterschüler im doppelten Wortsinn.

“Kein Spiel ohne Debriefing” stellte Organisator Martin Heider 25 Minuten vor dem Ende der Session fest. Kommunikation, Diskussion und der starke Praxisbezug wurden in der Retrospektive als Stärken des Spiels ausgemacht. Viele Teilnehmer fassten beim Spielen neuen Mut, um im eigenen Unternehmen Veränderung zu wagen, wie der abschließende “Gang ans andere Ufer” (quer durch den Raum) beeindruckend bestätigte. Und so waren schließlich nicht nur die Teilnehmer zufrieden, weil sie ein neues Spiel und neue Strategien für Veränderungsprozesse kennen und anwenden gelernt hatten; auch die Reiseleiter konnten zufrieden auf eine tolle Reise zurückblicken, von der sie noch lange erzählen werden.

Ich möchte mich bei allen Teilnehmern und bei meinem Reiseleiter-Team (Christian Dähn, Rolf Dräther, Christine Neidhardt, Deborah Hartmann Preuss, Norbert Hölsken, Michael Kloss, Ilja Preuss) unter der Leitung von Martin Heider für ein unvergessliches Erlebnis bedanken und wünsche allen noch viele furchtlose Reisen.

Mehr Informationen zum Spiel: fearlessjourney.info

(Fotos: Michael Kloss/Holger Koschek/ein freundlicher JAX-Teilnehmer)

Seit fünfzehn Jahren veranstaltet die Freiwillige Feuerwehr Wedel am Samstag vor Ostern ihr traditionelles Osterfeuer. Neben der Organisation dieser Veranstaltung sind wir Feuerwehrleute auch für den Ausschank an den Getränkeständen zuständig. Da wir keine Gastronomie-Profis sind, dauert es immer einige Zeit, bis sich das Team am Getränkestand aufeinander eingespielt und seine Handgriffe gelernt hat: Bestellungen entgegennehmen, Bier zapfen, Softdrinks einschenken, Getränke ausgeben, kassieren, Pfandbecher zurücknehmen, Pfand auszahlen (oder mit einer neuen Bestellung verrechnen) und Becher spülen. In diesem Jahr haben wir in Anbetracht der niedrigen Temperaturen auch Glühwein ausgeschenkt – wahlweise mit “Schuss”.

Es war interessant zu beobachten und zu erleben, wie wir den Flow gefunden haben.

Arbeitsteilung und Rotation

Schon von Beginn an hatten wir uns für eine arbeitsteilige Aufstellung entschieden: Während zwei Feuerwehrleute an den Zapfhähnen für den Biernachschub sorgten, füllte ein weiterer den Glühwein ab. Die beiden anderen Mitglieder des fünfköpfigen Teams übernahmen den Verkauf: Bestellungen wurden entgegengenommen und an die Bier- und Glühweinverantwortlichen weitergeleitet. Von denen bekamen die Verkäufer die Getränke zugereicht, Softdrinks füllten sie selber ab.

Wer wollte, der konnte durch die verschiedenen Stationen rotieren. Da es nicht jedermanns Sache ist, Bestellungen entgegenzunehmen und die Preise im Kopf zu berechnen (ich gebe zu, dass auch ich das Kopfrechnen erst wieder üben musste), kam es vor, dass einige Kameraden bei ihrer Station blieben.

Prozessoptimierung und Garbage Collection

Es dauerte nicht lange, da wurden erste Optimierungen des Prozesses in die Tat umgesetzt. Beispielsweise schufen wir einen Vorrat an Bechern, die wir mit Rum befüllten. Somit war die Lieferzeit für einen Glühwein mit und ohne Schuss genau gleich lang, weil in beiden Fällen nur noch der Glühwein aufgegossen werden musste. Der Vorrat an Rum-Bechern wurde in den kurzen Pausen aufgefüllt, die sich immer wieder ergaben. Die Kundschaft kam nämlich nicht gleichverteilt, sondern immer stoßweise, was unter anderem davon abhing, welche Musik der DJ gerade spielte.

Die zurückgenommenen Pfandbecher wurden zunächst im Spülbecken gesammelt, bis der Vorrat an frischen Bechern zur Neige ging oder das Spülbecken zu voll wurde. Erst dann baten wir einen weiteren Feuerwehrkameraden zur Hilfe, der das Team temporär verstärkte, um die Becher zu spülen. Unser Konzept gleicht dem der Garbage Collection in einer Java Virtual Machine, die ungenutzte Objekte nicht sofort wegräumt, sondern auf einen geeigneten Zeitpunkt wartet, an dem sich das Aufräumen lohnt und den Betrieb möglichst wenig beeinträchtigt. Die ungeliebte Aufgabe des Becherspülens wurde übrigens ebenfalls im Rotationsprinzip erledigt.

…und dann war er plötzlich da: der Flow!

Ich habe nicht auf die Uhr geschaut (dazu war einfach keine Zeit), aber wir haben ca. eine Stunde gebraucht, um die beschriebenen Verbesserungen im Prozess zum Laufen zu bringen und reibungslos miteinander zu arbeiten. Als ich spürte, dass wir gemeinsam alles im Griff haben, wich eine Anspannung von mir, die ich erst im Nachhinein wahrnahm. Jetzt fand ich endlich die Zeit, um mich besser um die Gäste zu kümmern. Ein Lächeln hier, ein kurzer Schnack dort – kleine verkaufsfördernde Maßnahmen, die zudem den Spaß an der Sache steigerten. Interessanter Weise wurden wir jetzt auch von den Gästen als eingespieltes Team wahrgenommen, wie ich einigen Äußerungen entnehmen durfte.

Auf dem Boden bleiben!

Die größte Gefahr im Flow ist, die Bodenhaftung zu verlieren und sich selbst zu überschätzen. So war es nur eine Frage der Zeit, bis ich mich zum ersten Mal an diesem Abend verrechnete – zu Ungunsten des Gastes, der meinen Irrtum bemerkte und mich freundlich darauf hinwies. Ich entschuldigte mich und war von diesem Moment an zwar immer noch im Flow, aber wieder mit der vollen Konzentration bei der Sache.

Fazit

Was kann man aus dieser kurzen Geschichte an Erkenntnissen für agile Projekte gewinnen?

• Es gibt ihn, den Flow. Ma braucht dafür ein echtes Team, das gerne gemeinsam arbeitet und willens ist, seine Arbeitsweisen zu reflektieren und gegebenenfalls anzupassen.
• Arbeitsteilung ist auch in agilen Projekten erlaubt und sinnvoll, solange man (z.B. durch Rotation oder Pair Programming) dafür sorgt, dass keine Wissensinseln entstehen.
• Es gibt Aufgaben, die man nicht sofort erledigen muss, sondern besser erst einmal ansammelt. Dieses “Garbage Collection”-Muster entspricht im weitesten Sinne dem Konzept der Backlogs (z.B. Product und Impediment Backlog, nicht aber Sprint Backlog), wobei dort natürlich kein Müll gesammelt wird. So findet ein Estimation Meeting üblicherweise nicht regelmäßig statt, sondern nur dann, wenn man sich aus bestimmten Gründen mit der Pflege des Backlogs beschäftigen muss.
• Die positive Stimmung, die der Flow auslöst, spüren auch die Kunden. Sie nehmen das (Entwicklungs-)Team als eingespielte Mannschaft wahr, der sie ihr Vertrauen schenken können.
• Bei aller Euphorie, die der Flow auslösen kann, muss das Team auf dem Boden bleiben und seine Aufgaben weiterhin mit voller Konzentration wahrnehmen.