Warum Scrum in Ihrem Unternehmen scheitert

Jeder, der etwas auf sich hält, möchte mit Hilfe von agiler Softwareentwicklung etwas für sich beweisen. Zum Beispiel wie schnell man auf strategische Veränderungen, impulsive Ideen und modularen Aufbau ganzer Projektberge reagieren kann. Entwickler sind endlich frei in ihrer Arbeit. Projektleiter, als Chefs der Scrum Teams, werden nicht gezwungen mit Projektteilnehmern zu interagieren. Geschäftsführer träumen von einer im Zeitplan befindlichen Entwicklung. Endlich ist ein unendlich großer Ausbau von Qualität und Feature-Sets möglich. Bravo.

Den Investoren und der Holding wird mitgeteilt, dass man ab sofort Zeit spart. Und Zeit ist bekanntlich Geld. Das Marketing tanzt bereits Tango, weil sich die Brand besser entfalten kann. Konzerne versprühen im Kicker-Raum nach Rosenwasser duftendes Start-Up-Flair. Und Neugründungen wachsen auf Pizzaböden zu Einhörnern heran.

Warum reale Fabelwesen nichts mit nur einer Methode zu tun haben, Scrum mit diesen Wunschvorstellungen nicht einmal verwandt ist und agile Softwareentwicklung nur so gut ist wie das Kanu, welches am Steg des Wasserfalls angebunden bleibt, soll Thema dieses Artikels sein. Denn: Agile Entwicklung ist teuer. Sie zielt nicht auf raschere Programmierung ab. Ach ja,… und sie hat keinen Platz für Delegierung oder Vorgesetzte. Kurz: Ich bin begeistert von agiler Softwareentwicklung. Ehrlich.

Eine neue Hoffnung

Natürlich habe ich mich dazu entschlossen mit einer Reihe von provokanten Wortaneinanderreihungen Aufsehen zu erregen. Sogar mit einem Plottwist. Ein Ringen nach Aufmerksamkeit, wenn man so will. Und doch verbergen sich kleinere und größere Wahrheiten in meinen vorhergegangenen Sätzen. Meiner Erfahrung nach wird Scrum missverstanden. Zutiefst. Und entsprechend wachsen in vielen Unternehmen unberechenbare Vorstellungen heran. Dann gibt es noch diejenigen, welche im Wechsel der Entwicklungsmethodik keinen Nutzen sehen. Konzerne sind schließlich auch ohne agile Softwareentwicklung gewachsen. Und wenn man ehrlich ist: Da ist schon etwas Wahres dran.

Tatsache ist aber auch, dass es einen Umbruch bei der Softwareentwicklung gab. Aus Gründen. So recht zufrieden waren also nicht alle in dem Projekt involvierten Personen. Die Geschichte von Sutherland und Schwaber kennt man. Und wer schon mal in die Notwendigkeit einer Projekt-Budgetplanung gekommen ist, weiß dass das Resultat mit den Zahlen auf dem Papier selten etwas gemein hat. Wo der Grund liegt, ist abhängig von der eingenommenen Perspektive. Und alle sind falsch. Oder richtig. Die agile Softwareentwicklung soll es dann richten. Und dabei ist es so offensichtlich, dass eine Methode zur Umsetzung von Softwareprodukten hierbei nur unterstützen kann. Nicht mehr. Nicht weniger.

Tu es oder tu es nicht – es gibt kein Versuchen

Pragmatisch betrachtet ist ein Projekt mit einem Supermarkt-Einkauf zu vergleichen. Ich überprüfe meine Finanzen und entscheide daraus folgend was ich tatsächlich aus dem Discounter benötige. Zudem plane ich mit Verkehr und Wartezeit an der Kasse noch zwei Stunden meines Tages ein. Jetzt die entscheidende Frage an Sie: Wie oft waren Sie beim Einkaufen erfolgreich?

Die Masse wird sicherlich zustimmen, dass man dazu geneigt ist zu sagen, dass dieser Vorgang üblicherweise sogar sehr erfolgreich ist. Ich gratuliere. Ein super gelaufenes Projekt.

