Iterative Personae

Anfang dieses Monats hatte ich, Ina El Kadhi, das Glück, die “Agile on the Beach”-Konferenz in Falmouth, Cornwall, besuchen zu können: eine absolute Konferenzempfehlung. Großartiges Line-up in idyllischer Umgebung mit charmanter Durchführung (@Judith: nochmals Danke für den Tipp!). 

Einer der vielen hochwertigen Konferenzvorträge war der von Adrian Howard über Iterative Persona: wie kann man Personae in der agilen Entwicklung verankern und sie dabei agil weiterentwickeln?

Dieser Post basiert auf Adrians Vortrag und den anschließenden Diskussionen.

Egal in welcher Branche wir unterwegs sind, wir müssen unsere Kunden kennen. Nur so können wir tatsächlich “customer centric” agieren. Wir funktionieren über Geschichten. Geschichten wecken unser Interesse, wir können sie uns merken und wiedererzählen. Geschichten machen es uns einfacher, uns in Andere hinein zu versetzen. 

Die erste Herausforderung liegt in der Natur von Geschichten begründet. Geschichten sollten interessant sein: Sie werden interessant, wenn Aspekte uns überraschen. Sie entsprechen nicht unseren Erwartungen.  Wir schmücken Geschichten aus, wenn wir sie erzählen. Wir erliegen oft der Versuchung, Schrullen oder Eigenheiten einfach zu erfinden.

Eine Geschichte über “Egon, Finanzberater a.D., mag Excel” wäre für mich persönlich weit weniger attraktiv als eine über “Egon, Finanzberater a.D., kann nicht rechnen und liebt Orchideen”.

Die Annahme "Finanzberater lieben Orchideen" könnte dazu führen, auf einer Finanzberatermesse Orchideenknollen als Marketing-Goodie auszulegen. Einige der Teilnehmer und Teilnehmerinnen würden verwundert gucken.

Begriffe und Beschreibungen, die man verwendet, sind meist aufgeladen mit Bildern, Erwartungen und, im schlimmsten Fall, Vorurteilen. 

“Julia, 29, Single, Marketingleiterin” lässt bei den meisten von uns im Kopf eine völlig andere Person entstehen als “Jutta, 31, alleinerziehende Mutter, Marketingleiterin”. Es ist die Stärke von Personae, dass sie vor unserem geistigen Auge Menschen ins Leben rufen. Gleichzeitig ist es ihre Schwäche.

Zu allen Stichpunkten auf der Beschreibungsliste wabern Bilder und Eigenschaften mit. Diese können gefährlich werden. Sie könnten bei Produktentscheidungen implizit mit berücksichtigt werden.

Nach Adrian Howards Erfahrung sprechen Teams völlig anders über eine Persona, wenn nur Geschlecht, Photo, Name oder Alter geändert wurden.

Adrian schlägt vor, für die Attribute einer Persona eine Kategorisierung vorzunehmen. Hierdurch wir herausgestellt, wie verlässliche diese Attribute sind:

Oder etwas weniger polemisch:

• Guess/Made Up S##t: Das haben wir uns einfach ausgedacht. Es gibt keinerlei Validierung dafür, dass das auf irgendjemanden, den die Persona repräsentieren soll, zutrifft.
• Weak: Es gibt ein paar real existierende Repräsentanten der Persona, von denen wir wissen, dass das auf sie zutrifft.
• Strong: Wir haben Belege dafür, dass das auf die meisten Repräsentanten zutrifft.
• True: Das Attribut ist strong, und wir haben ERFOLGREICHE Produktentscheidungen auf Basis dieses Attributs getroffen. 

Als Agilisten hängen wir das Ganze pro Persona an ein Board. Wir schreiben die Attribute auf Post-Its (oder Karteikarten) und kleben dann die Attributkarten in die entsprechenden Felder.

Bei Produktenscheidungen sollten nur “Strong” oder “True” Attribute berücksichtigt werden. Es hilft in der täglichen Arbeit, die Felder und die Attributkarten, wie im Bild, zu farbkodieren – “Nee, das können wir nicht nehmen, das ist Gelb. Wenn Du’s wirklich nutzen willst, müssen wir das erst mal validieren und gucken, ob’s Grün wird!”

Aber wie komme ich zu einer Persona, und wie entwickle ich eine Persona weiter?

Für wen brauchen wir eigentlich jeweils eine Persona? Eine mögliche Antwort: für jede Stakeholdergruppe:

"Ein Stakeholder an einem Produkt/Projekt ist jemand, der auf das Produkt/Projekt Einfluss nehmen kann oder von ihm betroffen ist."

Das sind übrigens auch die Menschen, die wir in Methoden wie Impact Mapping berücksichtigen. Wenn wir Personae haben, können wir auf validierte Attribute der jeweiligen Stakeholdergruppe zurückgreifen.

