Interview mit Björn Schotte

Das Geheimnis des agilen Erfolgs
Kommentare

Agile Vorgehensweisen gehören in vielen Unternehmen zum Standard. Zahlreiche Projekte weltweit setzen auf Scrum, XP, Lean oder andere bekannte, aber häufig auch selbstgestrickte agile Methoden. Das Problem ist allerdings, dass nicht jedes Projekt erfolgreich ist, nur weil es auf agile Methoden setzt. Was vielen fehlt, ist die Bereitschaft, umzudenken.

Genau darüber haben wir mit Björn Schotte gesprochen. Er erklärt uns, warum es nicht mehr genügt, in Projekten zu denken – und welche Fehler man bei der Einführung agiler Methoden noch machen kann.

Produkte, nicht Projekte

PHP Magazin: Björn, du bist auf der IPC dieses Jahr mit einer Keynote vertreten. Erzähl uns doch bitte kurz, worum es da geht.

Björn Schotte: Es geht um Products, not Projects. Wie der Titel schon sagt, geht es um einen kleinen Wandel, den wir schon seit einiger Zeit im Netz erleben – im wesentlichen bei der Erstellung von Online-Software/ Mobile-Software. Ich will einfach mal ein bisschen polarisieren, zum nachdenken anregen, warum Hersteller lieber in Produkten denken sollten als in Projekten.

PHP Magazin: Und, wieso sollten sie lieber in Produkten denken?

Björn: Naja, sieh es mal so: Vor fünf bis zehn Jahren war es so, dass Unternehmen hauptsächlich irgendwelche Corporate Websites haben entwickeln lassen. Also mit TYPO, im Stile von „wir präsentieren uns, stellen uns dar, zeigen, was wir so machen“. Durch den fundamentalen Wandel, gerade auch durch das Mobile-Umfeld und durch die flächendeckende DSL-Verfügbarkeit ausgelöst wird, wissen wir natürlich, dass das Netz allgegenwärtig ist und dass wir, speziell auch die jüngere Generation, einen ganzen Teil unseres Lebens durch das Netz organisieren und dementsprechend auch Software dafür nutzen. Solche Softwareprojekte – ich nenne es jetzt noch mal Projekte – setzen in der Herstellung immer einen Fokus auf ein finales Produkt.

Tatsächlich ist es aber doch eigentlich so, dass so ein Produkt über viele Jahre genutzt wird, und meines Erachtens gehört dazu eben auch ein anderer Fokus bei der Herstellung von solch einem Produkt. Wenn also heute ein Unternehmen – ein Autohersteller zum Beispiel –, einen Onlineshop für Autoersatzteile entwickeln möchte, dann sollte er bitte nicht in einem Rahmen eines Projekts denken, also im Sinne von „ich fange heute an und hör in drei Monaten auf und muss da nichts mehr investieren“. Häufig genug reden wir hierbei über Zyklen, die über sehr, sehr viele Jahre gehen. Und da braucht man eigentlich Product-Management-Know-how dafür.

Björn Schotte

Björn SchotteBjörn Schotte ist Geschäftsführer und Senior Consultant bei Mayflower. Eines seiner Spezialgebiete ist die rechtskonforme Vertragsgestaltung für agile Softwareprojekte. Als einer der vier Mitbegründer der Mayflower GmbH ist er verantwortlich für den Bereich Marketing, PR und Vertrieb und mit seiner Expertise ein gern gesehener Gast und Speaker auf nationalen und internationalen Konferenzen und Tagungen.

PHP Magazin: Ist es denn vergleichbar mit der Produktpalette eines Automobilkonzerns, die zum Beispiel alle paar Jahre ein Redesign machen? Oder wie kann man sich das vorstellen?

Björn: So ungefähr kann man sich das vorstellen, ja. Redesign ist ein gutes Stichwort, das kennt vielleicht der eine oder andere beim Erstellen von Corporate Websites. Da hieß es früher „Relaunch“ oder „Redesign“ – mittlerweile heißt es etwas abgeschwächt in den Marketingabteilungen nur noch „Rebrush“, weil man quasi einzelne Teile auf der Website irgendwie ein bisschen anders anpinselt.