Wenn ich jetzt aber an den Vorgaben oder den Ereignissen innerhalb des Projektes „Einkauf“ schraube, verändert sich alles. Sie haben weniger Budget. Oder lediglich eine halbe Stunde Zeit für den Einkauf. Eventuell sind nicht alle Waren auf Lager. Vielleicht hat der Supermarkt auch die Regale völlig umgeräumt. Oder Sie planen zum aller ersten Mal den Einkauf, weil Sie gerade erst bei den Eltern ausgezogen sind. Und stellen wir uns doch nur vor, dass Ihnen an der Ampel ein Wagen in den Kofferraum fährt. Ihr Auto bleibt also auf der Einkaufsstrecke erstmal liegen. Nicht nur, dass die Zeitplanung hinüber ist, auch das Eis im Kofferraum schmilzt, die Eier sind kaputt und der Einkauf war partiell nutzlos. Es verändert sich alles, nicht wahr? Aber der Einkauf ist irgendwie fertig geworden. Ein Erfolg?

Bei der Entwicklung von Software sieht es ziemlich ähnlich aus. Unzählige Firmen hatten es letztlich satt „Geld zu verbrennen“. Und da Erkenntnis bekanntlich der erste Schritt zur Besserung ist, handelt man nun. Irgendwie. Das macht es aber leider nicht besser.

Um alles etwas effizienter zu gestalten, stampfen Unternehmen irgendwann so etwas wie Scrum aus dem Boden. Hat man schon mal gehört. Im Valley machen das ja alle. Man tastet sich also heran. 2 Wochen lang. In dieser Zeit haben die Mitglieder des agilen Teams in vielen Meetings gesessen, unzählige Haftnotizen verbraucht oder aufwändige Jira-Boards implementiert. Abgeschottet von Impulsen des Abteilungsleiters. Genau diese Impulse, welche in der alten Welt doch mal eben schnell gemacht hätten werden können. Und das steht nun dem Erfolg des Unternehmens im Weg. Geschafft wurde nichts. Die Geschäftsführung ärgert sich über die neumodische Methode und das Team versteht die Welt nicht mehr. Die feenbestaubte agile Softwareentwicklung aus dem Valley hatte scheinbar keine Wirkung. Oder zumindest die Falsche. Könnte also Erfahrung und Disziplin der Schlüssel zum Erfolg sein?

Wenn der Kunde dem Weg weichen muss

Um es mit aller Deutlichkeit zu sagen: Agile Produktentwicklung steht und fällt mit der Unterstützung des gesamten Unternehmens und vor allem mit dem korrekten Fokus. Gerade im alltäglichen Hierarchie-Denken fällt es einem oft schwer, das eigentliche Ziel im Auge zu behalten. Oftmals geht es vielmehr darum, ein Projekt zu beenden. Und das ziemlich schnell und unbedingt mit geringen Kosten. Allerdings möchte man auch nicht die Freiheit verlieren, nochmals in den Zyklus der laufenden Entwicklung einzugreifen, weil man feststellt, dass ein pinker Button viel mehr Conversion bringt als graue Schaltflächen. Gute Qualität wird hierbei natürlich vorausgesetzt, aber ohne die Rahmenbedingungen zu schaffen. Wie oft wurde die Testing-Zeit bei Ihrem letzten Projekt verringert, um eine Timeline zu halten?

Spricht man mit einem Projekt- bzw. Produktmanager, dann wird er mit Sicherheit mitteilen, dass von ihm verlangt wird, Projekte zum Erfolg zu führen. Wie falsch diese Aussage ist (und ich kann den Menschen dahinter noch nicht einmal einen Vorwurf machen), zeigt sich an der Einfachheit der nachfolgenden Antwort: Der Kunde steht nicht im Fokus, sondern das Abteilungsziel. Der Weg, nicht das Resultat. Oder um es physikalisch zu beantworten: Das Weg-Zeit Verhältnis (= Geschwindigkeit) steht im Mittelpunkt der Entwicklung. Beide Variablen werden hierarchisch vorgegeben: „Baut ein Produkt (Was) bis zum Tag X (Wann) auf diese Art und Weise (Wasserfall).“

