Agile Worst Practices – Teil 4

Willkommen zum vierten Post aus der Serie Agile Worst Practices, die ich mit diesem Post begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein Problem auf, das es auch außerhalb der agilen Welt gibt, im agilen Kontext aber noch größeres Schadenspotential entwickelt:

Team Worst Practice #4: Bloß keinen Kundenkontakt

Beschreibung: Diese Worst Practice gibt es in verschiedenen Ausprägungen. Allen gleich ist die Grundeinstellung: “Ich weiß eh am besten, was der Kunde braucht”. Entsprechend ist es ja nicht notwendig, mit dem Kunden, dem Anwender oder auch nur dem Product Owner zu sprechen – alles vertane Zeit, in der man ja schon etwas programmieren könnte. Mehrwert produzieren ist doch die goldene Regel der Agilität, oder?

Und da lenken Kunden und ähnliche Nicht-Experten einfach nur ab. Nicht nur, dass sie die Dinge einfach nicht vernünftig formulieren können, sie wissen doch gar nicht, was sie wollen. Da muss doch einfach mal ein Experte ran und denen zeigen, was sie brauchen.

Gleiches gilt auch für Fachkonzepte und ähnlichen Ballast (im Lean-Jargon auch gerne “Waste” genannt oder von den ganz hippen Agilisten “Muda” – japanisch für sinnlose Verschwendung). Wozu sollte ich meine Zeit damit verschwenden, womöglich auch noch vor einer Schätzung? Ich weiß es eh besser!

Konsequenz: Man muss kein Hellseher sein, um vorauszusagen, dass das Ergebnis bei einem solchen Verhalten mit hoher Wahrscheinlichkeit nicht den Erwartungen des Kunden entsprechen wird. Auch wenn der Kunde bzw. Anwender sich in der Tat manchmal schwertun, ihre Vorstellungen “auf den Punkt” zu bringen und sie (aus verschiedenen, meist nachvollziehbaren Gründen) während der Entstehung einer Funktionalität auch einmal ihre Meinung ändern, so sind sie letzten Endes dennoch die einzigen, die sagen können, was sie benötigen, um ihre Aufgabe zu erfüllen.

Bezieht man sie bei der Umsetzung nicht in die Lösungsfindung mit ein, so wird man normalerweise eine suboptimale Lösung realisieren, die dem Kunden/Anwender nicht oder nur eingeschränkt hilft, seine Aufgaben möglichst effizient und effektiv zu erfüllen.

Häufig führt ein solches Vorgehen auch zu geringerer Qualität des Ergebnisses, weil benötigten Qualitätsanforderungen nicht wahrgenommen und damit auch nicht umgesetzt werden. Oder um es einfach zu formulieren: Das Ergebnis ist technisch vielleicht top, aber fachlich ein “Flop”.

Maßnahmen: Häufig ist der Grund für eine solche Einstellung nicht Arroganz, wie man zunächst vermuten könnte, sondern eher Unsicherheit. Es besteht eine große (gefühlte) Distanz zwischen dem Kunden/Anwender und dem Entwickler im Team. Und da viele Leute sich schwertun, eine solche Distanz von sich aus abzubauen, sollte man da unterstützen.

Eine gute Maßnahme ist z.B. ein gemeinsames Kick-Off, möglichst in einem nicht zu formalen Rahmen, damit die Leute Zeit haben, sich gegenseitig ein wenig kennenzulernen. Auch ein gemeinsames Projekt-Event nicht zu spät während des Projektes wirkt oftmals echte Wunder.

Eine etwas kleinere Maßnahme ist, das Team zu den Sprint-Demos mitzunehmen und es die Demo selber durchführen zu lassen, inklusive der Diskussionen, die sich häufig bei der Demo ergeben. Nebenbei ist das sowieso meistens eine gute Idee, wird nur häufig nicht gemacht, weil sich die Kosten dafür über die Sprints hinweg summieren, vor allem, wenn der Kunde nicht um die Ecke sitzt. Diese Kosten werden dann gerne eingespart und nur der Scrum Master oder der Product Owner, ggf. mit einem weiteren Senior machen die Demo. Lässt man das Team die Demo machen, so fungieren Scrum Master bzw. Product Owner nur als Moderator.

