Die Retrospektive: Maßnahmen einfach tracken

Donnerstagnachmittag, Retrospektive bei einem Automotive-Kunden. Der Gong schlägt, die Timebox ist vorbei. Ich blicke überrascht auf die Resultate: Viele Vorschläge, aber keine wirklich konkrete Maßnahme. Vor allem keine, die man in einem Sprint umsetzen könnte.
Was nun? Klassische Frage: Halte ich die Timebox? Nach dem Prinzip: „Schade, schön wäre es gewesen. Learning fürs nächste Mal.“ Oder fokussiere ich mich auf den Zweck des Meetings: Wir wollen unseren Prozess verbessern. Ich entscheide mich für den Zweck und gebe uns noch einmal 10 Minuten.
10 Minuten später.
Nachdem wir kurz in eine offene Diskussion zurückgefallen sind, haben wir zwei konkrete Maßnahmen abgeleitet. Ich lasse das Meeting abschließend bewerten und beende es. So weit so gut, das Meeting war erfolgreich. Wie geht es nun weiter?

Leichen vergraben?

Ich habe mir vorgenommen, alles gut zu dokumentieren. Auch wenn das Fotoprotokoll wahrscheinlich eine Leiche im SharePoint bleibt. Was mich eher beschäftigt ist: „Was waren eigentlich die Maßnahmen der Retrospektive einen Sprint zuvor?“ Ich kann mich nicht daran erinnern und noch schlimmer, eine Abfrage hat es auch nicht gegeben. Das muss besser werden, denke ich mir. Diesmal tracke ich die Maßnahmen effektiv.

Noch ein Board?

Ich dachte erst an Continuous Improvement Board (CIB). Klasse Idee, oder? Ich verhandle mit mir selbst: „Viel Platz für viele Maßnahmen. Werden die auch alle umgesetzt in einem Sprint? Naja vielleicht brauchen sie ja mehrere Sprints. Aber dann sind die Maßnahmen einfach nicht konkret genug. Ein weiteres Problem beim CIB: Es ist ein weiteres Artefakt. Ich hänge es gleich neben die wenig beachtete Definition of Ready und die kaum benutzte „Waste-Wall“.

Oder einfach nur ein Task?

Die besten Lösungen sind die einfachsten. In einem früheren Team hatte ich am Taskboard eine eigene Swimlane mit dem Namen „Kaizen“. Das war gut, aber ich suche die Herausforderung: Geht es noch einfacher? Ohne Verlust von Effektivität? Ich entscheide mich dafür, Tasks zu erstellen. Simpel, nachvollziehbar und transparent. Weiterer Vorteil: Die Maßnahmen werden nun täglich im Daily mitverfolgt, und zwar instinktiv.
Mein Learning: Die einfache Lösung ist oft weniger intuitiv, aber durchdachter als die komplexe.

Visualisierung in Projekten: Braucht Skalierung Tools?