Dass diese Vorgehensweise gänzlich den Anspruch von Nutzen und Qualität vermissen lässt, versteht sich von selbst. Und natürlich ist es richtig, dass man sich nicht in Details bei einer Produktentwicklung verlieren sollte, um dem Wachstum eines Unternehmens nicht im Wege zu stehen. Dennoch würde es der Masse der Projekte da draußen guttun, wenn man sich Zeit für eine außerordentliche Planung nehmen würde. Sich mal wieder Zeit nehmen, einen Nutzer, wie auch seine Kommunikationskultur, komplett zu verstehen. Gerade letzteres ist mir in den vergangenen Jahren immer häufiger über den Weg gelaufen. Wenn man aufgrund mangelnder Zeit oder gar des Skillsets Abstriche in der Usability für Kunden macht, dann helfen oftmals nur noch Transparenz und gute Erklärungstexte für den Nutzer. Überschriften, Tool-Tipps, oder einfach nur die unmissverständliche Benennung eines Call-To-Action. Das ist total ok. Nur muss man es auch machen. Und wenn man sich einen smoothen Einstieg einer agilen Methodik wünscht, dann steht dies jedem frei. Warum also nicht das Testing per Haftnotizen in Kanban-Form an einer Bürowand platzieren und sich dort mit Akzeptanzkriterien austoben? Ich konnte dahingehend sehr gute Erfahrungen mit dem Entwicklerteam meines Arbeitgebers machen.

Die berühmten Haftnotizen im Einsatz

Mut zur Lücke heißt: Platz für den Kunden

Woher kommt also diese antrainierte Vorgehensweise? Und warum fehlt es in Projekt- und Produktmanagement an der Akzeptanz etwas nicht genau zu wissen und entsprechend keine Aussagen treffen zu können? Einfach mal wieder zugeben, dass man etwas nicht kann – oder weiß. Früher war man noch erfolgreich damit. Schließlich ist das Projekt beendet worden. Verbugt. Aber beendet. Alle sind absolut genervt von der Umsetzung. Aber das Ziel ist erreicht.

Aufgrund des digitalen Wandels, welcher an Geschwindigkeit immer mehr Fahrt aufnimmt, steigt auch der Konkurrenzdruck. Besonders die Generation „Ich-bin-smart-und-will-ein-Start-Up-Gründen“ macht es Konzernen sehr schwer, die Geschwindigkeit zu halten. Letztlich hat man das Gefühl, dass Neugründungen frische Features täglich in Pressemitteilungen verkünden. Mit unerfahrenem Personal. Kleinem Budget. Geringeren Gehältern und Erfahrungswerten. Ein Gegensatz, welcher sich meist mit den Mindsets erfahrener Manager, nicht erklären lässt.

Und alles in der Aufzählung ist der Grund für den Erfolg. Mit Weniger arbeiten, bedeutet sich auf mehr zu konzentrieren. Es ist ein kreativer Staffellauf, welcher viele kleine Meilensteine präsentiert und eben nicht nur der Zieldurchlauf, von dem man gar nicht weiß, ob dort zur vermuteten Finalzeit noch irgendein Zuschauer jubelt.

Start-Ups haben keine andere Wahl, als mit geringen Ressourcen schnelle Resultate auf den Markt zu bringen. Diese sind dann eben eher ein Feature als ein fertiges Produkt. Knowledge wird sich während des Sprints angeeignet. Erfahrene Wissensträger als Analysten für den Entwicklungszeitraum integriert. All das konnte in den Planungen berücksichtigt werden, weil sich ein Team abgestimmt hat. Mut zur Lücke bewies. Und den Experten auch tatsächlich zuhörte. Wie oft wird dem eigenen Personal die Kompetenz abgesprochen. Nur um einem überbezahlten Consultant darum zu bitten, die Thesen der eigenen Mitarbeiter zu bestätigen. Aktiv. Oder auch Passiv. Irgendwie typisch Konzern. Letztlich geht es doch bei Methoden, wie Scrum, darum das Feature für den Kunden zu bauen. Koste es was es wolle. Wie schon gesagt: Agilität hat seinen Preis. Das hat ein Kobe-Steak im Übrigen auch. Und das Fleisch hat beste Qualität.

Erfolg durch Relevanz, Ruhe und Vertrauen

