Direkt zum Hauptbereich

Der Benutzer ist nicht dumm! Obwohl er am Ende (zu) oft der Dumme ist.

Software welche für einen Anwender entwickelt wird soll diesem bei seiner Arbeit unterstützen und ihm so einen Mehrwert liefern. Leider erlebe ich immer wieder, dass gerade dieser Benutzer nie ernsthaft gefragt wird, was er denn benötigt. Und das gilt auch für agile Projekte.
Und was ist der Grund dafür, dass ein Produkt Manager, Produkt Owner oder gar die Entwickler selbst die Anforderungen definieren? Nun die zwei häufigsten Antworten, die ich auf die Frage danach erhalte sind:
Es sind keine Anwender (Ressourcen) frei, welche dem Projekt zur Verfügung gestellt werden können.
oder
Der Anwender ist so eingefahren in seine aktuellen Arbeitsweisen, der weiß doch gar nicht was er braucht.

Nun ja wenn keine Ressourcen frei sind, so ist das in der Regel eine Frage der Prioritäten. Und oft auch ein mangelndes Bewusstsein dafür, welche Vorteile ein direkt eingebundener Benutzer bringt.
Viel schlimmer und schwerwiegender finde ich die zweite Antwort. Hier wird der Anwender, welcher in der Regel schon lange einen guten Job macht, für dumm gehalten. Es wird unterstellt, dass ein externer, welcher ein paar Fragen stellt und sich die Arbeit vielleicht auch mal live ansieht besser beurteilen kann wie die Arbeit richtig und besser gemacht werden kann und das bis in jede Detailtiefe. Und der Anwender kann ja auch nicht über den Tellerrand schauen und will eh nur das was er kennt nur schöner.
Ist dem so? Oder sind wir nur zu Faul oder zu Feige den Anwender zu Fragen und mit Ihm zusammen eine Software zu entwickeln, welche ihr Ziel erreicht? Oder Kratzt das an der Ehre des einzelnen der nicht mehr “sein” Produkt entwerfen darf?
Nun ist das agile Manifest schon über zehn Jahre alt und die agilen Methoden haben bewiesen, dass mit dem Anwender zusammen gute Software entstehen kann. Viele rühmen sich mit einem agilen Vorgehen und Iterationen aber der agile Geist scheint noch nicht überall  angekommen zu sein. So lange wir die Iterationsergebnisse nicht nutzen und den Anwender regelmäßig einbeziehen um dadurch zu lernen, werden wir auch weiter Software erstellen, welche ihr Ziel nicht erreichen.
Und am Ende ist der Anwender auch (endlich) der Dumme! Weil er mit dieser “tollen” Software, welche sicher seine Arbeit vereinfacht, wenn er sich nur erst an die Änderungen gewöhnt hat, nutzen muss.
Hören wir endlich auf dumm zu sein und fragen unsere Anwender!

Kommentare

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte.

Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen verteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Speed Temenos auf dem AgileDay der JAX

Letzte Woche hatte ich die Gelegenheit auf dem AgileDay der JAX zu sein. Neben Vorträgen am Vormittag mit Beiträgen zu Retrospektiven agile in Konzernen sowie einer spezifischen Implementierung in einem Unternehmen stand nach der Mittagspause ein Speed Temenos mit Olaf Lewitz und Christine Neidhardt auf dem Programm. Zur Unterstützung hatten sie sich Unterstützung über die Softwerkskammer organisiert, so dass die Anwesenden von insgesamt 20 Facilitatoren betreut wurden.

Bei Temenos handelt es sich um einen "geschützten Raum" in dem Menschen Offenheit und Vertrauen erleben können. Das Speed Temenos mit seinen 3 Phasen, in welchen es um die Persönliche (Berufliche) Vergangenheit, den Ist-Zustand und die Vision für die Zukunft geht hilft über Geschichten erzählen, sich selbst zu reflektieren und Gemeinsamkeiten in der Gruppe zu entdecken. Details sind auf http://trusttemenos.de/ viel besser erklärt als ich es hier kann.

Ich hatte Temenos mit Olaf bereits auf der Play4Agile 201…

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität.

Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus:

Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit.

Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist.
(Was nun was bedingt, lass ich mal dahingestellt)

Dadurch haben sich natürlich auch die Struktur…