Craftsmanship & Agilität. Mit Craftsmanship und Professionalität eine agile Welt erschaffen

Von: Alexandre Soler-Sanandres

Warum wir Agile zum Scheitern bringen werden

Was traue ich mich hier, eiskalt so was zu schreiben! Ist das schlimm mit mir! Wie kann ich nur behaupten Agile würde Scheitern? Nun, ich will das nicht einfach so stehen lassen.

Über Agilität und Professionalität

Viele Unternehmen in der Softwareentwicklungsbranche sind in den letzten Jahren auf Agile umgestiegen, mit mehr oder weniger Erfolg. Die Tatsache, dass man agile Methoden im Unternehmen einführt, bedeutet leider noch lange nicht, dass man agil ist. Agilität ist eine Denkweise, eine Art zu agieren und sich zu verhalten. Man ist nicht agil, weil man die Methode XYZ verwendet und schon gar nicht, weil man Unmengen an Zetteln in verschiedenen Farben an der Wand kleben hat. Meiner Meinung nach ist professionelle Softwareentwicklung auch so ein Fall. Es gibt Menschen, die denken Programmierer wären einfach die Leute, die den Code in die Maschine eintippen. Fachliches Wissen und Führung sind viel wichtiger für das Unternehmen, als diese armen, im dunklen Keller lebenden Code-Monkeys. Softwareentwickler zu sein ist viel mehr als nur Programmieren. Codes zu schreiben ist zwar ein wichtiger Bestandteil der Arbeit, aber bei Weitem nicht der Einzige. Ein professioneller Softwareentwickler zu sein, deckt viele verschiedene Facetten ab.
Professionelle Softwareentwicklung bedarf auch einer besonderen Denkweise!

Erfolgreiche Projekte: Die Farce

Wer sich mit dem Chaos Report beschäftigt hat, wird wissen, dass viele der Softwareentwicklungsprojekte auf dieser Welt nicht gerade erfolgreich abgeschlossen werden. In der Tat nur etwa 30 % der Projekte verdienen am Ende das Prädikat erfolgreich. Ich bin der Meinung, die Zahlen könnten noch schlimmer sein als in der Studie präsentiert. Das liegt an der Definition von erfolgreich. Laut der Studie ist ein Projekt erfolgreich, wenn es beendet wurde, innerhalb der geplanten Zeit, ohne das geplante Budget zu überschreiten und mit allen Features, die ursprünglich geplant waren.
Das ist eine recht arme Definition für erfolgreich. Nehmen wir eines dieser erfolgreichen Projekte und fragen uns: Was ist, wenn wir mit Fehlern überhäuft werden, die niemand bis jetzt entdeckt hatte? Was ist, wenn unsere Kunden neue Features brauchen, wir aber nicht in der Lage sind sie hinzuzufügen, oder es zu lange dauern würde, sie zu implementieren? Was ist, wenn sich niemand mehr traut den Code anzufassen, um bloß nichts kaputt zu machen? Unsere Kunden werden unzufrieden. Ist das wirklich ein erfolgreiches Projekt? Meiner Meinung nach nicht! Aber wir machen ja agil, wie kann das sein? Agilität kann man nicht machen, man ist agil, oder auch nicht, oder nur zum Teil. Es wird weiterhin das Blame Game gespielt, an der Kultur hat sich nichts geändert. So kann es eben nicht funktionieren. Kein Wunder, dass sich Stimmen gegen Agilität erheben. Agile ist bestimmt nicht die Lösung aller Probleme. Es gibt durchaus Situationen, in denen die klassischen Entwicklungsmethoden mindestens genauso gut funktionieren, aber ich schweife ab.

Komplexität

