User Experience in Kanban

Grundlage dieses Beitrags sind folgende Publikationen:

• Winter, D., Schön, E.-M., Uhlenbrok, J. & Thomaschewski, J., (2013). User Experience in Kanban. In: Brau, H., Lehmann, A., Petrovic, K. & Schroeder, M. C. (Hrsg.), Tagungsband UP13. Stuttgart: German UPA e.V. (S. 220-224).
• Uhlenbrok, J., Schön, E.-M., Winter, D. & Thomaschewski, J., (2015). User Experience in Kanban – Case Study: Erfahrungen aus dem Relaunch eines Internetportals. In: Endmann, A., Fischer, H. & Krökel, M. (Hrsg.), Mensch und Computer 2015 – Usability Professionals. Berlin: De Gruyter Oldenbourg. (S. 84-94).
• Schön, E-M., Winter, D., Uhlenbrok, J., Escalona, M. und Thomaschewski, J., (2016). Enterprise Experience into the Integration of Human-Centered Design and Kanban. In: Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) – Volume 1. (S. 133-140).

In diesem Beitrag wird davon ausgegangen, dass Sie die Grundzüge von Kanban kennen und eine Integration von Kanban und dem Human-Centred Design anstreben. Zu Kanban gibt es eine Reihe guter Informationen, z.B. bei Wikipedia.

Wenn Unternehmen interaktive Produkte entwickeln, müssen diese eine positive User Experience aufweisen, um wettbewerbsfähig zu sein. Die Integration von Human-Centred Design (HCD) in die agile Softwareentwicklung ist daher notwendig. Es gibt viele Erfahrungen und Best Practices, die sich mit der Integration von HCD in Scrum beschäftigen. Doch auch Kanban erfreut sich großer Beliebtheit und wird immer häufiger in IT-Projekten eingesetzt. Trotz dieses Trends gibt es kaum Untersuchungen zur Integration von Kanban und HCD.

In diesem Beitrag berichten wir über wissenschaftlich erhobene Ergebnisse der Integration von Kanban und HCD anhand eines größeren Relaunch-Projektes.

Kanban und HCD

Kanban ist eine agile Projektmanagementmethode aus der Softwareentwicklung, die ihre Ursprünge beim japanischen Automobilhersteller Toyota hat. Der Automobilhersteller wollte einen gleichmäßigen Fluss („Flow“) in der Fertigung herstellen und so Lagerbestände reduzieren. David Anderson passte die Methode an und übertrug sie auf den IT-Bereich. Auch hier werden geringe Durchlaufzeiten während des Entwicklungsprozesses angestrebt. Im Fokus der Entwicklung steht immer die aktuelle Aufgabe. Die Wertschöpfungskette wird mit Hilfe eines Kanban-Boards visualisiert. Für gute Ergebnisse muss der Gestaltungsprozess den Prinzipien des Human-Centred Design (HCD) folgen. Agile Projekte stehen aber vor der Herausforderung, nicht nur einzelne Aufgaben, sondern auch das Gesamtprojekt zielgerichtet und nutzerzentriert zu realisieren.

Kanban vs. Scrum

Was genau unterscheidet Kanban und Scrum nun voneinander?

Im Vergleich zu Scrum ist Kanban wesentlich freier und hat weniger Vorgaben. Rollen, wie etwa der Product Owner in Scrum, sind hier nicht definiert. Anstelle der Scrum Sprints findet bei Kanban eine kontinuierliche Entwicklung statt. Die Teammitglieder betrachten dabei nur ihre eigenen Aufgaben in ihrem jeweiligen Fachgebiet. Durch die kleinteilige Arbeitsverteilung der Produktbestandteile ist jedoch die Erschaffung einer positiven User Experience ohne eine Konzeption des Gesamtprodukts schwierig.

