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

18.01.2017 - Lesezeit ca. 10 Min - 2100 Wörter

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, bedeuten 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. Code zu schreiben ist zwar ein wichtiger Bestandteil der Arbeit, aber bei Weiten 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 eine dieser erfolgreichen Projekte und fragen wir uns dann: 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 dauert ewig, bis sie drin sind? 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 nicht 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 und 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.

Meine 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 Willen es ernsthaft zu versuchen schon lange nicht mehr da sind. Das ist wirklich schade.

Software zu erstellen ist eine komplexe Angelegenheit. Meistens bewegen wir uns in Bereichen, wo bis jetzt keine war. Kreativität, ja sogar Kunst ist öfters gefragt, nicht nur Ingenieurwesen. Die Verfahren, welche in früheren Zeiten so hilfreich gewesen sind, helfen uns hier eher selten und sei auch hier mal wieder erwähnt: Agilität bedeutet nicht 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 kümmern versucht, dass wir DAS RICHTIGE implementieren . Was Agile uns nicht zwingend beantwortet, ist, wie wir das auch noch 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 machen, 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 als in der Prä-Agilen Ära?

Die Antwort auf diese Fragen ist nicht schwer. Niemand wird über Nacht und ohne jegliche Anstrengung besser. Die 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: Ich versuche es, als sie vor der Tür stand mit irgendwelche superwichtige, sofort zu erledigenden Aufgaben, für die ich aber gerade im Moment keine Zeit habe, weil ich mich eben um andere nicht aufschiebbaren Problemen kümmern soll? 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 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, unser 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 es nach Lösungen zu suchen, Kompromisse auszuhandeln, eben herauszufinden wie viel kann bis dahin geschafft werden ohne das 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 und auch in diesen Bereichen sollten sie sich weiterbilden.

Der Weg zum Erfolg

Unsere Aufgabe ist Software zu produzieren, die das Leben unsere 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, da 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:

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 genannte Methode sind momentan unter den besten die wir haben und trotzdem werden sie viel zu oft 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. Lerne. Probiere, ob sie einen Mehrwert für euch haben, aber nutzte sie nicht nur, weil sie gerade Hip sind. Nicht aus Prinzip ändern. Sondern nur, wenn es tatsächlich was bringt.

Zusammengefasst

Wir machen Agile zur Hälfte und wundern uns, dass es nicht so funktioniert wie versprochen.

Wir ändern an den Prozessen um uns herum und vergessen dabei unserem 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 klügeren Menschen, und wenn er meint, dass das nichts bringt, bin ich geneigt ihn zu glauben, abgesehen davon hat mich 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 vergiss Command & Control, lerne modernere Führungsstile, Zuckerbrot und Peitsche zerstört die Motivation unsere Mitarbeiter. Es gibt unterschiedliche Möglichkeiten zeitgemäß zu führen . Es wurde leider den Rahmen dieser Artikel sprengen, auf sie 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, die 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, in dem 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 und der Weg zur Meisterschaft, das einzige erfolgsversprechende Pfad ist, um die Qualität und Güte unsere Software auf dem nötigen 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 ihr herantasten. Wir müssen unsere Fähigkeiten erweitern und verbessern, auch wenn der Weg dahin hart ist und uns vieles abverlangt.

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 wirtschaftliche 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. Lerne neue und bessere Techniken. Vertiefe deine Kenntnisse in dem, was du bereits kennst. Das kann man auf unterschiedliche Wege erreichen: Lese Bücher, Blogs und / oder Zeitschriften. Übe dauernd deine Fähigkeiten, z. B. in Form von Coding Katas, Coding Dojos oder Coderetreats. Nimmt Teil an die Open Source Community oder unterhalte deine eigenen privaten Projekte! Kommuniziere, tausche dich aus, nimmt Teil an Communities of Practices, Meetups, Lerngruppen, … die Möglichkeiten, die zur Auswahl stehen, sind vielfältig. Es sollte möglich sein etwas zu finden, womit auch du dich wohlfühlst und Spaß dabeihast.

Jeder Mensch erwarten exzellente Qualität von den Produkten, die er bekommt.

Es ist unsere Aufgabe uns darum zu kümmern, die höchstmö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 wichtige Eigenschaften, 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 unsere Hand, ob wir diesen Prozess unterstützen oder nicht.

Ohne uns geht das nicht!


Wenn du das Lesen des Artikels genossen hast, würde ich mich freuen, wenn du es teilst. :-)