Eine Persona muss im Team leben. Sie muss vom Team verstanden werden und es muss Konsens herrschen über das, was eine Persona aussagt. Mit „Team“ ist hier das ganze interdisziplinäre Team gemeint, das an dem Produkt/Projekt arbeitet – von Marketing bis Entwicklung sollten alle im Team vertreten sein. 

Sollte UX-Wissen extern eingekauft werden müssen, so sollte es nur beratend, mentorierend und moderierend eingesetzt werden. Die Verantwortung für die Entwicklung und Pflege einer Persona liegt beim Team. 

Hierbei unterscheidet Adrian drei verschiedene Phasen:

1. Define
2. Refine
3. Realign

Brainstorming im Team, flankiert von UX-Recherche gibt uns erste Hinweise darauf, welche Personae wir benötigen. Weiteres Brainstorming und weitere Recherche führt zum ersten Wurf der einzelnen Personae.

Wichtig in dieser „Define“-Phase ist weniger die Validität der gefundenen Personae-Skizzen als das Etablieren der Teamdiskussionskultur und des gemeinsamen Teamverständnisses über die spezifizierten Personae. 

Es werden über Diskussionen erste Regeldefinitionen für Transitionen zwischen den Attribut-Kategorien Guess <-> Weak <-> Strong <-> True gefunden.

Diese Regeln werden, analog zur „Definition of Done“ bei Entwicklerteams, für alle sichtbar zu den Personae gehängt.

Haben wir eine Persona, so muss sie kontinuierlich gepflegt und weiterentwickelt werden: die „Refine“-Phase. 

Bei iterativ arbeitenden Teams fallen im Rhythmus der Sprints Entscheidungen an. Diese müssen vorbereitet werden. Da die Entscheidungen auch Erkenntnisse aus den Personae der betroffenen Stakeholdergruppen berücksichtigen sollten, bietet es sich an, die Pflege der Personae im Iterationsrhythmus durchzuführen. 

Hierbei sollten zum Beispiel folgende Fragen beantwortet werden:

• Wie valide ist diese Persona-Eigenschaft, auf Basis derer ich ein Feature entwickeln möchte?
• Fehlt mir ein Attribut in meiner Persona, ohne das ich meine Entscheidung nicht treffen kann?

Die notwendige Recherche wird durchgeführt und deren Ergebnisse werden im entsprechenden Persona-Board dokumentiert.

Periodisch sollte das Team einen Schritt zurücktreten und alle Personae und deren Relationen zueinander kritisch hinterfragen. Auch der bis dato gelebte Prozess muss überprüft werden. Wenn nötig, muss er neu ausgerichtet werden – sprich, die „Realign“ Phase sollte periodisch eingeläutet werden.

In dieser Phase werden Fragen adressiert, wie:

• Sollten wir zwei Personae zu einer zusammenführen?
• Oder sollten wir diese eine in zwei unterteilen?
• Ist diese Persona überflüssig? Fehlt uns eine Persona?
• Welche Attribute sind irrelevant für das Produkt/Projekt und welche fehlen?
• Haben sich unsere Transitionsregeln bewährt oder müssen wir sie ändern? 

Nach einer Realign-Phase kann wieder zum Tagesgeschäft der iterativen Refine-Phasen übergegangen werden.

Ich persönlich finde den vorgestellten Ansatz sehr ansprechend. Die Methode verspricht zum einen die Möglichkeit der kontinuierlichen Einbindung von Personae in die iterative agile Entwicklung. Zum anderen erlaubt sie die Validierung einzelner Attribute einer Persona. Bei den „klassischen“ Personae hatte ich so gut wie immer ein flaues Gefühl:

• “Stimmt das überhaupt alles so wirklich?
• Wie aktuell ist das?
• Sind das wirklich die Menschen, über die wir reden sollten?
• Und was davon ist tatsächlich relevant für meine Arbeit?

Adrian Howard erklärte zum Schluss, “Iterative Persona” sei ein “sh..ty name” und er würde versuchen, irgendwann einen Besseren zu finden, “but it will do for now”.

Es gibt noch keine Best Practices für Transitionsregeln und für die Realign-Phase. Wünschenswert wäre es ja, für bestimmte Fragen einen guten Startpunkt zu haben:

• Wann sind die Attributmengen von zwei Personae so ähnlich, dass man darüber nachdenken sollte, diese zwei Personae zu Einer zusammenführen?
• Oder, gibt es eine Faustregel dafür, ab wann ein Attribut als „Strong“ statt als „Weak“ kategorisiert werden sollte?

Iterative Personae lösen die "klassischen" Personae auf. Es gibt an sich keine Geschichten mehr, sondern nur noch Mengen von produktrelevanten Attributen in verschiedenen Validierungsstufen. Vielleicht sind aber für Produkt/Projekt-Entscheidungen Bilder im Kopf weniger hilfreich als validierte Eigenschaften?

• Nächster Artikel: BASTA | Projektkommunikation
• Vorheriger Artikel: Berlin Ops Summit | Scrum ist die Lösung? Oder doch nicht?