Agile Projekte und UX

Agile Entwicklung ist ein Dauerbrenner in der Software und Webbranche. Wenn man fragt, würden heute wohl die meisten Entwickler von sich behaupten, sie arbeiteten mit Scrum, Kanban, Extreme Programming und wie die bekannten Prozesse alle heissen. Dass sich der Usability-Prozess hervorragend in die agile Entwicklung integrieren lässt, haben wir im Dossier in der Netzwoche-Ausgabe 1/2012 bereits gezeigt. Dieser Beitrag geht etwas weiter – er skizziert, wie agile Projekte aufgezogen werden können, damit sie nicht «nur» technisch und ergonomisch hochwertige, sondern auch innovative Lösungen generieren.

Um es vorwegzunehmen: Es sind vor allem die Arbeitsbedingungen, die darüber entscheiden, ob ein Team sein Innovationspotenzial freisetzen kann. Sie müssen dergestalt sein, dass Techniker und Nichttechniker nicht nur gut zusammenarbeiten, sondern sich gegenseitig inspirieren.

Man sollte sich nämlich darüber im Klaren sein, dass durch agile Konzepte nicht automatisch innovativere Produkte entstehen als durch klassische. Agil ist ja bloss die Arbeitsmethode, und die ist vor allem darauf ausgerichtet, schnell und möglichst risikoarm zu einem ersten Release zu kommen. Das Prinzip ist bekannt: Statt das Projekt mit wenigen, grossen Meilensteinen zu strukturieren, bedient man sich vieler kleiner Sprints. Jeder dieser Sprints bietet nicht nur die Möglichkeit für Verbesserungen und Korrekturen, sondern auch zum Verwerfen von Teilkonzepten oder gar des gesamten Projekts. Das hält einerseits das finanzielle Risiko für den Projekteigentümer klein, schafft andererseits aber auch Freiraum für Experimente, also auch für Innovation.

Komfortzone verlassen

Wie lässt sich nun in der Zusammenarbeit zwischen Entwicklern und Usability-Fachleuten zusätzliches Potenzial mobilisieren? Systemisch betrachtet, geht das etwa, indem die Mitwirkenden dazu gebracht werden, ihre ureigene Komfortzone zu verlassen und sich thematisch und fachlich in neues Terrain vorzuwagen. Etwas plakativ formuliert, passiert dabei Folgendes: Die Entwickler verlassen ihre «sichere » technische Ecke und bewegen sich auf die eher schlüpfrig empfundene Welt von Usability-Experten und Interaction Designer zu. Umgekehrt treten letztere aus ihrer kreativen Spielwiese und nähern sich den trockenen technischen Sphären von Programmierern und Datenbankspezialisten. Dadurch entstehen neue Sichtweisen auf dieselbe Aufgabe, frische Ideen und originelle Ansätze.

Doch, wie wir alle schon erlebt haben: Das Verlassen der Komfortzone kann mit erheblichen Unannehmlichkeiten verbunden sein. Dazu gehören etwa die Angst, sich zu blamieren, sich in einem fremden Gebiet zu verlieren, nicht verstanden zu werden und so weiter. Das ist mit einem Verlust an Identität, an Souveränität verbunden. Solche Ängste sind höchst real, können ganze Teams blockieren und Projekte in die Irre führen, wenn sie überhand nehmen.

Wie fängt man derartige Ängste und Hemmungen in einem Team auf, das eigentlich weder Zeit noch Lust auf gruppendynamische Experimente hat? Klar, die adäquate Strukturierung und Organisation des Projekts sind auch hier sicher hilfreich. In erster Linie ist es aber eine Frage der Kultur. Es braucht eine Atmosphäre des Vertrauens und der Toleranz. Die Mitarbeiter müssen Gewissheit haben, dass sie nicht gleich vom Spezialisten vis à vis in die Pfanne gehauen werden, wenn sie einen gut gemeinten, aber auf den ersten Blick vielleicht nicht umsetzbaren Vorschlag machen. Es braucht Offenheit gegenüber neuen Ideen von ausserhalb des eigenen Spezialgebiets. Es braucht jemanden, der darauf achtet, dass Diskussionen nicht aus dem Ruder laufen. Es braucht eine Art Übersetzungsdienst, der die Verständigung über die Grenzen der Fachgebiete erleichtert. Es braucht in allen Köpfen unbedingt eine belastbare Idee dessen, was gemeinsam erreicht werden soll und welche Rollen den Einzelnen dabei zugeteilt sind. Und nicht zuletzt wird das Ganze nur funktionieren, wenn die Beteiligten immer wieder wohlwollend, aber mit Nachdruck dahingehend ermuntert werden, wohldosiert «über den Hag zu fressen».