Bei Scrum sind interdisziplinäre Teams notwendig, da dort alle nötigen Fertigkeiten zur Produktentwicklung gebündelt vorhanden sein müssen. Diese bestehen neben Programmierern auch aus Konzeptern, Business-Analysten und Designern. Kanban aber funktioniert auch in bestehenden nicht-interdisziplinären Teams. Daher ist die Einführung von Kanban im Hinblick auf nötige Anpassungen in der Organisation weniger aufwändig als bei Scrum. Kanban macht den Workflow sichtbar und das bestehende Prozessmodell kann schrittweise angepasst und verbessert werden. Kanban ermöglicht somit einen sanften Umstieg in die agile Entwicklung und kann auch ohne sofortige Änderung der gesamten etablierten Entwicklungsprozesse eingeführt werden.

Prozessablauf

Das Kanban-Board (siehe Abbildung 1) dient der Visualisierung der Arbeitsaufgaben und hat mehrere Spalten, die von den einzelnen Aufgaben durchwandert werden. Dieser „Flow“ kann zusätzlich durch eine Begrenzung der Anzahl an gleichzeitig in Arbeit befindlichen Aufgaben pro Spalte gesteuert werden. So werden Engpässe schnell sichtbar und es können durch den „Flaschenhals-Effekt“ auch nur so viele Aufgaben weitergereicht werden, wie es das Limit der nächsten Spalte zulässt.

Abbildung 1: Beispiel Kanban-Board

Human-Centred Agile Development (HCAD)

Agile Methoden werden inzwischen gerne verwendet. Dadurch ist auch der Forschungsbereich Human-Centred Agile Development (HCAD) sehr beliebt und es gibt viele Publikationen in dem Bereich. Einerseits wird dort von den Herausforderungen der Integration von Human-Centred Design (HCD) und agiler Softwareentwicklung berichtet. Andererseits beschreiben die Autoren aber auch Best Practices. Schön et al. 2016 fasst die wichtigsten Aspekte zusammen, über die in der Literatur berichtet wird:

1. Durchführung einer ersten Iteration für HCD
2. Unterstützung der kontinuierlichen Einbeziehung von Stakeholdern und Benutzern
3. Integration von Prototyping- und User Experience-Testaktivitäten
4. Verwendung von einfachen Artefakten, um ein gemeinsames Verständnis zu erreichen

Soll der Entwicklungsprozess mit Kanban diese Kriterien genügen, muss er um einige Methoden ergänzt werden.

Anpassung Workflow

Zur Integration des Human-Centred Design in Kanban muss die Wertschöpfungskette angepasst werden. Erklärtes Ziel ist ein strukturierter Workflow, in dem die Anforderungen (Requirements) durch den gesamten Entwicklungsprozess sichtbar bleiben. Zu diesem Zweck sind unter anderem zusätzliche Kanban-Boards, wie etwa ein Konzeptionsboard, sinnvoll und auch HCD-Evaluationen sollte ihren festen Platz haben. Auch Rituale und die Einführung von UX-Artefakten (Persona Stories, Prototypen) sind vorteilhaft. Nachfolgend werden die einzelnen Maßnahmen näher vorgestellt.

Konzeptionsboard

Bei der Verwendung zusätzlicher Kanbanboards bietet sich speziell die Nutzung eines Konzeptionsboards an. Der Workflow auf dem Kanban-Board wird oft aus einer technischen Perspektive mit Programmieraufgaben und den dazugehörigen Abnahme- und Auslieferungstätigkeiten visualisiert. Die konzeptionellen Aufgaben, wie z.B. User Research oder die Spezifizierung von Benutzeranforderungen hingegen werden vernachlässigt. Diese sind für eine erfolgreiche Umsetzung des Human-Centred Design jedoch essenziell.

Im Artikel von Winter et al. 2013 wurde erstmals eine Erweiterung nach „vorne“ um ein Konzeptionsboard vorgeschlagen. So können konzeptionelle Aufgaben auf die gleiche Weise wie Programmieraufgaben auf dem Entwicklungsboard organisiert werden. Müssen mehrere Teams (z.B. Konzeptionsteam und Programmierteam) abgebildet werden, können dafür auch mehrere Boards parallel genutzt werden.

Liegen Ergebnisse auf dem Konzeptionsboard vor, wandern diese (Abbildung 2) zum nächsten Board, dem Entwicklungsboard. Die Auslieferung erfolgt dann schlussendlich durch ein Administrations- oder Technikteam. Diese Arbeitsweise ermöglicht auch die Aufdeckung von Engstellen zwischen den Teams bzw. den einzelnen Boards.