“Big Visible Charts” war einmal das Motto – Scrum-Teams wollten schnell ihre Informationen an jene mitteilen, die daran vorbeigehen. Ein wundervolles Beispiel für diese Variante der Informationsverbreitung findet sich hier. Die Idee war es, physisch und haptisch, schnell und ohne viel Aufwand Teams zu ermöglichen, effektiver zu arbeiten.
Dann kamen die Leute, die unbedingt die große, allumfassende Visualisierung über alle Projekte haben wollten. Sie setzen immer noch Entwickeln mit Produktion gleich und wollten per Mouse Click haben, was bis dato kein MS Projekt Ghantt-Chart konnte: Tagesaktuelle, verlässliche und korrekte Zahlen über den Entwicklungsfortschritt liefern. Sprich: Reporting bis zum Exzess.
Findige und geniale Entwickler wie zum Beispiel die Jungs von Atlassian bauten coole Tools wie Jira, Greenhopper, und einige andere entwarfen die wirklich abgefahrenen Lösungen wie Trello, VerisonOne, Mingle und wie sie alle heißen, damit sie die geforderten Informationen möglichst schnell und einfach liefern konnten.
Und was passiert jetzt: Es gibt Software-Entwickler, die ihr Geld damit verdienen, z.B. JIRA für Kunden zu konfigurieren, die Workflows anzupassen, und aus der simplen Idee von drei Spalten – TODO, INPRG, DONE – wochenlange Entwicklungsprojekte zu machen. Das ist zwar eine tolle Einnahmequelle und wir als Scrum Consulting Firma werden vielleicht sogar schwach und machen das bald auch – aber das war nicht der Sinn und die Idee hinter alldem. Was wir wollten, war ganz einfach: Wissensarbeit sichtbar machen, damit man darüber sprechen kann. Mehr nicht. Damit ein Teammitglied dem anderen helfen kann. Damit klar wird, wo es noch Lücken gibt und wo man sofort eingreifen kann.
Die Entwicklung geht aber leider in die – meines Erachtens – falsche Richtung. Scrum Entwicklungsteams werden automatisiert dazu gezwungen, über jede Story und jede Zeile Code Rechenschaft abzulegen. Ihre  Chefs, leider oft auch die Product Owner, müssen das nicht. Warum eigentlich? Wieso wird von den Entwicklern diese Transparenz erwartet, nicht aber von denjenigen, die die Ansagen machen?
Meine klare Vermutung: Es würde zu deutlich zeigen, dass dort gar nichts produziert wird. Dort wird keine Leistung, keine Wertschöpfung erbracht. Erklären Sie doch einmal der nächsthöheren Ebene, was Sie den ganzen Tag in den 6 Meetings zu je 90 Minuten und in den 10 Telefonaten dazwischen produziert haben.
Wir haben in unserem Unternehmen die Beweiskette, den Nachweis, dass etwas passiert, umgekehrt. Ich muss klar darlegen, was ich tue. Ich führe ein Backlog, das sich alle in einem Confluence Wiki ansehen können. Dort stehen alle Aktivitäten (fast alle – ich vergesse auch mal was), die ich an einem Tag ausführe, und ich lege die Ziele ebenfalls öffentlich ab. Nicht weil ich sie vorgeben will, sondern weil wir sie nur dann diskutieren können, wenn wir sie immer wieder sehen. Man kann nur über etwas reden, das man offenlegt.
Und wisst ihr, was passiert ist? Es hat Schule gemacht. Jeder legt nun das, was er tut, ganz von selbst offen. Wir haben noch kein Taskboard – noch nutzen wir ein Wiki. Vielleicht nutzen wir auch bald mal JIRA intern 😉  – als verteiltes, skaliertes und multikultures Team. Aber nicht, damit mir meine Kollegen reporten, sondern damit sichtbar wird, wer gerade woran arbeitet und sich die Kollegen gegenseitig helfen können – egal, wo sie gerade sitzen. Internationalisierung, das remote Arbeiten und das ständige mobil Onlinesein lässt sich nicht mehr zurückdrehen. Wer diese Geschwindigkeitsvorteile nutzen will, darf Tools für die  Zusammenarbeit über die Grenzen eines Büros hinaus nicht mit Reportingtools für das Management verwechseln oder sie dafür missbrauchen.

5 minutes on scaling: Hangout & Co

Natürlich nutzen wir mittlerweile neben den physischen Taskboards auch JIRA und Co. Doch jedes Mal, wenn ich diese Tools nutze, gehen mir ihre Unzulänglichkeiten auf den Geist. Sie lösen im skalierten Umfeld das eigentliche Problem nicht: Sie helfen nicht, die Kommunikation zwischen den Scrum-Teammitgliedern einer weltweit aufgestellten Organisation zu vereinfachen. Vielmehr sind sie zu Datenbanken, Reporting Tools, perfektionierten Bug Tracking Tools und Forecast Push Systemen degeneriert. Selbst bieten diese Wesen keinen Mehrwert – sie müssen sich der Lebenszeit von Entwicklern und Managern bedienen, um am Leben zu bleiben.
Dabei wäre es so einfach, ein wirklich funktionierendes, agiles Scrum-Tool zu entwickeln. Eines nämlich, das Arbeit beschleunigt und Kommunikation erleichtert, statt zu einer Belastung zu werden. Dazu bräuchte es nur ein paar Entwickler, die nach folgendem Rezept das perfekte Scrum-Tool bauen:

  1. Man nehme ein wirklich funktionierendes, d.h. stabiles Video Conferencing System wie zum Beispiel Google Hangout und verpasse ihm eine bessere Usability – sorry liebe Googles, das geht besser!
  2. Man füge eine Prise Telefoneinwahl international und kostenfrei hinzu – für die Teammitglieder, die während des Daily Scrums unterwegs sind (sorry, noch ist WLAN oder LTE auf deutschen Autobahnen und im ICE zu instabil – vor allem bei Hochgeschwindigkeitsfahrten).
  3. Dann mische man ein Whiteboard, eine Desksharing-Funktionalität, einen Persistent Chat und ein Taskboard hinzu.
  4. Nun braucht man noch die Möglichkeit, Texte auffindbar zu erstellen, die u.a. aber nicht nur an den Stories hängen. Deshalb integrieren wir ein Wiki, das sich aber bitte so wie ein Google Docs verhält.
  5. Für große Mengen an Bildern und Dokumenten brauchen wir noch Dropbox oder Evernote.
  6. Als Dessert nehmen wir noch einen integrierten Kalender, ein Shared Adressbook und eine E-Mail-Funktionalität.