Das mag jetzt alles nach Binsenweisheit klingen, deckt es sich doch weitgehend mit den Regeln, die generell für die Zusammenarbeit in interdisziplinären Teams gelten. Stimmt wohl, aber erfahrungsgemäss bleiben die draussen in der Berufswelt zu oft noch graue Theorie. Verschärfend kommt noch hinzu, dass gerade Prozesse, die Innovationen generieren sollen, ganz besonders empfindlich auf kulturelle Unzulänglichkeiten reagieren.

Vier Thesen

Sehen wir uns an, was getan werden muss, damit sich Fachleute aus unterschiedlichen Gebieten in einem Projekt gegenseitig befruchten. Hierzu folgende vier Thesen:

1. Klar und verbindlich festschreiben, was genau im Projekt entstehen soll (Produkt, Service, bis hinunter zum Button, Filter etc.). Das liefert die Grundlage für ein gemeinsames Ziel in den Köpfen aller Beteiligten. Damit es seine ordnende Wirkung entfalten kann, muss es ausformuliert und vor allem: von allen verstanden werden. Voraussetzung hierfür ist, dass der Business Case steht und damit die Anforderungen von allen Anspruchsgruppen minutiös abgeklärt sind. Agile Entwicklung ersetzt nämlich keineswegs die vorherige saubere Abklärung dieser Grundlagen.

2. Es muss definiert sein, was in Code umgewandelt werden muss. Die Entwickler brauchen klare und enge Vorgaben, bevor sie anfangen, zu arbeiten. Das vermittelt auf der einen Seite Sicherheit und klärt die Zuständigkeiten. Auf der anderen Seite steigert es die Effizienz und schafft damit den nötigen Freiraum, sich «fachübergreifend» für innovative Lösungen zu engagieren. Das hilft auch den Usability-Experten, weil sie nun wissen, wo ihre Aufgabe anfängt und wo sie aufhört.

3. Die Kultur entscheidet über Erfolg und Misserfolg im Innovationsprozess. Agile Projekte haben im Vergleich zum Wasserfallmodell einen deutlich höheren Bedarf an Kommunikation, Kooperation, gegenseitigem Respekt. Je kürzer die Loops sind, umso enger müssen alle zusammenarbeiten, umso besser müssen sie sich verstehen. Damit steigt auch die Bedeutung der Visualisierung. So helfen etwa Wireframes und Prototypen dabei, User-Storys zu überprüfen und damit ein gemeinsames Verständnis für die Anforderungen der Nutzer zu schaffen.

4. Der Projektleiter ist wichtiger, als man denkt. In agilen und speziell in innovationsgetriebenen Prozessen ist der Projektleiter nicht nur für Organisation, Strukturierung, Controlling zuständig. Er muss auch eine Atmosphäre schaffen, die Kreativität freisetzt. Zu seinen Aufgaben gehört auch, einen Teamgeist zu etablieren und aufrecht zu erhalten, der auch gelegentlichen Stürmen standhält. Hierfür braucht er Erfahrung, Empathie und starke Nerven. Er muss motivieren, Konflikte lösen, kommunizieren können und das grosse Ganze stets im Auge behalten. Nebenher behält er natürlich seine starke ordnende Funktion bei. Insbesondere ist er auch dafür verantwortlich, dass sich der agile Prozess in der Hitze des Gefechts nicht schleichend wieder in einen Wasserfall zurückverwandelt. Diese Gefahr ist grösser, als man denkt, weil viele Beteiligte dieses klassische Projektdenken in der Ausbildung eingeimpft bekamen.

Fazit

Wer schnell, gut und risikoarm entwickeln will, greift heute oft zu agilen Methoden. Wer aber darüber hinaus auch innovativ sein will, kommt nicht darum herum, sich um die viel gerühmten, aber wenig beachteten soften Faktoren zu bemühen. In diesem Zusammenhang erhält der Projektleiter als Wächter über die Kultur eine wichtige Rolle.

Ursprünglich veröffentlicht: Netzwoche Nr. 18, 2016