Auch heute habe ich einen guten Mix gefunden, alle Talks geben zusammen genommen ein rundes Bild ab.

Design Thinking

Mary Poppendieck  spricht darüber, wie man aus einer Idee ein Produkt designt. Ganz klar mit einem iterativen Prozess und mit viel Kreativität, Prototypen bauen, fail-early-fail-often, etc.

Wichtig ist zu wissen, welches Problem man lösen will und den eingeschlagenen Weg immer wieder darauf zu überprüfen – genauso wie man das Problem immer wieder hinterfragen muss. Als Beispiel brachte Sie hipmunk, eine Seite auf der man Flüge buchen kann. Wer hätte gedacht, dass man in 2010 noch Erfolg mit einer Flugpreisvergleichsseite haben kann. Der Unterschied zu anderen Seiten, hipmunk optimiert seine Seite auf das Erlebnis “Flug” und nicht auf “Kaufen“. So werden die Flüge nicht nach Preis sortiert, sondern nach “Qual”. Direktflüge, Flüge mit kurzen (aber nicht zu kurzen) Umsteigezeiten, Flüge die zu normalen Zeiten starten/landen tauchen in der Liste weiter oben auf.

Leider sind die Slides noch nicht Verfügbar, insgesamt hat Mary viele weitere Aspekte angesprochen, die ich noch nachreichen werde.

Integrating UX Into Agile: How To Ensure Your Sprints Result In Usable Software

Jon Innes hat mit der UXI Matrix eine Möglichkeit vorgestellt, wie man UX-Arbeit transparent in ein agiles Umfeld, zB Scrum, integrieren kann.

Im Ergebnis ist die Matrix die Erweiterung des vorhandenen Product Backlogs um weitere Spalten wie “Personas, UX Complexity, UX % done, Responsible UX-person”. Die Idee konnte überzeugen, die Umsetzung mit einem riesigen Excel Sheet nicht wirklich. Und Jon arbeitet auch noch daran die Matrix in vorhandene Tools integriert zu bekommen.

Viel wichtiger war aber der andere Blickwinkel, den ich jetzt auf UX-arbeit habe. Insbesondere die Erkenntnis, dass ich bisher keine Ahnung hatte, was alles zu UX gehört, ausser Photoshopen und Texten.

Selbstverständnis und Wahrnehmung

“Ich arbeite in der UX” ist eine genauso hohle Phrase wie “Ich arbeite im Projektmanagement”. User Experience beschreibt die Sicht und die Erlebenswelt des Kunden, was genau ist Deine Aufgabe auf der Seite des Produzenten/Verkäufers. PO und Entwickler und UXler müssen sich über die Rollen und Aufgaben einig sein und ein gemeinsames Verständnis davon haben.

User acceptance (tests)

Finden üblicherweise am Ende bzw. nach dem Sprint statt. Das ist aber mehr Waterfall als agil. Wir bauen über 4 Wochen ein Produkt und testen erst danach, ob es dem Kunden überhaupt gefällt und ob es sein Problem löst. Das ist nicht richtig.

Support, Sales, Marketing

Wenn unser Kunde ein Problem hat oder eine Reklamation, wie sieht dann seine Erfahrung mit uns aus, wie ist seine experience? Was ist mit Marketing oder Sales oder anderen Bereichen, in denen unser Kunde Kontakt mit uns hat. In diesen Bereichen muss UX noch viel stärker eingebunden werden.

Produktentwicklung und Research

UX muss viel stärker und viel früher in die Entwicklung von Produkten eingebunden werden. Das war auch schon ein Punkt bei Mary Poppendieck. “Was muss das Produkt können” und “Wie muss das Produkt funktionieren” sind zwei Fragen, die sich PO und UX teilen und bei denen jede Rolle aber auch jede Person einen Schwerpunkt finden muss. Und dann müssen diese Fragen möglichst früh und gemeinsam mit dem Kunden beantwortet werden.

Wir fragen unsere Kunden zu selten nach Ihrer Meinung und nach Ihren Ideen. Und wenn wir es tun, meist erst nachdem das Produkt fertig ist. Das ist nicht agil.

Basic Principle of the TPS and its Practical Ideas for Agile Software Process!

TPS ist das Toyota Production System - quasi der Urgroßvater von Lean und Agile. Satoshi Kuroiwa war jahrzehntelang Manager bei Toyota und hat unter anderem das TPS in IT und IS eingeführt.

Leider war der Talk schwer Verständlich. Satoshi spricht mit starkem Akzent, gefühlt war ein Drittel des Talks auf japanisch…

Die Slides waren “PowerPoint from Hell”. Mit Text vollgestopft, kleine Schriftgröße, Grafiken teilweise auf Japanisch. Puuh.

Insgesamt hat der Talk schon einen Eindruck von TPS und Agile und deren Gemeinsamkeiten und Unterschiede vermittelt. Mit einer besseren Präsentation wäre er aber deutlich ergiebiger gewesen.

Keywords: TPS is people centric, flow, eliminating waste

Scrum and Kanban Like Chocolate and Peanut Butter

Der Talk von Damon Poole drehte sich um Scrum und Kanban und wie man (insbesondere wenn man Scrum skaliert) beide Systeme kombiniert um so schnell wie möglich ein Produkt zu liefern.

Die Iterationen von Scrum sorgen für einen regelmäßigen Stillstand, der häufig noch durch eine hardening phase verschlimmert wird. Im Gegensatz dazu läuft Kanban kontinuierlich (flow).

Innerhalb einer Iteration und eines Teams kann ein Team durchaus Methoden aus Kanban verwenden, um Stories zu bearbeiten. insbesondere ein Kanban-Board und limiting WIP helfen dabei.

Scaling and flow with decoupling

Dazu nur ein paar Stichworte:

• Scrum Meetings von den Iterationen trennen, also Estimation Meetings nicht nur zum Sprintanfang machen, Retrospektive nicht nur zum -ende.
• Continuous Integration & Delivery. Nach jeder Story.
• Stories nicht nur im planning ziehen – Velocity pro Iteration oder pro “fliessendem 4 Wochen Zeitfenster” sind vergleichbar. Im Ergebnis geht es nicht um die absolute Zahl sondern die Veränderung der Velocity.