Doch wollen wir ehrlich sein: Scrum, Kanban und all die smarten agilen Wunderkinder sind keine Heilsbringer. Wie könnten sie auch? Methodik alleine macht noch keinen Erfolg aus. Auch Wasserfall hat seine Berechtigung. Schließlich gibt es Projekte, welche, zum Beispiel mit Scrum, over engineered wären. Es ist in meinen Augen ein Trugschluss, dass sich ein Unternehmen nur eine Methode aussuchen darf. Oftmals ist es die Kombination, welche die richtige Würze ins Spiel bringt. Oder würden Sie für die Korrektur eines Rechtschreibfehlers eine User Story schreiben? Mitsamt einer Priorisierung und Schätzung des Teams. Nur damit der Fehler innerhalb eines zwei-wöchigen-Sprints aus der Welt geschaffen wird. Sicherlich nicht. Das wäre verrückt. Zudem steht es in keinem Kosten-Nutzungs-Verhältnis.

Glauben Sie mir, wenn ich sage, dass die agile Softwareentwicklung eine gute Projektrecherche nicht ersetzt. Zu oft wird dies über den Haufen geworfen: „Scrum braucht das doch gar nicht.“ Habe ich alles schon gehört. Und gelesen. Im Übrigen, nicht nur bei Konzernen. Ich empfehle hier das Komplexitäts-Diagramm von Ralph Stacey, welches es genau auf den Punkt bringt und dabei hilft, sich in diesem Methodik-Universum zu orientieren.

Das Stacey-Diagramm als Hilfe im Methodik-Universum

Noch viel wichtiger ist es aber, oftmals Ruhe zu bewahren. Geduld mit seinen Kollegen und der Geschäftsführung zu haben. Besonders, wenn man neue Methoden im Unternehmen platzieren will. Auch das sollte gut recherchiert sein. Denn es braucht Zeit, Kraft und Empathie. Im Scrum Team gibt es keine Hierarchien. Nur Rollen. Niemand ist Chef. Wenn doch, dann eventuell im Unternehmen – aber eben nicht in seiner Rolle im agilen Team. Das Team ist autark und bremst sich nicht mit schmerzhaftem Personalmanagement. Und gibt es Reibungen, dann löst man das unter Kollegen, oder mit dem tatsächlichen Chef außerhalb der Scrum Truppe. Aber dafür muss viel im Argen liegen. Pure Eskalation vorherrschen. Da lohnt sich dann auch schon eher die Rolle neu zu besetzen, um den Flow nicht zu unterbrechen.

Überzeugen Sie das Management und andere Abteilungen von Agilität, indem Sie von Mehrwerten für den Kunden sprechen. Nicht für das Unternehmen. Seien Sie sich um die Unterschiede von Effizienz und Effektivität bewusst. Agile Softwareentwicklung ist teuer und überträgt Verantwortung von der Leitung an das agile Team. Ist es dem Management aus fachlichen oder emotionalen Gründen nicht möglich die Finger aus Detailfragen zu halten, dann wird, zum Beispiel Scrum, nicht den ersehnten Erfolg mit sich bringen. Versprochen. Das Team wird gar demotiviert. Wer hat beim Schreiben von User Stories schon gerne eine Souffleuse neben sich sitzen?

Lang lebe die Vision

Mikromanagement kann mit Agilität nicht funktionieren. Unterbricht man laufende Sprints oder kippt in den bereits vollen Eimer weiteres Wasser hinzu, dann werden schnell die Füße nass. Heißt: Aufgrund von Anforderungen wurde eine Vorgehensweise geplant. Ändert man also die Anforderungen (Komplexität, Menge…), dann ist der Plan dahin. Eigentlich simpel. Nennt man auch Kausalität.

Die versprochene Flexibilität durch agile Softwareentwicklung entpuppt sich urplötzlich als Regelwerk aus Titan. Nichts geht mehr. Impulse sind nicht möglich. Und die Kosten scheinen zu explodieren. Der Mehrwert ist dahin. Das ist dann rasch die Denke des Managements. Es wird schmerzlich realisiert, dass impulsive Entscheidungen keinen Platz in Scrum haben. Dies wird dann als mangelnde Flexibilität abgetan. Dem ist nicht so. Nicht die Methode ist das Problem. Die fehlende oder nicht verstandene Vision ist es.