Fertig. Alle zu Tisch, so kann man international arbeiten.
Ach so: Die Reporting-Funktionalitäten fürs Management lassen wir weg.
Fortschritte zeigen wir, indem wir fertige Produkte liefern – wir zeigen es nicht durch abgearbeitete Stories oder Tasks. Das ginge ja, wenn wir das Video-Chat-Programm so ausweiten könnten, dass wir ohne Probleme Demos auch für nicht Firmenmitglieder abhalten könnten.
Naja, ich träume. Aber ganz ehrlich, wir brauchen solche Tools. Die Entwicklung in der postindustriellen Netzwerkgesellschaft geht hin zu mehr Remote-Arbeit (work were you are), denn Teams kaufen sich die Kollegen dort ein, wo sie eben wohnen. Einer meiner Bekannten wohnt in St. Pölten (Niederösterreich) und arbeitet täglich für ein kalifornisches Unternehmen als Entwickler – warum auch nicht. Softwareentwicklungs-Teams können das heute. Andere Firmen werden folgen.
Wir müssen das möglich machen. Die Teams eines unserer Kunden arbeiten an zwei Orten in den USA, in China, in Indien und in München. Wir brauchen die Infrastruktur, um sie miteinander arbeiten zu lassen – und zwar produktiv. Und nein: Menschen zu einem Umzug oder hunderttausenden Flugmeilen mehr zu zwingen, ist keine wirkliche Alternative – weder steuertechnisch noch aus Sicht der Produktivität. Wissensarbeit braucht den Austausch, das miteinander Denken. Das geht in der Business Class des A380 nicht, da hilft auch die überfüllte Senatoren Lounge nichts mehr. Das ist nichts anderes als verlorene Lebenszeit.
Verteiltes, skaliertes und mulitkulturelles, grenzüberschreitendes Arbeiten wird zum Alltag werden. Kleine, schlanke Firmen werden das mit einer Symbiose aus den günstigen Lösungen wie Google HO, Confluence, Evernote und Dropbox stemmen. Große, unbewegliche Konzerne werden folgen – und dafür teure Enterprise Tools einkaufen. Vor allem müssen wir es schaffen, auch den multikulturellen Aspekt zu berücksichtigen. Schweizer, Österreicher und Deutsche – wir sprechen eine Sprache und meinen etwas völlig anderes. Ein elektronisches Board, dessen Sichtbarkeit auf die Größe eines Monitors beschränkt ist, muss also etwas anderes können, als beim Verschieben der Tasks die Farbe zu wechseln.

ScrumMaster Checkliste

Gerade wenn wir als ScrumMaster lange im Einsatz sind, werden wir betriebslind. Der gute ScrumMaster hat natürlich schon die Initiative ergriffen und sich jemanden gesucht, der ihm Feedback geben kann. Aber immer geht das nicht. Darum möchten wir euch heute eine Checkliste zur Verfügung stellen, mit der ihr eure Arbeit selbstständig bewerten und an verbesserungswürdigen Stellen arbeiten könnt. Ihr könnt diese Checkliste natürlich auch als Grundlage für ein Coaching nutzen.

 
Hier geht es zur Checklist_ScrumMaster_2012
 
 
Schreibt doch mal: Hat sie geholfen? Habt ihr noch etwas für euch ergänzt?

Brainstorming: Können wir ja alle … Wirklich?

Was ist das Erste, was uns allen einfällt, wenn wir im Team ein Thema angehen wollen, ein Problem lösen müssen? Versammeln wir uns doch mal im Besprechungsraum ums Flipchart und machen wir ein Brainstorming!
Jeder von uns hat es bestimmt schon unzählige Male gemacht – ich traue mich zu wetten, dass es 95% von uns meistens falsch gemacht haben. Und genau deshalb möchte ich zusammenfassen, wie es richtig gemacht wird. Denn das Brainstorming ist die einfachste und am meistgenutzte Möglichkeit, um kreativ(e) Lösungen für Probleme zu finden.

1. (und wichtigste) Regel: Raus mit der Sprache – Denk- und Sprechverbote waren gestern

Kommen euch folgende Sätze beim Brainstorming bekannt vor?

Und der absolute Dauerbrenner, einfach aber wirkungsvoll:

Diese Liste ließe sich schier endlos fortsetzen und auch noch um Mimik, Gestik und sonstige Zweifels- und Missfallensbekundungen ergänzen, die ähnliche Inhalte transportieren (Augen verdrehen, laut hörbar seufzen, anderen bedeutungsvolle Blicke im Stil von „so ein Schwachsinn“ zuwerfen, etc.). Das alles sind absolute Killer, die bewirken, dass der damit in „realistische Schranken“ gewiesene Brainstormer in seiner Kreativität blockiert wird. Erstens, weil er das Gefühl bekommt, dass seine Beiträge sowieso nicht angenommen werden, und zweitens, weil die Gedanken zum abgewürgten Input in seinem Gehirn endlose Kreise ziehen und damit neue Gedanken keinen Platz haben (so ungefähr wie: „Denk jetzt nicht an einen rosa Elefanten!“).
Wenn jeder Gedanke – egal ob er im Ergebnis als brauchbar in die Lösung mit einfließt, oder nicht – vorbehaltlos geäußert werden kann, ohne von den anderen bewertet oder gar abgewertet zu werden, dann ist er zumindest aus dem Kopf draußen und kann neuen kreativen Gedanken Platz machen. Macht euch daher vor jedem Brainstorming bewusst, dass ihr damit „nur“ eine erste Ideensammlung schafft, die ihr im Entstehungsprozess noch nicht an Machbarkeitskriterien messen müsst. Diese Ideensammlung werdet ihr in der Auswertung ohnedies noch clustern, ranken und Überlegungen zur Umsetzbarkeit unterziehen.
Und manchmal sind es genau die auf den ersten Blick völlig phantastisch erscheinenden Ideen, die – weiter gedacht, modifiziert und an die realen Umstände angepasst – im Ergebnis zur Lösung beitragen. Wollt ihr euch selbst um diesen wunderbaren, verheißungsvollen, ursuppenartigen Ideenpool bringen? Nein! Das wollt ihr nicht!

2. Regel: Ideenklau erwünscht

In unserer guten Kinderstube haben wir gelernt, dass man niemals die Ideen anderer Leute klaut und als die eigenen verkauft. Auch im Berufsleben haben wir uns schon mal die Nase gestoßen, wenn uns so etwas doch einmal unglücklicherweise passiert ist und der Ideenbeklaute dahintergekommen ist. Spätestens seit WWW und Intellectual Property Themen in aller Munde ist uns klar: geistiges Eigentum klauen ist gaaaaanz pfui (und kann auch noch ziemlich teuer werden)!
Fürs Brainstorming bitte wieder 180 Grad umdenken. Hier ist Ideenklau erwünscht.
Was meine ich damit? Damit meine ich, dass es beim Brainstorming ideal ist, auch auf den Inputs der anderen aufzubauen, sie weiter zu entwickeln, sie in einen anderen Rahmen zu setzen, etwas wegzunehmen hier, etwas hinzuzufügen dort, … Daraus kann im Idealfall in eurem Team eine starke kreative Dynamik entstehen, bei der eure Ideen nur so sprudeln. Und genau das ist es ja, was ihr wollt.
Damit das auch gut umgesetzt werden kann, platziert die bereits gesammelten Brainstorming-Inputs so, dass sie immer für alle Brainstormer gut sichtbar sind.