So ähnlich kann man sich das entsprechend im Rahmen einer echten Onlinesoftware, also zum Beispiel einem Onlineshop, vorstellen. Unternehmen, die erfolgreich online arbeiten wollen, werden da in der Regel kontinuierlich investieren und auf dieser Basis ganz andere Überlegungen anstellen, was die Entwicklung von neuen Funktionen betrifft. Und das hat sehr viel mehr mit Produktmanagement und Produktentwicklung als mit einem typischen Projektbusiness zu tun, bei dem man einfach sagt: „Okay, heute starte ich ein Projekt und in drei Monaten bin ich durch und danach muss ich die nächsten drei Jahre nichts mehr investieren und kann dann weiter Geld verdienen.“

So leicht ist es leider nicht mehr.

PHP Magazin: Bedeutet das nicht im Umkehrschluss, dass sich Unternehmen, die im Web aktiv sind, eigentlich nur auf ein Projekt – oder in dem Fall ein Produkt – beschränken können?

Björn: Naja, beschränken nicht unbedingt. Sie können natürlich mehrere Produkte für sich erstellen, aber im Wesentlichen geht es um eine Grundhaltung, die teilweise natürlich auch durch die ganze Agile-Bewegung ausgelöst wurde – dort sprechen wir ja auch von Produkten.

Die Anwendung agiler Methodologien ergibt besonders dann einen Sinn, wenn man tatsächlich Produkte entwickelt. Es ist so ein kleiner Paradigmenwechsel, der da stattgefunden hat, eben weil die Kunden der Kunden – also die Nutzer – tatsächlich auch kontinuierlich so eine Software nutzen.

Wie agile Methoden helfen können

PHP Magazin: Ihr arbeitet sehr agil, und zwar in allen Bereichen – im Marketing, in der Entwicklung sowieso. Wie unterstützen agile Methoden diesen Umschwung?

Björn: Das unterstützen sie hauptsächlich dahingehend, als dass sie statt auf eine große, umfangreiche Einmal-Planung – die sowieso meistens komplett obsolet ist – auf eine kontinuierliche Planung setzen. Das wird dadurch unterstützt, dass im agilen Umfeld die Rolle des sogenannten „Product Owners“ existiert. Das ist derjenige, der sich für das Produkt businessseitig verantwortlich zeichnet.

Das ist etwas völlig anderes als wenn ich sage, „ja okay, ich hab halt jetzt ein Projekt und mach mal drei Features“. Der Product Owner sollte tatsächlich bei jedem Feature, dass er haben möchte, über den Business Impact nachdenken, d.h. überlegen, was bringt denn eigentlich diese Funktion für den Nutzer? Bringt mir das Geld, kann ich damit Geld einsparen, welchen Geschäftswert bekomme ich also eigentlich durch dieses Feature? Das ist ein ganz anderer Denkprozess, der innerhalb der agilen Methoden sehr tief eingebrannt ist und dazu führt, dass man tatsächlich erfolgreiche Software entwickeln kann; und damit natürlich auch – in unserem Fall – mit den Kunden deutlich besser wirtschaften kann als in anderen Fällen, wo es tatsächlich nur um ein einfaches Projekt geht.

PHP Magazin: Kann man so was lernen? Sagen wir, ich hab ein bestehendes Unternehmen, wir arbeiten bisher nicht so, weil wir schon seit zehn Jahren irgendwas im Web machen, das läuft so vor sich hin … kann man diesen Umschwung einfach so hinkriegen?

Björn: Jain. Wenn ich jetzt ein Werbeblog einführen würde, würde ich sagen, kommt doch einfach zu meinem Workshop auf der IPC, in dem genau solche Themen auch behandelt werden. Also welche Tools und Methoden es braucht, um tatsächlich vernünftige Features zu entwickeln, zu priorisieren, den Geschäftswert zu bestimmen und ähnliches.

