Dass Usability Engineering und Agile Softwareentwicklung meiner Meinung nach ein gutes Team sind, konntet ihr bereits im Blogbeitrag “Passen Agilität und Usability Engineering wirklich zusammen?” erfahren. Wie sich jedoch die Rolle des Usability Engineers zu den anderen Rollen im Scrum-Prozess verhält und welche verschiedenen Möglichkeiten einer Zusammenarbeit es geben kann, möchte ich in diesem Blogpost erläutern.
Dazu stelle ich euch vier verschiedene Strukturen vor, mit denen der Usability Engineer in den agilen Entwicklungsprozess integriert werden kann:
Bei dieser Vorgehensweise ist der Usability Engineer als festes Scrum-Teammitglied im Entwicklungsteam integriert. Auch wenn er in jedem Sprint “lediglich” für Usability-Aufgaben zuständig ist, haben diese Einfluss auf die Team-Kapazität. Interdisziplinäres Arbeiten ist demnach nur bedingt möglich und hängt stark von den jeweiligen Fähigkeiten der Teammitglieder ab. Der Usability Engineer erstellt beispielsweise allgemeine Konzepte oder spezielle Mockups für die Entwickler. Entweder er nimmt hierbei seine Ergebnisse als Input für jeden Sprint, während die Entwickler die Vorschläge anschließend direkt umsetzen, oder er liefert alle Vorgaben im Voraus und die Umsetzung durch die Entwickler folgt erst einen Sprint später. Eine Kombination beider Ansätze ist natürlich möglich und von Projekt zu Projekt individuell.
Für kleine Neuerungen eignet sich die vollständige Integration von Usability Engineering in einen Sprint besonders gut, da der Usability Engineer hier eng mit den Entwicklern zusammenarbeitet, schnelles Feedback geben kann und dadurch zeitnahe Ergebnisse erzielt werden können.
Gibt es mehrere Scrum-Teams in einem Projekt, eignet sich diese Variante nur, wenn es ausreichend viele Usability Engineers gibt und jeder in einem der Teams platziert werden kann. Die verschiedenen Usability Engineers sollten sich dann untereinander regelmäßig abstimmen oder mit Hilfe eines zentralen UX-Teams alle Maßnahmen im Blick behalten und koordinieren. Ist der Usability Engineer "einfaches" Mitglied im Scrum-Team kann es außerdem problematisch werden, wenn der Product Owner die Ansichten des Usability Engineers nicht teilt und den Fokus lieber auf die Feature-Entwicklung legt, als auf eine gute Usability des Produktes.
Es ist auch denkbar, dass es einen übergeordneten UX-Product-Owner gibt, der für alle Usability-Aspekte und -Maßnahmen in einem Projekt verantwortlich ist.
Bleiben wir bei dem Beispiel von mehreren Scrum-Teams: Hier kann sich der UX-Product-Owner nicht mehr um alle Mockups oder Detailkonzepte selber kümmern. Er ist nur noch für die Priorisierung und Koordinierung der Aufgaben zuständig. Dies setzt allerdings voraus, dass die anderen Scrum-Teammitglieder die Erledigung der Usability-Aufgaben übernehmen. Das wiederum kann nur geschehen, wenn die Teammitglieder Usability-Know-How besitzen und es einheitliche Vorgaben gibt, an die sich jeder halten kann (z.B. einen Styleguide). Darüber hinaus muss der Usability Engineer sich mit den anderen Product Ownern abstimmen, was unter Umständen viel Koordinations- und Verhandlungsgeschick erfordert.
Der Usability Engineer kann außerdem als rechte Hand des Product Owners eingesetzt werden. Er wird als Ansprechpartner für alle UX-Fragen herangezogen, ist jedoch nicht direkt als Mitglied des Entwicklungsteams zu sehen, wodurch die Sprint-Kapazität unberücksichtigt bleibt. Bei mehreren Scrum-Teams sollte es auch mehrere Usability Engineers – nämlich genauso viele wie Product Owner – geben, damit die Aufgaben besser verteilt werden können. Auch hier sollten die verschiedenen Usability Engineers regelmäßig zusammenkommen, um die gemeinsame Produktvision voranzutreiben. Des Weiteren erstellen sie übergreifende Mockups und Konzepte, wohingegen eine konkrete Prototypenentwicklung auch von anderen Scrum-Teammitgliedern übernommen werden kann. In meinen Projekten war es außerdem enorm hilfreich, wenn der Usability Engineer den Product Owner bei der Erstellung von User Stories unterstützt.
Die Vorgehensweise, in der der Usability Engineer gleichzeitig auch die Rolle des Product Owner einnimmt, konnte ich bereits sehr gut austesten. Diese Variante der Integration von Usability Engineering in den Scrum-Prozess unterscheidet sich allerdings nicht so sehr von der vorherigen. Besonders vorteilhaft bei dieser Struktur ist beispielsweise, dass sich wesentlich leichter Usability-Methoden einplanen lassen. Der Usability Engineer hat außerdem durch eigene Absprachen mit Kunden, Stakeholdern, Entwicklern und Nutzern einen guten Überblick über Anforderungen, Features und die gesamte Planung. Dazu passt, dass das Projekt als Ganzes immer im Mittelpunkt der Aufgaben eines Product Owners stehen sollte. Ein guter Überblick ist demnach zwingende Voraussetzung. Ein Priorisierungskonflikt, der zwischen Usability Engineer und Product Owner eintreten kann, wird so von vornherein leichter vermieden.
Jedoch kann man nicht unbedingt allen Interessenkonflikten gleichermaßen aus dem Weg gehen. Gerade gegen Ende des Projektes kann es sein, dass der Product Owner aufgrund eines knappen Budgets, vermehrt auf das “Feature Complete” bestehen muss und dadurch Usability-Aspekte vernachlässigt.
Auf welche Art sich ein Usability Engineer in ein Scrum-Team integrieren lässt, ist natürlich immer individuell zu entscheiden und abhängig von der generellen Zusammensetzung und Größe des Teams. Dass der Usability Engineer jedoch in den Prozess eingebunden werden sollte, steht außer Frage – ist der Einbezug von Usability-Engineering-Maßnahmen doch in jedem Fall ein absoluter Gewinn.
Wenn ihr euch für das Zusammenspiel von Usability Engineering und Agilität interessiert, findet ihr in unserem Blog verschiedene Artikel dazu – zum Beispiel zum Thema User Story Mapping. Schaut doch mal rein!