3. Regel: Wo die Depression am tiefsten, ist der Höhenflug am nächsten

Erfahrungsgemäß ist es so, dass irgendwann beim Brainstorming der Punkt kommt, an dem die Ideen versiegen. Wenn wir das merken, hören wir auf.
Mööööp.
Erfahrungsgemäß gibt es einen Punkt, an dem die Ideen vorübergehend versiegen. Die „Depression“. Hier bitte noch nicht zusammenpacken, Kaffee holen gehen und wieder jeder vor den eigenen Computer setzen. Denn wenn ihr dieses etwas unangenehme Schweigen der Ideen gemeinsam durchtaucht, kommt danach zumeist noch ein letzter kreativer Höhenflug, bei dem ihr noch einmal äußerst spannende Inputs sammeln könnt.

4. Regel: Abwechseln beim Schreiben am Flipchart

Ja, ich weiß.
Wir alle lieben es, beim Flipchart zu stehen und zu schreiben. Deshalb finden wir auch immer die wunderbarsten Ausreden, warum wir das nicht müssen – hier die fünf beliebtesten:

Beim Brainstorming ist es jedoch wichtig, dass nicht immer nur ein Teammitglied am Flipchart schreibt (auch wenn es jenes mit der schönsten Schrift ist oder zumindest jenes, das sich am wenigsten wehrt).
Warum? Weil man es trotz aller Multitasking-Fähigkeit als Schreiber einfach nicht schafft, alle auf einen einprasselnden Wortspenden (einigermaßen leserlich…) aufs Flipchart zu bannen und gleichzeitig selbst kreative Ideen zu entwickeln. Daher löst immer mal wieder die Schreiber ab, damit auch sie eine Chance bekommen, am kreativen Prozess teilzunehmen.

Variante mit Moderationskarten

Oft wird auch eine Variante des Brainstormings genutzt, bei der alle Brainstormer zu Beginn für sich ihre Ideen auf Moderationskarten schreiben. Das ist wunderbar, aber bringt euch damit nicht um den dynamischen, kreativen Prozess des gemeinsamen Brainstormings (siehe auch 2. Regel: Ideenklau erwünscht)! Das heißt: habt ihr einmal die Karten gesammelt und aufgepinnt, dann macht auch noch mal eine Runde gemeinsames Live-Brainstorming.

Beim nächsten Brainstorming daher beachten 

0. Regel: Zeitrahmen festlegen (ca 20 – 30 Minuten) und alle Regeln zu Beginn des Brainstormings kurz kommunizieren

  1. Regel: Denk- und Sprechverbote ade und raus beim Mund mit allem, was im Kopf herumschwirrt
  2. Regel: Ideenklau erwünscht
  3. Regel: „Depression“ durchtauchen für den letzten Höhenflug
  4. Regel: Abwechseln beim Schreiben am Flipchart

Probiert es doch aus und lasst mir bei Lust und Laune ein paar Kommentare hier, wie es euch damit gegangen ist!
Und zum Abschluss möchte ich noch mein persönliches Credo und damit sozusagen die hier 5. Regel festhalten: Arbeit darf auch Spaß machen. Spaß macht kreativ und Kreativität findet neue Lösungen!

Flighty Estimation – "schwereloses" Schätzen

14:00 Uhr – Estimation Meeting in Scrum. “Please focus your estimates and put your courage in the upright postion!” Noch nie gehört? Schade!
Vielen Teams fällt es anfänglich schwer, agil zu schätzen. Das wirkt sich auf den Schätzprozess als solches aus und das Erlernen des Prozesses wird langsamer. Vieles, was bei diesem Prozess passiert, hat mit Vertrauen zu tun. Genauer gesagt: mit dem Zurückerlernen des Vertrauens. Soll heißen, das Team empfindet das Schätzen oftmals als emotionale Belastung, weil in der Organisation Fehler nicht gerne gesehen werden. Bei Ungenauigkeiten und Abweichungen werden dann auch entsprechende Rechtfertigungen verlangt.

Wie durchbricht man das alte Muster? Wie bekommt man das Team dazu, schwerelos den Prozess zu erlernen?

Am besten spielerisch! Nehmt ein Beispiel, zu dem alle Teammitglieder einen neutralen Bezug haben. Etwas, das weder mit dem Status der einzelnen Teammitglieder zu tun hat, noch direkt mit der Arbeitswelt der Beteiligten in Verbindung steht. Nehmt einfach mal was anderes: Zum Beispiel Papierflieger.
Es irritiert euch, einen Papierflieger zu schätzen? Gut, denn genau das birgt die Chance, etwas zu lernen. Irritation ist einer der wichtigsten Bestandteile, um einen Lernprozess zu starten.
 
Zurück zu den Papierfliegern: Prinzipiell handelt es sich um einfache Dinge. Ein paar Mal in die eine Richtung gefaltet, dann in die andere und am Ende kommt ein Flieger heraus, der leichtgewichtig seine Bahnen zieht. Baut ein paar Papierflieger zusammen und lasst sie das Team analog zu User Stories schätzen: Wie gut verstehe ich den einzelnen Flieger im Aufbau und wie “groß” schätze ich den Bauplan des Fliegers? Schon haben wir die wichtigsten Komponenten für das Schätzen beisammen. Jetzt könnt ihr schwerelos den Schätzprozess starten und anhand eines Experiments leichtfüßig lernen.
Viel Spaß mit den Papierfliegern und unterschätzt den Bauplan nicht! Es ist gar nicht mal so leicht, sie zu bauen.
Wer Bauanleitungen für Papierflieger braucht, hier findet ihr welche: http://www.funpaperairplanes.com/Plane%20Downloads.html
Hier noch zwei sehr empfehlenswerte Blogeinträge von meinen Kollegen Mathis und Kristina zum Thema “Schätzen”:
http://borisgloger.com/2012/06/06/schatztauchen/
http://borisgloger.com/2012/06/05/ich-schatze-was-das-du-nicht-schatzt/

Impediment Management – vom Opfer zum Täter @Startup Weekend Berlin

Die erste Regel für den Impediment Backlog lautet: „Hänge es öffentlich auf“!
So einfach die Regel, so einfach auch die Umsetzung – und doch führt der Weg sehr oft zunächst durch viele Diskussionen. Diskussionen über Zweckmäßigkeit eines Impediment Backlogs an sich, Diskussionen über Vorteile oder Nachteile der analogen Gestaltung eines Impediment Backlogs im Gegensatz zum bereits existierenden, elektronisch geführten. Diskussionen über die politisch korrekte Platzierung eines Impediment Backlogs im fragilen Ökosystem eines Unternehmens – das sind ein paar Beispiele, die Liste könnte ich noch ewig fortsetzen.
Anstatt die Probleme zu diskutieren, möchte ich aber einfach mal eine Lösung zeigen. Vielleicht inspiriert das einige von euch und hilft, eine neue Sichtweise auf das Impediment Handling zu entwickeln. Beim Startup Weekend Berlin, das ich mit zwei Kollegen als Scrum-Coach begleiten durfte, formten sich viele Teams, die innerhalb von 54 Stunden der Fachjury eine investitionswürdige Produktidee vorstellen sollten. Einem der Teams fehlte ein Entwickler, aber auch Zeit, Geld und die Personalabteilung, die sich mit diesem Problem beschäftigen sollte. Was dem Team ganz und gar nicht fehlte: Kreativität, Mut und ein starker Wille. Und dann hatten die Teammitglieder ja noch ihre eigenen Ressourcen, die sie zur Verfügung stellen konnten. Das Impediment (fehlender Entwickler) und die Lösungsvorschläge wurden am Flur öffentlich plakatiert. Der Flurfunk „funkte“ über vier Stockwerke und 150 Leute und stieß auf positive Resonanz: Kurz darauf war das Impediment positiv gelöst!

Natürlich rechne ich mit Einwänden, wie: In großen Unternehmen wäre dieser Weg unmöglich, so eine Lösung ist unvorstellbar, man muss sich an den vorgegebenen Prozessen festhalten und eigentlich gibt es da ja ganz andere Impediments – und und und! Es ist mir bekannt. Ich weiß aber, dass es auch in großen, geregelten Unternehmen kreative Ansätze gibt, die bei der Lösung von Impediments helfen.
Ich wollte euch nur sagen: Diese Lösung beim Startup Weekend war einfach und hat funktioniert. Habt einfach auch einmal den Mut, den Impediment Backlog öffentlich zu platzieren.

Wie erstellt man eine Persona?

Letztens habe ich in meinem Blogbeitrag vorgeschlagen, die User-Rolle mit Leben zu füllen, indem man sich tatsächliche Menschen vorstellt, die hinter diesen Rollen stecken. Schaut euch mal die Reportage von ABC über IDEO an. Die zeigt wunderbar, wie das Design-Team herauszufinden versucht, welche Menschen einen Einkaufswagen benutzen und vor allem wie sie diesen Einkaufswagen nutzen. Das Team von IDEO verwendet also offensichtlich das Element der Persona, um sein Produkt den Notwendigkeiten anzupassen.

Natürlich sind die wenigsten Produkt-Entwicklungsteams so aufgebaut wie ein IDEO-Team, aber welche Elemente können wir dennoch nutzen und was können wir von IDEO lernen? Hier meine 10 Tipps:

Lasst die Personas auch an eurem Entwicklungsprozess teilhaben! Sie sollten bei Meetings – dem Sprint Planning 1 und 2, während der Reviews, aber auch bei allen Design-Entscheidungen – mit im Raum sein.
Fragt euch immer: Wie würde die Persona das Feature sehen, das ihr gerade entwickelt bzw. entwickeln lasst?
 

Die User-Rolle ist tot, es lebe die Persona

Die XP-Community hatte vor etwa zehn Jahren die Idee, User Stories zu benutzten, um die Essenz einer Funktionalität aus der Sicht des Anwenders aufzuschreiben.
Zu Erinnerung:
Als User-Rolle
möchte ich eine Funktionalität
so dass ich den folgenden Nutzen habe. [1]
Eine super Idee, die dann von Mike Cohn aufgegriffen und durch sein Buch „User Stories applied“ populär gemacht wurde. Die Idee war so einfach, dass sie die damals gängigen Use Cases als Analysetool sofort überholte. Das Tool ist aber so einfach wie schwierig. Funktionalität aus Anwender-Sicht zu beschreiben, fällt vielen sehr schwer. Noch spannender ist zu beobachten, dass es tausende User Stories gibt, die im folgenden Format formuliert werden:
Als User möchte ich XX
Also wird zum einen einfach aus User-Rolle = User und die Frage nach dem “Wozu” wird oft weggelassen.

Echte Menschen für echte Rollen – die Persona

Heute möchte ich kurz über den User reden. Es ist wichtig zu sehen, dass User-Rolle gemeint war, nicht User. Es geht darum, dass sich der Product Owner und das Team eine echte Anwenderrolle überlegen und mit dieser arbeiten. Das Konzept der User-Rolle ist hier aber offenbar nicht griffig genug. Daher schlage ich vor, das Konzept der User-Rolle aus den User Stories zu streichen und durch das Konzept der Persona zu ersetzen. Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Applikationen, unsere Anwendungen, unsere Produkte benutzen.
Eine noch schönere und ausführlichere Beschreibung einer Persona findet ihr auf dieser Website, zusammen mit der folgenden Beschreibung, was eine Persona ist:
“Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. They act as ‘stand-ins’ for real users and help guide decisions about functionality and design. Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo.
Although personas are fictitious, they are based on knowledge of real users. Some form of user research is conducted before they are written to ensure they represent end users rather than the opinion of the person writing the personas.“
Wir machen also aus der Rolle Administrator zum Beispiel: Hans Müller, 35 Jahre, IT-Fachmann, lebt in München, fährt morgens mit der U-Bahn zur Arbeit. Er hat zwei Kinder, ist Studienabbrecher und faszinierter Science Fiction Fan. Er liebt es, mit seinen Kinder Lego zu spielen.
Diese Person ist aber erforscht. Das heißt, wir reden mit einigen Admins, finden heraus, wie die wirklich leben, wie sie unsere Applikation tatsächlich nutzen werden. Hat man mit seinem Team diese Personas identifiziert – und davon gibt es natürlich einige, ihr könnt auch mehr als eine Persona pro User-Rolle definieren -, dann kann man anschließend die User-Rolle durch die Persona ersetzen. Auf diese Weise entsteht eine wesentlich lebendigere Vorstellung davon, für wen man die Applikation erzeugt, als durch die User-Rolle. Zumal dann per se klar wird, dass es nicht nur einen User gibt.
Viel Spaß beim Erstellen von Personas!
[1] Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2010