Ansonsten ist natürlich eine Zertifizierung zum Product Owner im agilen Umfeld sehr hilfreich. Vielleicht auch ein bisschen eine veränderte Denke, ein verändertes Verständnis auf Seiten der Kunden. Gerade wenn ein Projekt aus der Marketingabteilung gesteuert wird, wird es häufig als Projekt behandelt. Da sagt die Marketingabteilung: „Wir haben Budget X, da lassen wir drei, vier Features draus entwickeln und das war’s dann.“ Solchen Leuten empfehle ich tatsächlich entweder den Besuch des Workshops und zusätzlich natürlich auch eine Zertifizierung, um die Grundlagen zu lernen.

Agile, das unbekannte Wesen

PHP Magazin: Das ist ein ziemlich spannender Punkt. Agil wird ja leider auch oft missverstanden. Gerade in der Anfangsphase, wenn man sich an der Einführung agiler Methoden versucht, definiert man ein Featureset und nach dem Sprint haben wir halt nur drei von fünf Features geschafft – lebt damit. Wie kommt man aus diesem Teufelskreis wieder raus?

Björn: Naja, wieso Teufelskreis?  Wenn ich innerhalb eines Zweiwochen-Sprints tatsächlich nur zwei Features schaffe, dann habe ich hoffentlich auch eine Retrospektive, in der ich erörtern kann, warum nur zwei von den ursprünglich fünf geplanten Features geschafft werden konnten. Und eben diese Gründe helfen dann, um im nächsten Sprint besser planen zu können.

Tatsächlich geht’s in der agilen Entwicklung nicht so sehr darum, ob ein Feature drei Stunden braucht oder fünf Stunden oder zwei Tage, sondern eher darum, dass ich mit einem kontinuierlich zusammengesetztem Team den höchsten Business Impact herausholen kann, d.h. mit einer möglichst gleichbleibenden Geschwindigkeit ordentlich Features entwickeln kann. Wenn ich natürlich in der Vorabschätzung daneben gelegen habe, dann ist es erst mal so. Aber dadurch, dass man in diesen Inkrementen von zwei Wochen arbeitet, hat man die Chance, in der nächsten Planung einfach deutlich besser zu planen, vielleicht genauer hinzuschauen, was für die Abschätzung eines Features noch an Detaildiskussionen notwendig ist.

PHP Magazin: Aus deiner eigenen Erfahrung: Wie viele Projekte scheitern bei der ersten, zweiten, dritten, … Einführung von agilen Methoden?

Björn: Das kommt so ein bisschen auf die Kunden an  – und auf die Bereitschaft der Kunden.

Es gibt natürlich viele Einführungsprojekte, von denen ich auch aus meinem Umfeld gehört habe, die scheitern, weil der Kunde nicht bereit ist, sich selbst zu ändern. Der Kunde möchte zwar die Benefits von Agil haben – im Sinne des kosteneffizienteren Arbeitens, der Kostenreduzierung, vielleicht sogar Leute einsparen, mehr Geld verdienen, schneller am Markt sein usw. usf. – aber dass sie selbst was dafür tun müssen, dass ist den wenigsten bewusst.

Ich glaube, wenn man auf Kundenseite tatsächlich Ansprechpartner hat, die bereit sind, diesen fundamentalen Wandel auch mitzugestalten und mitzugehen, dann ist die Wahrscheinlichkeit für einen Erfolg der Einführung solcher agiler Methoden deutlich höher, als wenn ich einfach nur sage, „ich habe gehört, Agile ist der geilste Scheiß, den man machen soll und jetzt macht einfach mal, von oben herab, sozusagen“. Das wird nur selten funktionieren.

Aufmacherbild: Hello I Am Agile Name Tag Sticker Ability Quick Change von Shutterstock / Urheberrecht: iQoncept

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -