Von einer UXlerin, die auszog, Business-Analysten zu treffen: Mein Besuch an der BA & Beyond-Konferenz

Vom 27. März bis zum 29. März fand sie statt, die BA & Beyond-Konferenz in Brüssel und Amsterdam.

Als UX-Enthusiast begebe ich mich also ausserhalb meiner Komfortzone in unsere Schwesterndisziplin der Business-Analyse (BA). Am Vorabend der Konferenz im Konferenzhotel angekommen, habe ich die grosse Freude, bereits die internationalen Redner kennenzulernen. Und wie das gerne so ist, unterhält man sich hauptsächlich über den kulturellen Hintergrund, den man mitbringt. Viele am Tisch haben einen multikulturellen Hintergrund, ich hätte gar nicht realisiert, auch dazu zu gehören ? Mit den überwiegend extrovertierten Personen am Tisch bin ich voller Erwartung auf die Vorträge des nächsten Tages.

Start in die strategische Business-Analyse in Brüssel

Und der Tag beginnt zeitig, denn die Registrierung startet bereits um 8 Uhr. Um 9 Uhr gibt es den Willkommensgruss der Organisatoren und ab 9:30 Uhr sind die ersten Vorträge zu hören.

In der ersten Session geht es um strategische Business-Analyse. Matt Thompson, Frank Lemmens und Adrian Reed präsentieren uns drei Aspekte strategischer Business-Analyse. Matt sucht nach dem Grund hinter dem, was an der Oberfläche passiert und der Verbindung von Cause und Effect. Die Kombination von Modellierung mit Storytelling verwendet Frank, um seine neue Architektur intern zu verkaufen. Und eine wirkliche Obsession, was das Suchen von Problemen und das Darstellen des Problemraums betrifft, um die Desorientierung eines Produktes zu verhindern, stellt Adrian vor. Interessant am Modus auf der Konferenz ist, dass alle drei Redner nacheinander präsentieren, ohne dass das Publikum Fragen stellt. Erst in der gemeinsamen Fragerunde, in der alle drei Redner auf der Bühne stehen, werden sowohl vom Publikum als auch von einem Moderator Fragen gestellt. Zuerst kommt mir das komisch vor, aber ich finde, das Konzept ist aufgegangen. So können alle drei Redner auf gemeinsame Fragen antworten, da ihre Talks thematisch gut zusammenpassen. Der Moderator ist auch prima vorbereitet.

Auf der Suche nach der Definition eines Business-Analysten

In der Kaffeepause nutze ich die Zeit für ein kleines Gespräch mit Lynda Girvan. Was ich nicht wusste ist, dass Lynda so etwas wie ein Popstar in der Business-Analyse-Community ist. Aber es macht einen riesigen Spass, mit ihr zu diskutieren. Sie promotet ihr Buch an der Konferenz und ein paar der Glaubenssätze, die sie formuliert, sind auch die, die ich jeden Tag gebetsmühlenartig wiederhole: Agil ist ein Mindset, kein Methodenkoffer. Wenn ihr eine neue tolle Methode lernt («all these fancy new methods»), vergesst die Bewährten nicht. Macht die verdammte Analysearbeit! Nehmt die Anforderungen vom Business nicht einfach an. Zwischen dem Hören einer Anforderung und dem Umsetzen derselben muss noch was passieren, genau das ist Analysearbeit!