Abbildung 2: Kombination mehrerer Kanban-Boards – Eine Aufgabe vom Konzeptionsboard kann z.B. auf dem Entwicklungsboard in mehrere Aufgaben aufgeteilt werden

Auch wenn bei mehreren Kanban-Boards mit getrennten Teams gearbeitet werden kann, müssen diese Aufgaben und Parameter wie etwa Realisierbarkeit oder Aufwand miteinander abstimmen. Teamübergreifende Meetings können die Grundlage für die Übergabe vom Konzeptionsboard zum Entwicklungsboard schaffen. Zusätzlich sind gemeinsame Daily Standup-Meetings sinnvoll, da sie den Austausch der beteiligten Teams fördern. So bekommt einerseits das Entwicklungsteam Informationen über zukünftige Aufgaben und andererseits erfährt das Konzeptionsteam von aktuellen Problemen bei der Realisierung. Des Weiteren müssen alle Teams die langfristige Entwicklungsplanung kennen. Daher ist eine teamübergreifende Kommunikation für die Gesamtübersicht aller Projektbeteiligten sehr wichtig (Abbildung 3). Zur Zielkontrolle muss am Ende, nach Durchlaufen des gesamten Prozesses, ein Abgleich zwischen dem Ergebnis und Planungen des Konzeptionsboard vorgenommen werden.

Abbildung 3: Teamübergreifender Kanban-Prozess

Team-Arbeit

Team-Arbeit versteht sich als interdisziplinäre Zusammenarbeit, denn geschlossene Gruppen von Experten können zur Bildung von sogenannten „funktionalen Silos“ führen. Im agilen Bereich hat die interdisziplinäre Zusammenarbeit einen hohen Stellenwert. Diese hat den Vorteil, dass Ideen schon in frühen Phasen der Softwareentwicklung von unterschiedlichen Seiten beleuchtet werden können. So kann z.B. ein UX-Entwickler bei der Konzeption eines neuen Features einen Frontend-Entwickler zu Rate ziehen. Dieser kann mit seinem Fachwissen Umsetzbarkeit und Aufwand bewerten und Optimierungsvorschläge beisteuern. Werden Ideen gemeinschaftlich weiterentwickelt, führt dies meist zu besseren Lösungen, die sich wiederum positiv auf die UX des zu entwickelnden Produkts auswirken. Eine mögliche Maßnahme zur Förderung des Austauschs zwischen den Teams ist zum Beispiel ein teamübergreifendes Daily Standup.

Release Evaluation

Mit der Zeit werden immer mehr Aufgaben auf dem Board abgearbeitet und wandern in die letzte Spalte des Boards, wo sie sich gemäß den Kanban-Regeln ohne Begrenzung (= WIP-Limit) sammeln. Für eine regelmäßige Evaluation bezüglich der nutzerbezogenen Eigenschaften eines Produkts wird auch für diese „Done“-Spalte ein WIP-Limit eingeführt, dessen Höhe abhängig von der Teamgröße und den Releasezyklen ist. Sobald dieses Limit erreicht ist, wird eine Release Evaluation vorgenommen. Aus den Evaluationen resultieren Optimierungen, die als neue Aufgaben in den Kanban-Prozess eingeplant werden können. Der so entstehende iterative Kontrollmechanismus ermöglicht die langfristige Verfolgung einer User Experience-Strategie.

UX-Artefakte

„Damit die am Projekt beteiligten Menschen eine einheitliche Sprache verwenden und eine gemeinsame Vision vom Produkt teilen, ist es wichtig mit den gleichen Artefakten zu arbeiten.“ (Uhlenbrok et al. 2015)

In der agilen Produktentwicklung haben sich folgende Artefakte bewährt (Winter et al. 2013):

• Personas: Das Erstellen von Profilen fiktiver Personen mit konkreten Eigenschaften und Bedürfnissen stellt einen effektiven Weg dar, potenzielle Nutzer besser zu verstehen. Auch Funktionen und Funktionalitäten können mithilfe von Personas besser priorisiert und das Design von digitalen Produkten und Dienstleistungen entsprechend gelenkt werden.
• Persona Stories: Zur Darstellung von Anforderungen, aber auch zu Abgrenzung des Produktumfangs, werden oftmals User Stories verwendet. Eine User Story besteht aus der textuellen Beschreibung der Anforderung, der Team-Diskussion über selbige und den Akzeptanzkriterien aus denen hervorgeht, wann die User Story abgenommen werden kann. Persona Stories (früher auch Persona-driven User Stories genannt) können verwendet werden, wenn Personas entwickelt wurden. Es handelt sich also um spezielle User Stories, die in direkter Verbindung zu einer bestimmten Persona bestehen und damit den Nutzer greifbarer machen. Persona Stories werden in Kanban nicht nur zur Konzeption genutzt, sondern den gesamten Entwicklungsprozess hindurch verwendet.
• Prototypen: Ein großer Vorteil von Prototypen ist die Möglichkeit, komplexe Zusammenhänge einzelner Anforderungen zeigen zu können und Arbeitsabläufe von Nutzern zu visualisieren. Auf diese Weise erhalten die Projektbeteiligten eine gute Vorstellung des zu entwickelnden Produkts. So kann schon sehr früh überprüft werden, ob „das konzeptuelle Modell mit den Annahmen über das mentale Modell übereinstimmt“ und somit eine intuitive User Experience vorhanden ist. Zusätzlich kann schon vor der eigentlichen Entwicklung Nutzerfeedback eingeholt werden und es können erste Usability-Tests durchgeführt werden. Die daraus gewonnenen Erkenntnisse fließen anschließend in die Produktentwicklung ein.

Case Study

In den Jahren 2013/2014 wurde die Integration von UX in Kanban im Rahmen des Relaunches eines Internetportals in der Praxis eingesetzt. Basierend auf dem obigen Ansatz bezüglich der Integration des HCD in Kanban, wurden für die Durchführung der Case Study von Uhlenbrok et al. 2015 vier Forschungsfragen formuliert:

1. Welche Vorteile bringt der Einsatz eines Konzeptionsboards in Kanban?

2. Wie hat sich die interdisziplinäre Zusammenarbeit gestaltet?

3. Wie wurde die Release Evaluation durchgeführt?

4. Wie sind die UX-Artefakte integriert worden?

Während des Projekts wurde in einer IT-Organisation das vorhandene Entwicklungsboard um ein vorgelagertes Konzeptionsboard ergänzt. Das zwölfköpfige interdisziplinäre Team hatte somit die nötigen Strukturen für einen teamübergreifenden Austausch, der wiederum bei der Vermeidung funktionaler Silos hilft. Für die letzte Spalte des Konzeptionsboards wurde ein WIP-Limit festgelegt. War dieses Limit erreicht, wurde eine Release Evaluation durchgeführt und dabei erkannte UX-Probleme von Experten überprüft und mit den Entwicklern zusammen schnellstmöglich behoben. Persona Stories fanden keine Verwendung, da mit Personas im Unternehmen zum Projektzeitpunkt noch nicht gearbeitet wurde. Stattdessen wurde mit einfachen User Stories gearbeitet und für komplexere Bereiche Prototypen konstruiert. Letztere fanden sich auf dem Konzeptionsboard in der Spalte „Testing“ wieder.

Zwölf Monate nach Projektabschluss wurden Telefoninterviews mit sechs Projektmitgliedern durchgeführt. Von Interesse war die Sicht der Befragten auf den Prozess, sowie eine Einschätzung der Vor- und Nachteile des Vorgehens. Auch wurde auch nach der persönlichen Bewertung der Usability und User Experience des entstandenen Internetportals gefragt.

Ergebnisse

Die Case Study liefert wertvolle Erkenntnisse für den Einsatz von des angepassten Kanban-Workflows in der Praxis. Eine ausführliche Darstellung findet sich in Uhlenbrok et al. 2015 sowie Schön et al. 2016.

Mithilfe des vorgelagerten Konzeptionsboards bündeln die Konzepter ihre Anforderungen und auch die Kommunikation zwischen den Teammitgliedern profitiert. Die Produktverantwortlichen und UX-Experten ersparen den Entwicklern somit viel Chaos. Darüber hinaus ist die Transparenz bei wiederkehrenden Anforderungen höher, so dass für gleiche Anforderungen gleiche Lösungen verwendet werden können.

2. Wie hat sich die interdisziplinäre Zusammenarbeit gestaltet?

3. Wie wurde die Release Evaluation durchgeführt?

1. Auslösen der Release Evaluation bei Erreichen des WIP-Limits der letzten Spalte des Konzeptionsboards
2. Entdeckte UX-Probleme von Experten bewertet und nach Zeitaufwand eingeteilt
3. Kleinere Anpassungen (Zeitaufwand < 30 Minuten): sofort mit Entwickler zusammen bearbeitet
4. Größere, schwerwiegendere Probleme: eigene Aufgabe im Konzeptionsboard

Alle Teilnehmer*innen waren mit dem Ergebnis und der Usability des Projekts zufrieden. Es gab eine allgemeine Zunahme der Nutzungszahlen und einen merkbaren Zuwachs an Unique Usern, also eine größere Anzahl unterschiedlicher Besucher der Webpräsenz.

4. Wie sind die UX-Artefakte integriert worden?

Weitere Erkenntnisse

• Die Implementierung des Prozessmodells sorgte für eine hohe Effizienz, für die aber auch die entsprechende Struktur und Disziplin benötigt wurde.
• Das Projekt wurde, verglichen mit Projekten ohne agiles Vorgehen, als sehr gut organisiert erlebt. Kanban wurde im Vergleich zu Scrum als performanter empfunden und hat durch sein klares Ablaufschema allgemein einen sehr positiven Eindruck hinterlassen.
• Durch die Integration von UX-Experten wurde der HCD-Prozess für die Stakeholder verständlicher.
• Die Bildung von funktionalen Silos konnte durch die direkte Zusammenarbeit vermieden werden.
• Die interdisziplinäre Zusammenarbeit stärkte das Bewusstsein für Usability bei allen Beteiligten nachhaltig und auch die Vorteile eines eigenen, kleinen UX-Teams wurden erkannt.
• Die Anzahl von Nutzerfragen (z.B. „Wie finde ich…?) ist dadurch zurückgegangen, der Support wird entlastet.
• Für einen guten Gesamtüberblick sollte das Konzeptionsboard möglichst neben dem Entwicklungsboard hängen.
• Um Zeitüberschreitungen beim Daily Standup großer Teams zu vermeiden, ist ein Verantwortlicher sinnvoll, ähnlich dem Scrum Master.

Fazit

Agile Prozesse können und müssen erweitert und optimiert werden, um eine nutzerzentrierte Gestaltung zu erreichen.

Bei Kanban kann ein vorgelagertes Konzeptionsboard eingeführt werden, das den Workflow visualisiert. So können für das Design und eine gute User Experience wichtige konzeptionelle Aufgaben auf die gleiche Weise wie die Entwicklungsaufgaben organisiert werden und Anforderungen strukturierter in den Entwicklungsprozess einfließen. Das gemeinsame Daily Standup und ein gleichgewichtiges Einbeziehen aller am Prozess beteiligten Teammitglieder öffnet die Grenzen zwischen den verschiedenen Teams und führt zu den gleichen positiven Effekten wie die Bildung multifunktionaler Teams.

In der durchgeführten Case Study zum Relaunch eines Internetportals führte dieser Ansatz zusammen mit den anderen Methoden zur Integration von HCD in Kanban zu einem Endprodukt, dem alle interviewten Teilnehmer eine sehr gute Usability bescheinigen. Der Einsatz von Prototypen und deren kontinuierliche Verbesserung verringerte zudem seitens der Stakeholder die Anzahl der erwarteten UX-Probleme. Der im Projekt zusammengestellte UI-Werkzeugkasten hat sich bewährt und wird nach wie vor eingesetzt.

Es zeigt sich, dass mit einigen gezielten Maßnahmen das Human-Centred Design erfolgreich in Kanban integriert werden kann und so Produkte mit besserer User Experience ermöglicht.