Grundwerte und Teamentwicklung in Scrum Teams

Das Team ist das zentrale Element in Scrum. Die Chance, über effektive Teamarbeit Synergie zu kreieren, ist allerdings von verschiedenen Variablen abhängig, unter anderem auch von der schnellen und gezielten Entwicklung des jeweiligen Teams. Definierte Teams gestalten immer von sich aus ihren, meist unbewussten, Arbeits- und Sozialprozess, der jedoch durch gesteuerte Teamentwicklung schneller und effizienter verlaufen kann.
Teamentwicklung ist definiert als die gezielte Einwirkung auf die komplexen, offenen und verdeckten Prozesse eines definierten Teams, bezogen auf die Aufgabenstellung, das Struktur- und Beziehungsgefüge und die einzelnen Teammitglieder, zur Optimierung von Arbeitsfähigkeit und Effizienz und der Bearbeitung aktueller Blockaden.

Gezielte Teamentwicklung gehört zu den Aufgaben des ScrumMasters, der zur Gestaltung und Umsetzung differenzierte Modelle und Methoden braucht. Ein effektives Instrument in der Teamentwicklung ist das Modell der „Drei Grundwerte sozialer Systeme“ Dieses Modell eignet sich optimal zur Teamprozessanalyse und kann die zentralen Elemente von Dynamiken und Prozessen im Team darstellen

Das Modell der drei Grundwerte

Es ist ein systemisches „Urmodell“, das in vielen Kulturen in ähnlicher Ausprägung vorkommt, und aussagt, dass in allen vorfindbaren sozialen Systemen (Teams) dieses Set der Grundwerte Wissen/Know-how, Ordnung/Struktur, Vertrauen/Beziehung als vorgegeben existiert: Diese Grundwerte sind von zentraler Bedeutung für den Prozess der Selbstorganisation des Systems (Teams). Die zentrale Botschaft dabei ist, dass jeder dieser drei Werte im Team gewürdigt, gelebt und fließend entwickelt werden muss. Sind diese drei Werte in ausgewogener Balance, bedeutet dies für Teams Stabilität und Lebensenergie im Sinne effektiver Selbstorganisation. Entsteht eine Dynamik von Dis-Balance, d.h. ein Wert dominiert überproportional bzw. ein Wert ist sehr schwach ausgeprägt, erleben Teams diesen Zustand als z.T. massive Störung.

Der ScrumMaster in der Teamentwicklerfunktion kann daraus ein Prozessanalyseschema ableiten, das ihm und dem Team ermöglicht, z.B. in Retrospektiven oder Teamentwicklungsworkshops den Ist-Stand zu definieren und Entwicklungsfelder abzuleiten.
Ein Teamentwicklungsprofil könnte z.B. folgendermaßen aussehen:

Jedes Team hat ein individuelles Profil, das sich aus der Ausstattung und dem Zusammenwirken der Grundwerte gut ableiten lässt. Dieses Profil kann der ScrumMaster für sich als Beobachtungs- und Diagnoseinstrument entwickeln und nutzen, aber auch mit dem Team gemeinsam er- und bearbeiten. Der Prozess mit einer konsensorientierten Reflexion und Festlegung des Ist- Standes des Teams zwischen den Polen 1 und 10 und der Definition von Entwicklungsfeldern setzt eine fruchtbaren Dialog in Gang und ist damit Teamentwicklung par excellence. Die einzelnen Elemente jedes Grundwertes sind hier beispielhaft dargelegt und können je nach Praxissituation ergänzt werden.
Dieter Rösner, Trainer ScrumMaster Pro