Als offensichtlicher Exot auf der Konferenz, traue ich mich nun die einfachsten Fragen der Welt zu stellen. Einfache Frage Nummer eins:  Ist Business-Analyse und Requirements Engineering dasselbe? Wer sich das schon immer gefragt hat, hier die wunderbare Antwort dieser tollen Redner aus der Business-Analyse-Community: Nein! Requirements Engineering ist nur ein Teil der Business-Analyse. Wer sich so sehr mit dem Problemraum des Kunden beschäftigt, und damit ist hier das Unternehmen gemeint, das das Produkt anbietet, kann nicht einfach Requirements Engineer sein, wird mir vermittelt. Stakeholder-Netzwerke auszuleuchten und ihre unterschiedlichen Bedürfnisse explizit zu machen, die Konflikte klarzumachen und darzustellen, ist kritischer Erfolgsfaktor für Adrian Reed. Wir können nicht Produkte mit unterschiedlichen Zielen bauen. Sonnenklar! Unser (evux) Ansatz ist die Produktvision dafür, Adrians Vorschlag ist das Rich Picture. Diese Abwandlung des Konzeptdiagramms ohne spezifische Syntax zur Visualisierung der Stakeholder-Bedürfnisse hinsichtlich des Produkts über Prozesse und Abläufe hinweg erscheint mir ein sehr hilfreiches Tool. Die einzige Ebene, die ich vermisse, ist die Persona-Ebene, also das Interesse der Primärpersona im Unterschied zu anderen Endkunden. Da wir hier aber nicht syntaktisch oder semantisch limitiert sind, lässt sich das einfach miteinander kombinieren.

Ziemlich begeistert war ich davon, dass faktisch die gesamte Community dieses Tool kannte. Als Adrian das Publikum fragte, war es, als hätte ich in der UX-Community gefragt, ob die Leute Nutzertests kennen. Allerdings habe ich in Projekten bei Kunden noch nie ein Rich Picture zu sehen bekommen. Wie vielen Produkten würde das guttun? Adrians Erinnerung an die Formulierung sauberer Problem Statements basierend auf Stützfragen finde ich genauso wertvoll:

• Welches Problem sollen/wollen/müssen wir lösen?
• Wen betrifft das Problem (Stakeholder)?
• Warum ist das wichtig?
• Was würde eine erfolgreiche Lösung bringen und wie merken wir, dass sie erfolgreich ist?

Ergänzen würde ich hier lediglich die Frage, ob das Problem wirklich ein Problem ist und woher wir das wissen. ?

Einfache Frage Nummer 2 stelle ich in der Kaffeepause: Wie arbeitet ihr mit UXlern zusammen? Ha! Die Antwort war hübsch. «Am liebsten machen wir das selbst.» Getreu einem ordentlichen Critical Thinking frage ich: «Warum?» «Ja, die braucht man ja erst gegen Ende und dann rollen die immer alles noch mal auf.» «Habt ihr euch gefragt, warum die alles noch mal aufrollen?….» Ihr wisst, wohin das Gespräch führte.

Agil ist auch in Brüssel ein «heisses» Thema

Nach der Kaffeepause besuche ich den Track «Agile beyond the hype». Schon mal gut zu sehen, dass auch Business-Analysten sich herausgefordert fühlen mit den agilen Konzepten. Auch Business-Analysten haben einen ganzheitlichen Anspruch wie UXler und tun sich in der Praxis schwer, in agile Vorgehensweisen zu passen. Bis der Groschen fällt, vergehen einige Jahre an Berufserfahrung, da waren sich meine Gesprächspartner auch einig. Insgesamt lassen sich entdeckte Schwierigkeiten gerne auf das Nichtbeachten vom agilen Manifest zurückführen. Jan Legtenberg berichtet von örtlich voneinander getrennten Teammitgliedern oder eng zusammenarbeitenden Teams, die verteilt über das Gebäude agieren und dann zusammengelegt werden. Plötzlich funktioniert viel mehr – oh Wunder! Die unterliegenden Logiken von SCRUM-Methoden, von denen Pieter Hens redet, sind allerdings sehr flach formuliert, wenig psychologisches Hintergrundwissen und es bleibt das Gefühl bei mir zurück, dass die Phänomene in z.B. Retrospektiven viel einfacher zu erklären wären. Aus meiner Perspektive bleibt Scrum eine Projektmanagementmethode, nichts weiter. Alle Techniken, die ich darin verwende, genügen sinnvollen psychologischen Prinzipien, die wie in anderen Workshopmethoden gewählt werden sollten, um Biases und Gruppenphänomenen vorzubeugen. Vielleicht muss ich diesen Talk aber anders bewerten. Da Business-Analysten in ihrem Wissensaufbau nicht so stark von der Psychologie beeinflusst werden wie wir UXler, ist die Ebene vielleicht okay. Aber zu erkennen, dass es keine Zauberei ist, in einer Retrospektive allen erstmal den Raum zu geben, ihre eigenen Gedanken auf ein Post-It zu schreiben, bevor alles zusammengetragen wird, dass die eigenen Gedanken nicht sterben, finde ich nicht so schwierig. Andernfalls – und das lässt sich ja leicht in Meetings und Workshops erkennen, können sich Teilnehmer zurücklehnen, wenn ein Monologist redet und einfach den Mund halten. Die soziale Hängematte (Social Loafing) wartet auf ein gemütliches Schläfchen…