Wir kennen ja die Geschichten von Toyota und so imposant, wichtig und lehrreich sie auch sind, wir bauen keine Autos, wir erstellen Software. Es geht eben nicht um die Software selbst, sondern um die Menschen, die sie erstellen. Menschen sind von Natur aus abgeneigt, Änderungen anzunehmen. Es ist also auch kein Wunder, dass es einige Leute gibt, die der Meinung sind, Agile funktioniert nicht.
Meiner Meinung nach ist Neugier eine der wichtigsten Eigenschaften, die man braucht, um gute Software zu entwickeln und eben diese Neugier fehlt mir bei einigen diese Gegenstimmen. Aussagen a là “Das haben wir schon immer so gemacht” oder “Das dauert alles viel zu lang” sind in manchen Fällen nur vorgeschobene Entschuldigungen, wenn die Neugier und der Wille, es ernsthaft zu versuchen, schon lange nicht mehr da sind. Das ist wirklich schade. Software zu erstellen ist eine komplexe Angelegenheit. Kreativität, ja sogar Kunst, ist hier oftmals gefragt, nicht nur Ingenieurwesen. Die Verfahren, welche in früheren Zeiten so hilfreich gewesen sind, helfen uns hier eher selten und auch hier sei erwähnt: Agilität bedeutet nicht, einen Wasserfall in einen Monatssprint reinzupacken.
Agile kümmert sich darum, welche Prozesse wir verwenden, wie wir miteinander besser arbeiten können. Für mich ist aber eine der wichtigsten Eigenschaften von Agile, dass es sich darum zu kümmern versucht, dass wir DAS RICHTIGE implementieren. Was Agile uns nicht zwingend beantwortet ist, wie wir das auch RICHTIG implementieren sollen.
Es ist unsere Aufgabe als Softwareentwickler, die bestmöglichen Techniken und Methoden zu kennen, um hochqualitative Software zu erstellen.
Wenn Agile also so eine tolle Sache ist und wir agil arbeiten, wieso ist die Qualität unsere Software nicht schlagartig nahezu perfekt? Wieso verschwinden die technischen Schulden nicht? Wieso haben wir die gleichen oder ähnlichen Probleme wie in der Prä-Agilen Ära?
Die Antwort auf diese Fragen ist nicht schwer. Niemand wird über Nacht und ohne jegliche Anstrengung besser. Prozesse zu ändern ist wichtig, aber wenn wir dabei vergessen, uns auch technisch weiterzuentwickeln, haben wir ein Problem. Kurz gesagt: Ein guter Prozess ist wichtig, aber hochqualitative Software auch. Wenn wir bessere Software produzieren wollen, dann müssen wir eben erst mal selber bessere Entwickler werden und das ist harte Arbeit. Es ist unsere Pflicht, die bestmöglichen Ergebnisse für unsere Kunden zu erzielen.

Wie soll das gehen?

Wie oft habe ich meiner Chefin gesagt, dass ich versuche, all die, in ihren Augen, wichtigen Aufgaben zu erledigen, für die ich eigentlich im Moment keine Zeit habe, weil ich mich eben um andere, nicht aufschiebbare, Probleme kümmern müsste? Viel zu oft muss ich zugeben. Man wird mir sagen, es ist schließlich dein Job es zu versuchen. Da bin ich mittlerweile anderer Meinung. Es ist mein Job und meine Pflicht es zu sagen, wenn irgendwas nicht machbar ist. Das Problem beim Versuchen ist, dass ich damit meine, dass ich es eben versuche, aber verstanden wird nur Ja, er macht das. Dann müssen Überstunden her, alles muss schnell gehen, die Qualität bleibt auf der Strecke, aber das holen wir ja später nach (übrigens für die, die es noch nicht wissen, später bedeutet meistens nie). Dadurch passieren uns selbstverständlich unbemerkt mehr Fehler, wir liefern, es kracht, unsere Kunden sind unzufrieden. Das alles nur, weil man versucht.
Nein zu sagen ist wichtig. Wenn es nicht möglich ist, ist es eben nicht möglich. Aber einfach zu sagen “Nein, das geht nicht” ist keine professionelle Haltung. Dazu gehört, nach Lösungen zu suchen, Kompromisse auszuhandeln, eben herauszufinden, wie viel kann bis dahin geschafft werden, ohne dass die Qualität darunter leidet.
Nicht nur Softwareentwickler können einiges dazu lernen, auch Führungskräfte sollten das. Sie sollten mit dem Team und für das Team arbeiten. Die klassischen, rigiden Kommandostrukturen funktionieren nicht so gut im kreativen Bereich. Command & Control ist out 😊. Selbstverständlich gibt es Geschäfts- und andere Ziele, die erreicht werden wollen. Jedoch finde ich, dass eine der wichtigsten Aufgabe der Führungskraft ist, das Team produktiv, motiviert und „gesund“ zu halten. Auch in diesen Bereichen sollten sie sich weiterbilden.