Man ist nur dann impulsiv, wenn man auf etwas Überraschendes emotional reagiert. Es findet keine Planung statt. Man wägt Pros und Cons nicht ab. Sollte aber nicht genau das bereits Bestandteil einer guten Vision sein? Der Vision des Managements wohlgemerkt. Möchte man dem Kunden unüberlegt Features in die Hand drücken, auf welchen sich nichts aufbauen lässt? Sollte man nicht lieber ein durchdachtes Fundament aus Features gießen, um ein ganzheitliches Produkt zu schaffen. Eines das der Nutzer wirklich benötigt?

Agil bedeutet gemeinsam voneinander lernen

Im Unternehmertum findet sich diese impulsive Ader häufig, aufgrund neu gewonnener Erkenntnisse oder gut gemeinter externer Ratschläge. Die können von Consultants, Investoren oder Kunden kommen. Das spielt keine Rolle. Im Übrigen, in Konzernen wie auch Start-Ups. In diesen Fällen muss man dem Management, oftmals nur in Bildsprache klarmachen, dass seine Vision gefährdet ist. Es einen Rattenschwanz mit sich zieht, wenn eine laufende Entwicklung unterbrochen wird. Und eben diese impulsive Anforderung langfristig keinen Platz in seinem Masterplan hat. Daraus wachsen dann die Gespräche, welche Augen öffnen lassen. Eine Folgediskussion münzt nämlich grundsätzlich in der Tatsache, dass die impulsive Anforderung nichts als eine These ist, welche sich bisher nicht auf Fakten stützen lässt. Es gibt keine Recherche. Erst recht keinen Business Case. Und falls es sie dennoch gibt, liegen die Informationen bisher nicht (vollständig) vor.

Wie soll also eine Komplexität von einem agilen Team bestimmt werden? Der Ball liegt dann letztlich wieder beim Management. Es müssen Daten zur Prüfung nachgereicht werden. Das sieht jeder gute Manager ein. Schließlich war sein Spezialisten-Team nicht eingeweiht. Und so gewinnt man für gewöhnlich Zeit bis zur nächsten Planung des nächsten Sprints. Verlockend, nicht wahr?

Gerade bei der Implementierung von agilen Entwicklungsmethoden gibt es enorme Reibungen. Durch die ganze Firma hinweg. Das ist auch gut so. Ein Unternehmen lernt sich neu kennen und Kommunikation ist der Schlüssel für eine saubere Entwicklung. Das müssen auch die Scrum Teams lernen. Im Speziellen der Product Owner und Scrum Master – sofern vorhanden. Dennoch müssen sich auch die Entwickler im Team auf transparente und hitzige Diskussionen einlassen. Ehrlich miteinander und zu sich selbst sein. Klar aussprechen, wenn es Hindernisse gibt. Und letztlich auch selbst Verantwortung übernehmen. Softwareentwicklern wurde das über Jahre hinweg abtrainiert. Eine Rückführung tut weh. Das gehört dazu.

Was mir noch wichtig ist

Agile Teams müssen gemeinsam wachsen. Nicht zwingend an der Anzahl der Mitglieder. Vielmehr im Zusammenspiel. Und im Mindset. Das eigene Können darf hinterfragt werden. Gar unabdingbar, um realistische Schätzungen abzugeben. Es gibt keinen Platz für Egos. Zudem finden sich so Synergien.

Sobald sich alles eingespielt hat, dann passieren wunderbare Dinge. Knowledge wächst. Entwicklungszeiten reduzieren sich. Produktqualität steigt. Projektresultate werden nicht mehr anhand einer Timeline bewertet, vielmehr am positiven Kundenfeedback. Ein herrliches Gefühl. Denn nichts ist motivierender, als Produkte zu bauen, von welchen man selbst überzeugt ist. Nicht nur der Kunde. Oder die Geschäftsführung.

Und das letztlich nur, weil man an den Kunden denkt. Nicht von der Vision abweicht. Die relevanten Methoden und Tools verwendet. Emphatisch mit seinen Kollegen umgeht, als Unternehmen an den richtigen Zielen arbeitet und nicht nur für die Abteilung etwas beendet.

Ziel erreicht.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Martin Peters hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.