Zeit für (Selbst-)reflexion: Wenn Business-Analysten so zu Hauf vorhanden wären…

Nach dieser Session folgt die Mittagspause. Ich bin ein bisschen froh darüber. Während nämlich meine beiden Gehirnhälften irgendwie streiten, ob sie sich aufregen über die Realität, die sie sonst erleben oder weiter neugierig an dieser Konferenz sein wollen, habe ich doch tatsächlich ein bisschen Hunger… Nach der Mittagspause sind die Sponsoren-Tracks. Ehrlich gesagt, verstehe ich nicht ganz, was das soll. Möglicherweise hätten mich Unternehmen aus der Schweiz interessiert, aber irgendwie fühle ich mich nicht angezogen. Ich nutze die Stunde, um ein bisschen nachzudenken und verlasse das Konferenzhotel. Bei meinem Spaziergang überlege ich, ob ich denn wirklich jemals einen «echten» BA getroffen habe. Ja, der eine oder andere würde mir einfallen, aber das, was die Konferenz mir zeigt, was ein Business-Analyst eigentlich ist oder sein sollte im Selbstverständnis der Fachcommunity? Schwierig. Die Gespräche hier sind toll, die Vorträge sind gut, der Tenor fantastisch. Business-Analysten, wo seid ihr? Wenn es von diesen stereotypen Business-Analysten mehr gäbe, bräuchte es ehrlich gesagt nicht so viele UX-Leute. Dann könnten wir uns auch um die Dinge viel mehr kümmern, mit denen wir uns auch so richtig gut auskennen wie z.B. User Research, Strategien für Primärpersona-Sekundärpersona-Nutzung oder tatsächlich Interaktionsdesign. Um bspw. mehrere Lösungsvarianten auszuarbeiten, bleibt häufig keine Zeit, weil wir sehr viel von der Analysearbeit mit übernehmen. Oft bleibt uns keine andere Wahl, als mit einem Interaktionsdesign fire and forget loszulegen. Und dieser Quatsch mit «fail fast and fail often», das muss auch mal aufhören! Entweder wir machen uns mal klar, dass wir am Anfang eines Konzepts experimentieren und dazu lernen wollen, was überhaupt gar nichts mit scheitern zu tun hat, oder wir lassen das. Dann würde in den ersten Prototypen auch nicht jeder Mist drin sein, von dem wir schon selbst mit Anlauf wissen, dass das eben Mist ist. Das ist leider etwas, was ich doch einmal zu oft gehört habe in den Vorträgen. Wer hat denn Lust zu scheitern? Was soll denn das? Wir wollen doch gar nicht scheitern. Manchmal haben wir aber einfach noch offene Fragen und dann müssen wir sie eben sichtbar machen.

Fachexpertenfalle: Fehlverhalten in Projekten, das können wir UXler auch

Im letzten Track vor der Keynote schaue ich mir noch die Präsentationen zu Soft Skills an. Und wie vermutet, wird Christina Lovelock mit «When BAs go BAD» das Publikum hervorragend treffen. Sie hält den Fachexperten charmant den Spiegel vor. Pedanten, Mavericks, Überlegene, «Ich bin hier nur BA», «Ich habs schon immer gesagt», «Es gibt uns und die anderen», «Alles ist schlecht», Kurzsichtigkeit – allesamt Verhaltensmuster oder Einstellungen, die die Arbeit eines Business-Analysten gemäss Christina verschlechtern. Im Vorfeld der Konferenz hatte Christina eine Befragung gemacht, ob man denn schlechte Verhaltensweisen bei Fachkollegen kennt und inwiefern man das bei sich selbst beobachtet. Und klar lautet das Ergebnis: Selbst ist man davon befreit, aber die anderen… ? An die eigene Nase zu fassen mag besonders schwierig sein, einerseits weil die Fähigkeit zur Selbstreflexion nicht die am stärksten ausgeprägte Kompetenz von uns Menschen ist (meines Erachtens) und andererseits weil es ja auch viel einfacher ist, die Unzulänglichkeiten des Gegenübers anzuzeigen. Christina trifft mit dem Thema aber ins Schwarze und schlägt Verhaltensänderungen, Pendants zu den Fehlverhaltensweisen vor, bei denen auch die Reflexion der eigenen Arbeit im Licht der eigenen beruflichen Karriere vorkommt. Besonders das macht doch nachdenklich. Wenn mehr Fachexperten sich selbst regelmässig fragen würden, ob sie stolz auf das sind, was sie hervorgebracht haben, würden sie sich wohl auch öfter fragen, warum vielleicht nicht… Nach den Vorträgen der Session erhalten wir noch eine Karte, auf deren Seite A die negativen Muster, auf Seite B die positiven Muster abgebildet sind. Und eines ist ja wohl klar: das Ganze lässt sich 1:1 auf UXler abbilden und vermutlich auf jeden Fachexperten. Ich gratuliere Christina zu ihrem lebendigen Talk und teile meine Gedanken dazu mit ihr. Dann begeben wir uns langsam wieder in den Vortragssaal und bereiten uns auf die Keynote von Lynda Girvan vor.

UX als wichtige Nebenkompetenz