Der Weg zum Erfolg

Unsere Aufgabe ist Software zu produzieren, die das Leben unserer Kunden vereinfacht. Es muss unser Anspruch sein, dass diese Anwendungen eine hohe Qualität besitzen. Leider geschieht es viel zu oft, dass wir aus unterschiedlichen Gründen nur Mittelklasse-Software erstellen. Wir sollten uns zum Ziel setzen, hohe Qualität in allen Bereichen zu erreichen. Nicht nur die äußeren und sichtbaren Merkmale, sondern auch die innere Qualität der Software muss deutlich erhöht werden, wo es möglich und sinnvoll ist.
Wie Code aussieht, ist nicht wichtig. Hauptsache es geht. Ich bin diese Aussage leid! Ich halte diese Meinung für obsolet, wenn nicht sogar für gefährlich. Es gibt viele Möglichkeiten, die innere Qualität unserer Software zu verbessern. Ihr möchtet Beispiele? Natürlich, hier sind einige:

• Four Rules of Simple Design
• Test first, Testautomatisierung, testgetriebene Entwicklung, Akzeptanz testgetriebene Entwicklung
• Refactoring
• Continuous Integration
• Pair- und Mobprogramming
• Design Patterns und die SOLID Prinzipien

Die Liste ist bei Weitem nicht komplett, es gibt noch viele andere Techniken, Prinzipien und Methoden, die angewandt werden können, um diese innere Qualität deutlich zu erhöhen. Die oben genannten Methoden sind momentan eine der besten, die wir haben und trotzdem werden sie viel zu selten eingesetzt. Warum ist das so? Ich kann mir das nicht erklären. Wir sollten uns damit beschäftigen, sie zu erlernen, zu verstehen, wie sie funktionieren und vor allem warum sie funktionieren.
Wir sollten uns unsere eigene Werkzeugtasche zusammenstellen, mehrere Methoden parat haben, um ein Problem zu lösen. Wenn ich nur mit dem Hammer umgehen kann, muss jedes Problem eben ein Nagel sein und das klappt meistens nicht allzu gut. Es ist ein ständiges Dazulernen. Methoden ändern und entwickeln sich, neue Methoden treten in Erscheinung. Lernt. Probiert, ob sie einen Mehrwert für euch haben, aber nutzt sie nicht nur, weil sie gerade Hip sind. Nicht aus Prinzip ändern. Sondern nur, wenn es tatsächlich etwas bringt.

Zusammengefasst

Wir machen Agile zur Hälfte und wundern uns, dass es nicht so funktioniert wie versprochen. Wir ändern die Prozesse um uns herum und vergessen dabei, unser technischen Knowhow zu erweitern und zu verbessern.
Denkt bitte an den Spruch am Anfang des Artikels. Wir schreiben unsere Software, so wie wir es immer getan haben, wir machen immer und immer wieder das Gleiche und erwarten andere Ergebnisse, weil der Prozess sich geändert hat. Ich halte Einstein für einen klugen Menschen, und wenn er meint, dass das nichts bringt, bin ich geneigt, ihm zu glauben, abgesehen davon hat mir meine Erfahrung gezeigt, dass in diesen Worten mehr Wahrheit steckt, als uns manchmal lieb ist.

Die aktuelle Zukunft

