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!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.