Lynda auf der grossen Bühne: An der Befüllung des Saals lässt sich leicht sehen, dass es eine gute Idee war, die Keynote an das Ende des Tages zu legen. Alle haben durchgehalten, wenngleich ich rechte Ermüdung spüre. Lyndas Energie scheint jedoch noch voll da zu sein ? «The agile Business Analyst» – ihr Vortrag basiert auf Inhalten ihres Buches mit Co-Autorin Debra Paul (https://www.amazon.com/Agile-Business-Analysis-Debra-Girvan/dp/1780173229). Lynda hebt hervor, dass sie im Gegensatz zu vielen Autoren eben nicht hauptberuflich Autorin, sondern tatsächlich auf Projekten tätig ist. Ein wichtiger Glaubwürdigkeitspunkt. Ich merke das an mir selbst, dass ich Trainern, Ausbildern, auch Professoren sogenannte Praxisvorträge nicht immer wirklich abnehme, wenn ich darüber nachdenke, wie deren Inhalte in die Realität umgesetzt werden sollen. Zwei Folien von Lyndas Vortrag sind mir besonders geblieben. Zum einen thematisiert sie «Verschwendung», was ist denn das in IT-Projekten? Unter anderem «Warten» und das «Produzieren auf Halde». Zwei Phänomene, die ich doch nur allzu oft sehe und bisweilen tappe ich selbst in die Falle… Und auch hier sticht es einfach plakativ ins Auge: wir UXler sind mit Business-Analysten in einer Wertschöpfungskette. Wenn wir durch monströse Prototypen und ausdetaillierte Designs schon zu Beginn eines Vorhabens, das einen MMP (minimal marketable product) erreichen soll, schon mal eine Menge Informationen auf Halde produzieren, braucht das Projektteam viel Zeit, um Denkfehler, weil man das Problem jetzt besser versteht, wieder aus den Köpfen zu bringen. UX hat einen ganzheitlichen Anspruch. Den müssen wir loslassen, vor allem im agilen Kontext, er ist Augenwischerei. Was nicht fertig ist, sollte nicht fertig aussehen.

Mein Aha-Moment ist dann aber vermutlich an einem anderen Ort als das des restlichen Publikums. Und zwar als Lynda ihre Slide des T-shaped Business Analyst auflegt. Zählen wir in der Vertikalen, also den Kerndisziplinen durch, gibt es drei Aufgabenbereiche, die sich um die Weiterentwicklung von Anforderungen drehen, also um das Verstehen des Problems, und nur zwei um die Modellierung, also die Lösung zu erklären. Hm. Ist das Zufall? Ich interpretiere frei: Business-Analysten sollen sich (mindestens) genauso viel um das Problem, wie um die Lösung kümmern und den Kontext ansehen, in dem die Lösung entsteht. Während der UXler nach dem Nutzungskontext forscht, sucht der BA nach dem Systemkontext und dem Kontext innerhalb des Unternehmens. (Ich werde an Adrians Vortrag erinnert, in dem er das Rich Picture thematisierte.) In der Horizontalen finden wir dann das Schlüsselwort, auf das ich höre ?: User Experience. Ja, wär doch gut, wenn wir mit Business-Analysten einen gemeinsamen Wortschatz haben, sie Prototyp von Mock-up unterscheiden können, Wireframes von Designstudien, einen Usability Test von einem Contextual Inquiry usw. Da Business-Analysten vielfach «Story-Owner» sind, ist es wichtig, dass sie in der Lage sind, Design- und Konzeptarbeiten zu koordinieren und fachanalytisch zu begleiten. Das allerdings muss nicht dazu ausarten, dass sie ganze Konzepte selbst machen. Dann bleiben Analyse oder Modellierung auf der Strecke. Unsere Schwierigkeit als UXler ist da aber vielfach, dass es so einfach aussieht, was wir da machen. Bringen wir jungen, aufstrebenden BAs die UX-Grundvokabeln bei, besteht die Gefahr, dass Ergebnisse zuerst schlechter werden, bevor sie besser werden. Dort schlägt sie dann zu, die einzige Sache, die wir von niemandem sonst lernen können: die eigene Erfahrung. Deshalb hoffe ich immer, dass neben Ausbildungen auch konkrete Projekte und Vorhaben mit den besetzen Fachkompetenzen da sind, um Ausbildung im Kontext zu reflektieren.

Nach Lyndas Referat bin ich, aufgepumpt mit aufgefrischtem agilen Mindset, der Überzeugung, dass es bald von mir den Vortrag «The agile user experience specialist» geben wird und ich bin ein bisschen traurig, dass ich direkt auf den Zug nach Amsterdam muss. Dort ist ja morgen der zweite Konferenztag und schliesslich auch mein Vortrag mit meinen Ideen, was da in das User-Experience-Kästchen von Business-Analysten hinein sollte.

Zweiter Konferenztag in Amsterdam, Projektberichte und spannende Workshopformate erwarten mich

Der Startschuss in Amsterdam ist wie in Brüssel. Um 8 Uhr Kaffee und 9 Uhr Beginn. Den sehr persönlichen Willkommensgruss übernimmt eine Mitarbeiterin von Le Blanc Advies, einem Sponsor der Konferenz. Sie erklärt ihren Weg vom Prozessdesigner zum Business-Analysten. Interessant, wie sich der Geist öffnet, wenn man eine neue Perspektive einnimmt. Ich hoffe in diesem Moment sehr, dass Designer sich genauso fühlen, wenn sie in das Feld der User Experience kommen…

Von ad-hoc-Wissensgemeinschaften zur Fachcommunity im Unternehmen

Der erste Track beginnt unter dem Motto «building your BA community» und zwei sehr ambitionierten Damen, die ihre Reise zu einem geregelteren Einstieg in die BA-Tätigkeiten ihres Unternehmens vorstellen. Das Unternehmen war innerhalb weniger Jahre so stark gewachsen, dass sie von «gar keine Ahnung, wozu man Business Analyse braucht» zu einem 50-Personen-starken Business-Analyse-Department geworden sind. Aktivitäten waren ad hoc, wenig standardisiert und es war nicht klar, was das Unternehmen von Business-Analysten erwartet und was es darunter verkauft. Maja Golubic und Mateja Blazevic sind sehr authentisch und wenn auch ihre Arbeit noch am Anfang steht, haben sie bereits einiges erreicht – unter anderem Austausch unter den BAs. Später am Tag diskutiere ich mit ihnen über die BA-Community in ihrem Land Kroatien. Offenbar gibt es dort nicht so richtig Events und Konferenzen. Ich frage, ob es denn so etwas in Deutschland oder so gäbe, weil ich mich ja nicht so auskenne. Meine Gesprächspartner hier sind sich einig, dass das nicht so recht der Fall ist. Mein gegoogle bringt mir da tatsächlich keine weiteren Treffer, aber ich habe auch nicht viel Zeit investiert. Trotzdem schien mir die Konferenz auch sehr UK-lastig.

Nach dem Einstieg der toughen Kroatinnen folgt Tom Colpaert, der sich einem sehr anspruchsvollen Thema gewidmet hat und über Wissenstransfer spricht. Viele von uns kennen das auch: «Hey, hier ist ein Projekt. Werde Experte dafür und das in 2 Stunden!» ? Das ist oft eher eine Herkulesaufgabe. Aber auch hier gibt es systematische Ansätze, die das Ganze erleichtern. Die Fragen, die man nach einander beantwortet, lauten:

• Wer soll das Wissen erhalten? (Einzelperson vs. Gruppe)
• Welches Wissen wird gebraucht? (auch organisatorisches Wissen, Wissen über Stakeholder)
• Wo ist das Wissen enthalten? (meistens Menschen)
• Welches Wissen fehlt gänzlich?
• Welchen Aufwand haben wir? (Tom nennt eine Menge Bewertungsfaktoren wie Verfügbarkeit der Wissensträger, Beeinträchtigung anderer Aktivitäten etc.)
• Welche Transfermethode ist die richtige (Sharing Session, Lesen, Testfälle, Reverse Engineering etc.)
• Wie genau gehen wir vor? (Zeitplan – und hier: treat it like a project!)

Nach dem Talk von Tom fühle ich mich sehr wohl. Jedes Problem ist beherrschbar, wenn man sich einen Plan macht, der auf den einfachen Fragen beruht: wo bin ich jetzt, wo will ich hin, warum will ich das und wie genau sind die kleinen Schritte zwischen heute und später.

Hier in Amsterdam ist der Konferenzmodus anders als in Brüssel. Nach den Talks werden direkt Fragen gestellt und am Ende der Session folgt ein Workshop-Teil. Wir starten nach der ersten Session mit einem World Café. Die Herausforderung ist ein bisschen, dass es doch einer rechten Menge an Teilnehmern unangenehm ist, Englisch zu sprechen. Aber das lässt sich auch überwinden. Das World Café an sich ist nicht so spannend für mich, aber es ist erfrischend, mal wieder andere Moderatoren am Werk zu sehen.

In der Pause im Anschluss komme ich ins Gespräch mit den beiden Kroatinnen und wieder mit Mitarbeitern von Le Blanc Advies. Von Joost Gordijn, auch von Le Blanc Advies, konnte man an dem Tag lernen, wie sich ein Sponsor an einer Konferenz auch verhalten könnte. Er hat jeden Redner persönlich begrüsst, hat sich bedankt, dass man einen Beitrag leistet und sich als ein toller Gastgeber verhalten. Zudem haben wir zusammen viel gelacht. Wenn das mal nicht auch ein wichtiger Punkt ist bei aller Ernsthaftigkeit, die wir beim Austauschen von Wissen und Erfahrung an den Tag legen. ?

Enabling Innovation: Klar, mit UX im Herzen

Die Folgesession steht unter dem Titel «enabling innovation» und mir gehört der zweite Talk. Den Start macht jedoch Antonio González Sanchis. Zugegebenermassen schneide ich nicht ganz so viel mit in dem Vortrag, weil meine Gedanken um meine eigenen Wortfindungsprobleme kreisen. Ob man es glaubt oder nicht, ich freue mich immer auf meine Talks, nervös bin ich aber trotzdem und dann hilft nur starker Fokus und der blendet meine Umwelt nahezu aus… Was ich aber behalten habe, ist dass Antonio ein bisschen aufräumt mit Methoden wie Design Thinking und Agile Inception. Mein persönliches Problem bleibt: Seit Jahrzehnten drehen wir uns um die erste oder frühen Phasen der Ideenfindung, angefangen mit Osborn 1953. Die Variablen der Anschlussfähigkeit «guter» Ideen an die übliche Umsetzung in den Organisationen werden ausgeblendet. Der Garant für langsames Scheitern (als Gegensatz zum gezielten Experimentieren).

Nun bin ich am drannsten. In den mir zur Verfügung stehenden Minuten versuche ich zu erklären, wie – aus meiner Perspektive – Business-Analysten ihren Methodenkoffer pimpen können, um wolkige Diskussionen zu beenden und in Prototypen zu zeigen, welche Konsequenzen besprochene Festlegungen haben. Interessant an der Geschichte war, dass wir bei evux im Vorhinein Annahmen getroffen haben, welche Folie die Teilnehmer wohl fotografieren werden und dachten, es wäre der Ablaufplan, der die Vorarbeit zur Storymap darstellt. Aber es war dann doch die Definition, was UX nicht ist – und was es ist. Hm, wir sind also noch nicht bei einem grundlegenden Wissensstand?

Ideen challengen mit «Ritual Dissent»

Nach den zwei Talks inklusive meinem folgte wieder eine Workshopmethodentestrunde, diesmal für «Ritual Dissent». Eine absolut interessante Möglichkeit, das Reflektieren über das eigene Verhalten und das Entwickeln von Lösungsansätzen aus der eigenen Erkenntnis heraus zu stimulieren. Dabei bildeten wir in der Kleingruppe ein Team aus Coaches. Ein Gast am Tisch (kam aus einer anderen Gruppe) stellte sein Problem vor. Das war nur ein Satz, z.B. «Wenn ich überzeugt bin, es besser zu wissen, dann mache ich die Arbeit am liebsten allein.» Unsere Aufgabe als Coach-Team war es Fragen zu stellen, die offen und nicht suggestiv sind, um das Problem weiter zu untersuchen. Dabei sitzt uns der Problemgeber mit dem Rücken zugewandt. Er oder Sie durfte nicht antworten. Wir stellten also Fragen wie «Was denkt dein Team darüber, wenn du die Arbeit allein erledigst?», «Was, wenn du mal falsch liegst?», «Wenn du einen Aspekt während deines Alleingang findest, den du nicht so gut beherrschst, was machst du dann?», «Wenn ein Stakeholder wissen will, wie der Stand ist, und du bist nicht da, was passiert dann?», «Was ist, wenn du krank wirst?» … an den anderen Tischen wurden andere Problemstellungen behandelt. Interessant dabei war besonders, was mit den Problemgebern passierte. Sie wurden sehr nachdenklich. Und wirklich alle machten sich Notizen und das ohne, dass sie dazu aufgefordert wurden. Mir schoss sofort in den Kopf, dass wir so unsere Konzepte und Designs challengen sollten. «Kill your own darlings», darf ich meinen Kollegen Stefan Wanner hier zitieren. Das ist aber oft gar nicht so einfach – mit dieser Vorgehensweise kann man ohne Verletzungen und Persönlichkeitsbezüge, die gern auch der Empfänger konstruiert, ohne dass sie der Sender wirklich beabsichtigte, umfassendes Feedback sammeln. Ich denke, das lohnt sich auszuprobieren.

«UX ist übrigens die Zukunft»

Jetzt bin ich aber geschafft, später Lunch! Einiges nach 13 Uhr – für jemanden, der in der Regel 11:30 Uhr zum Mittag aufbricht, ist das eine Tortour. Aber eigentlich auch nicht schlimm ?. Am Nachmittag sollen eine Session mit einem Workshopteil folgen und die abschliessende Keynote. Schade ist hier, dass einige Redner nicht länger an der Konferenz bleiben als ihr Talk dauert. Das ist wirklich ärgerlich für Teilnehmende wie mich, die gern mal noch was nachfragen (ätzend die Frau). Nun ja, die Nachmittagssession ist dann auch nicht mehr ganz so gut, wie die bisherige Zeit in Brüssel und Amsterdam. Vielleicht liegts auch an mir, aber die beiden Talks und auch der Workshopteil ziehen meine Neugier nicht mehr so recht. Die Keynote allerdings hat wieder ein kleines Highlight für mein UX-Herzchen. Damien Braekman stellt «Agile Business Cases und Beyond» vor mit seinem eigenen Zugang zu skalierenden agilen Organisationsformen. Es ist spürbar, dass die Praxis seine Wahrnehmung von SAFe und Co. gefeilt haben. Er zeigt Fachkompetenz im agilen Kontext auf und tadaa: UX ist dabei. Als er in die Runde fragt, ob UXler anwesend sind, dachte ich zwar nicht, dass sich alle melden. Aber ich hatte gedacht, dass sich wenigstens so ¼ meldet. Pustekuchen, meine Hand war die einzige, die sich voller Enthusiasmus dem Himmel entgegenstreckte. Nun, er sah betroffen zum Boden und ergänzte: UX ist übrigens die Zukunft. Bäm! Denke ich also zurück an das T-Shape-Modell eines Business-Analysten, das Lynda am Vortag präsentierte, wird das die Nebenkompetenz sein, die Business-Analysten lernen werden. Die Fachcommunity hat zumindest die Notwendigkeit erkannt. Das sollte, so will ich hoffen, auch dafür sorgen, dass echte UX-Experten einfacher erkennbar werden.

Wie fühlt sich dein agiles Projekt an?

Am Abend ist es Zeit für meine letzte einfache Frage: «Wir reden viel über agile Vorgehensweisen. Wie empfindet ihr sie selbst als Teil von agilen Projekten oder Organisationen?» Die Antwortenbandbreite ist wenig überraschend, aber unterstreicht meine Wahrnehmung. Die Antworten reichen von: «Hab noch nie ein erfolgreiches agiles Projekt gesehen.» bis «Es fühlte sich wie eine Befreiung an.» Was ich – natürlich beeinflusst durch meine eigene Einstellung – zwischen den Zeilen höre, ist die gemeinsame Überzeugung, dass eine Frage essenziell bleibt, und zwar egal wo und wie Software entwickelt wird: Warum? Warum soll das so sein, warum will der Stakeholder das, warum haben wir das schon immer so gemacht, warum machen wir es anders?

Die Konferenz endet so mit einem vollen Kopf und natürlich noch ein bisschen Sightseeing in Amsterdam bei schönstem Wetter. Für mich waren die Tage super und der Ausflug in die Schwesterndisziplin hat sich sehr gelohnt.