14. Juni 2018
Get in touch
Heute ist alles agil und super. Alle Probleme in Projekten und Softwareentwicklung haben sich in Luft aufgelöst. „Shiny, happy People“, so weit das Auge reicht. Alles ist einfacher und einfach besser. Wirklich?
Jede Software- oder Internetagentur die etwas auf sich hält, verkauft sich heute als agil. Und die meisten behaupten schon ganz lange, dass sie nach agilen Projektmethoden arbeiten. Das ist in der überwiegenden Anzahl der Fälle schlicht nicht wahr und trotzdem nicht wirklich gelogen.
Im Austausch mit vielen Softwareteams, vor allem im Bereich der klassischen CMS- und/oder E-Commerce-Dienstleistungen, stelle ich immer wieder fest, dass viele kleinere Anbieter noch nicht vollständig verstanden haben, was agiles Arbeiten wirklich heißt.
Oft wird das „Drauflosprogrammieren“ ohne Konzept als grundsätzlich Agil verstanden. Was es natürlich nicht im Ansatz ist. Oder es gibt zwar die hinreichend dem Namen nach bekannten Artefakte wie Daily und Retro etc. in den Abläufen. Die Meetings beinhalten aber ganz andere Tätigkeiten und Abläufe.
Ich bin daher der Überzeugung, dass so „Quasi-Agile“ Projekte genau dasselbe Potenzial für Drama haben, wie herkömmlich organisierte Wasserfall-Projekte. Und ich habe schon einige schiefgehen sehen.
Wirklich von den Vorzügen der agilen Entwicklung kann meiner Meinung nach erst profitiert werden, wenn diese auch konsequent umgesetzt wird. Aus Erfahrung kann ich sagen, so richtig erfolgreich ist ein agiles Projekt meist erst, wenn der Kunde einen fähigen Product Owner stellt, der mit dem Team zusammen die Entwicklung in Iterationen begleitet und auch wirklich Entscheidungen treffen kann.
Damit, neben der Hierarchie in der Firma, auch fachlich entschieden werden kann, muss der Product Owner zudem über entsprechendes Detail-Know-how verfügen.
Und bei größeren Projekten sollte er (oder sie) auch noch ausschließlich für das Projekt zu Verfügung stehen. Eine nicht ganz einfach zu findende Kombination.
Um mit neuen Kunden agile Projekte machen zu können, ist meiner Meinung nach ein umfassendes Verständnis für die Prozesse von entscheidender Wichtigkeit. Das bringen die wenigsten Kunden mit.
Es liegt daher nichts näher, als dem Kunden genau dieses Wissen zu vermitteln. Bei AOE gibt es für neue Kunden bei Bedarf einen zweitägigen Kurs, um sich mit den Grundlagen und nachher den Details des agilen Entwicklungsprozesses vertraut zu machen. Gerne sind da gerade auch projektfremde Führungskräfte gesehen, da sie als Entscheidungsträger oder Beeinflusser von Entscheidungen ebendiese Prozesse auch kennen müssen.
Meist werden diese Kurse kostenfrei für den Kunden erbracht. Als ich das vor ein paar Monaten einem Kollegen eines Softwarehauses erzählte, meinte jener, dass sei schon krass, dass man da als Anbieter noch Kosten damit habe. In Tat und Wahrheit ist es aber so, dass dieses Geld sehr gut investiert ist – reduziert es doch im Projekt später Aufwand und Ärger signifikant.
Als ich letzthin in einem Unternehmen über das agile Unternehmen und agiles Arbeiten sprechen durfte wurde in der Q&A eingebracht, dass man viele Kunden habe, die den agilen Prozess nicht kennen würden und insbesondere auch einen Design-Thinking-Prozess noch nie gemacht hätten. Ich denke, das ist ein guter Punkt. Das ist in der Tat schwierig.
In solchen Situationen fände ich es fatal zu kommunizieren, dass man nur agil arbeitet. Das schließt den Kunden sozusagen aus.
Viel besser ist es meiner Meinung nach, dem Kunden die Wahl zu lassen zwischen althergebrachter und neuer, agiler Arbeitsmethode. Nimmt man sich ein wenig Zeit um die Vor- und Nachteile zu erklären, so meine Erfahrung, lassen sich viele Kunden darauf ein. Und das tun Sie dann bewusster – was wiederum die Chancen auf Erfolg des Projekts erhöht.