Einiges muss geschehen, damit wir das Ganze zum wirklichen Erfolg bringen können. Als Erstes wären da die Führungsstrukturen. Führungskräfte dieser Welt: Vergesst Command & Control, lernt einen modernen Führungsstil, Zuckerbrot und Peitsche zerstört die Motivation unsere Mitarbeiter. Es gibt unterschiedliche Möglichkeiten zeitgemäß zu führen. Es würde leider den Rahmen dieses Artikel sprengen, auf diese näher einzugehen.
Weiterhin sollten wir als Softwareentwickler über die Autonomie verfügen zu entscheiden, was wir tun. Schlagwörter wie Pull-Prinzip oder die 20%-Regel sind das Motto. Auch das Thema Arbeitszeiten ist hier relevant, dass 9 bis 5 Prinzip ist längst überholt. Heimarbeitsplätze und flexible Arbeitszeiten sind hier die Devise. Auch die Freiheit zu haben, den für die Lösung des Problems am besten geeigneten Technologie-Stack zu wählen und nicht auf ein festes Framework festgenagelt zu werden. Kreativität erreicht man selten, indem man die Lösungsmöglichkeiten einschränkt.
Wir müssen uns weiterbilden. Das ist kein nice to have. Ich glaube wirklich daran, dass kontinuierliches Lernen der einzig erfolgsversprechende Pfad ist, um die Qualität und Güte unserer Software auf das nötige Niveau zu heben. Selbstverständlich ist Perfektion eine Asymptote, absolute Perfektion kann nicht erreicht werden, aber wir sollten uns so nah wie möglich an sie herantasten. Wir müssen unsere Fähigkeiten erweitern und verbessern, auch wenn der Weg dorthin hart ist. Für ein motiviertes Team ist es auch nötig, ein Verständnis dafür zu entwickeln, wozu wir etwas tun und auch das Gefühl zu haben, beitragen zu können. Jeder Mensch braucht Ziele und diese müssen nicht zwingend nur wirtschaftlicher Natur sein. Es hat auch viel damit zu tun, wie man miteinander kommuniziert. Die Art und Weise wie man miteinander umgeht und redet, beeinflusst, wie wir wahrgenommen und verstanden werden. Wir haben viele Möglichkeiten uns zu verbessern. Lernt neue und bessere Techniken. Vertieft eure Kenntnisse in dem, was ihr bereits kennt. Das kann man auf unterschiedliche Wege erreichen: Lest Bücher, Blogs und / oder Zeitschriften. Übt kontinuierlich eure Fähigkeiten, z. B. in Form von Coding Katas, Coding Dojos oder Coderetreats. Werdet Teil der Open Source Community oder unterhaltet eure eigenen, privaten Projekte! Kommuniziert, tauscht euch aus, beteiligt euch an Communities of Practices, Meetups, Lerngruppen, … die Möglichkeiten, die zur Auswahl stehen, sind vielfältig.
Jeder Mensch erwartet exzellente Qualität von den Produkten, die er nutzt. Es ist unsere Aufgabe uns darum zu kümmern, die bestmögliche Qualität in unsere Produkte einfließen zu lassen. Das bedeutet, sowohl die externen als auch die internen Qualitätsmerkmale zu berücksichtigen. Klarheit, Änderbarkeit, Nutzbarkeit, Zweckdienlichkeit, etc. sind genauso wichtig wie Funktionalität und Optik.
Wir brauchen technische Exzellenz und müssen diese auch anwenden, um die Voraussetzungen zu schaffen, in denen die agile Entwicklung seine Versprechen auch einhalten kann. Es liegt in unserer Hand, ob wir diesen Prozess unterstützen oder nicht.

Ohne uns geht das nicht!

Ihr seid ebenso verrückt nach IT, Software und Tech-Themen und habt Lust, Teil unseres Entwickler-Teams zu werden, hier geht´s zu unseren offenen Stellen: https://www.datev.de/web/de/karriere/geschaeftsbereiche/it/.

Photo by You X Ventures on Unsplash