Und sollten diese Maßnahmen nicht fruchten und die Distanz wird vom Team oder einzelnen Personen daraus aufrecht erhalten, kann man ggf. auch noch ein fachliches Design einfordern, um die betreffenden Personen mehr oder minder dazu zu zwingen, sich mit der Fachlichkeit und den Anforderungen auseinanderzusetzen. Natürlich muss in dem Fall auch sichergestellt sein, dass jemand zur Verfügung steht, der dieses Design auch validieren kann.

Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:

  • Den Link zum ersten Post dieser Serie findet Ihr hier.
  • Den Link zum nächsten Post dieser Serie findet Ihr hoffentlich in Bälde hier … ;-)

PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Uwe Friedrichsen

2 Antworten auf Agile Worst Practices – Teil 4

  1. Marc Clemens sagt:

    Einer der Gründe für dieses Verhalten liegt an der Vorstellung, dass das Team von der Außenwelt abgeschirmt wird um sich auf die aktuell anstehenden Aufgaben zu fokussieren. Und ganz falsch ist diese Vorstellung auch nicht, diese Fokussierung ist wichtig. Wichtiger ist aber, das Problem des Kunden das es zu lösen gilt zu verstehen. Daher muss ein gesundes Maß an Kundenkontakt gefunden werden, bzw. dieser Kontakt kanalisiert werden. Das ist eine der Grundaufgaben des Product Owner/Scrum Master Gespanns, vor allem im laufenden Sprint. Der Kontakt zwischen Team und Product Owner ist dabei nicht einzuschränken. Er muss dem Team als erste Ansprechpartner für Fragen zu Umsetzungsdetails zur Verfügung stehen, und kann anders herum sich technischen Rat für neue Anforderungen beim Team holen.

    Die von Dir erwähnte (doch etwas arrogante) Grundeinstellung “Ich weiß eh am besten, was der Kunde braucht” rührt daher, dass die meisten Kunden mit den aufkommenden meist sehr detaillierten Umsetzungsfragen überfordert sind. Das wiederum führt dann öfter mal zu „falschen“ Antworten, die dann später wieder geändert werden müssen. Hier liegt das Problem aber eher in der falschen Art den Kunden zu fragen (mit der Einstellung „Wenn ich schon den Kunden fragen muss, dann kann er mir auch genau sagen was ich zu tun habe.“). An dieser Stelle ist es wichtig die Probleme und Motivationen des Kunden zu verstehen und ihn bei der Lösungsfindung zu beraten.

    In einer Sprintdemo sollte immer das Team das Ergebnis präsentieren und dabei so vollständig wie möglich anwesend sein (bei Distributed Teams ist das natürlich nicht immer möglich). Neben dem immens wichtigen direkten Feedback den das Team hier bekommt, wirkt es erhöht es auch die Motivation des Teams ein qualitativ und quantitativ passendes Sprintergebnis zu erzeugen. Außerdem wer soll denn sonst präsentieren? Laut Scrum ist (nur) das Team für das Sprintergebnis verantwortlich.

  2. Hallo Marc,

    danke für die gute Ergänzung … kann ich nur “unterschreiben”.

    Eine Anmerkung noch:

    “In einer Sprintdemo sollte immer das Team das Ergebnis präsentieren und dabei so vollständig wie möglich anwesend sein …”

    Yup, ist prinzipiell absolut richtig (siehe “unterschreiben” von oben), wird aber häufig aus Zeit-, Kosten- oder welchen Gründen auch immer nicht so gemacht. Deshalb hatte ich es noch einmal als mögliche Maßnahme erwähnt.

    Gruß, Uwe

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>