Nach meinem kleinen Exkurs in die Theorie hinter nachhaltiger Software(entwicklung) und weiter zur Praxis, möchte ich diesen Beitrag vollständig der best practice widmen.
Hier könnte man schon stutzig werden, und so auch ich, ob es wirklich die eine und beste Praxis gibt. Wie gut der hier beschriebene Techgenossen-Ansatz ist, entscheidet Ihr.
Nachfolgend möchte ich jedenfalls ein paar Insights zu nachhaltiger Software(entwicklung) aus dem Erfahrungsschatz der Techgenossen mit Euch teilen.
Eine Frage des Mindsets
Die Techgenossen, das ist ja nun ein bunter Haufen Unikate. Charakterköpfe mit Geschichten. Und alles davon bringen sie in ihre Zusammenarbeit ein – Haltung, Köpfchen und Erfahrung. So wird ein Softwareprojekt schnell mal nachhaltig, was anderes käme ihnen auch nicht groß in den Sinn. Es ist eine Frage des Mindsets.
Holistisches Denken hat keinen Anfang und kein Ende. Und so ist es nur folgerichtig, dass die Techgenossen Nachhaltigkeit sowohl bei der Softwareentwicklung als Prozess als auch der Software als Produkt mitdenken. Ich habe meine liebgewonnen Techgenossen gefragt, was ihnen dabei besonders wichtig ist und möchte ihre Antworten nun mit Euch teilen.
Die zwei P’s
“Leider ist das Nachhaltigkeitsbewusstsein in der IT-Branche meinem Eindruck nach, wenn überhaupt, eher produkt- und (noch) nicht prozessbezogen.”
Das schrieb ich noch vor wenigen Tagen in meiner “Einführung” zu dem Thema. Da passt es sich umso besser, dass sich die Techgenossen Erkenntnisse vorrangig auf das Prozedurale beziehen. Das ist wahrscheinlich am Gewinn bringendsten, aber lest selbst.
Und die vier A’s
Clustern lassen sich die gewonnen Insights in vier Kategorien – mit A: in den Anspruch der (Informatik-) Gesellschaft, in die Ausrichtung der Idee, in die Arbeitsweise der Organisation und in die Ausführung des Teams. Aber was heißt das? Wie erreichen wir mehr Nachhaltigkeit in der Softwareentwicklung?
1. Der Aaaanspruch der (Informatik-) Gesellschaft
Wenn Sotwareentwicklung nachhaltiger werden soll, müssen wir das wollen. Wir als Gesellschaft, egal wie IT-affin jede*r Einzelne von uns ist. Wir können die bisherige Entwicklung nicht widerrufen, aber wir können sie weniger unnachhaltig machen und in Zukunft mehr auf Nachhaltigkeit achten.
Von bestimmt der Hälfte der Techgenossen kam diesbezüglich die Forderung nach Qualitäts- und Nachhaltigkeitsstandards in der IT und entsprechender Codes of Conduct. Hier wären die Kriterien aus dem vorangegangenen Blogbeitrag schon mal ein Einfang.
Damit einher und zur Verinnerlichung solcher Standards geht der Ruf nach einer problemwussten IT Ausbildung. Die drei Dimensionen der Nachhaltigkeit müssen fest im Lernplan verankert sein. Dass Softwareentwicklung neben wirtschaftlichen Auswirkungen auch ökologische und soziale Konsequenzen hat, darf keine zufällige Erkenntnis sein oder normalisierte Unkenntnis bleiben.
2. Die aAaausrichtung der Idee
Einmal verinnerlicht dürfte sich die so Techgenossen typische Frage nach Sinn und Nutzen der Idee wie von selbst aufdrängen. Handelt es sich um ein berechtigtes Softwarevorhaben? Was bringt es wem? Und weiter, wie steht es um die User-Orientierung? Ist die Software auf die tatsächlichen User-Bedürfnisse abgestimmt? Ist sie hilfreich und bietet sie, was sie muss – nicht mehr und nicht weniger? Da darf eine Software schon Feature-genügsam sein. Am besten ist sie noch systemkritisch und nicht -erhaltend. Da hüpft das nachhaltige Techgenosen-Herz.
3. Die aaAaarbeitsweise der Organisation
Bei den zwei letzten A’s ist das Prozedurale offensichtlicher. Hier geht es um die generelle Arbeitsweise und die Ausführung im Spezifischen. Mehr Nachhaltigkeit reinbringen kann man da, nach Techgenossen-Erfahrung, durch leanes und iteratives Arbeiten mit Paketen. Entwickelt wird nur, was im nächsten Schritt entwickelt werden muss. Dafür müssen die kritischsten Annahmen geprüft werden. Was braucht es wirklich? Und dann liefern. Also Minimal-Viable-Product Paketbote spielen.
Vorbei sind die Wasserfall-Zeiten. Jetzt wird geprototypt.
4. Die aaaAusführung des Teams
Und wie man letztlich nachhaltig programmiert, fragt Ihr? Da stehen Pairing, Dokumentation, Tests, Tests und nochmal Tests hoch im Techgenossen-Kurs. Ganz einfach, da geht es um die Wart-, Wiederverwend- und Erweiterbarkeit von Software – also um die Vermeidung von Legacy Code! Programmiert wird schließlich nicht für die Tonne. Da wandert höchstens mal ein Paketchen hin, nicht aber ein ganzes Projekt.
Beispiel gefällig?
Die Techgenossen betreiben neben der Auftrags- und Partnerarbeit auch eigene Tools, allen voran den Lunch-O-Mat und ihr Tool zum systemischen Konsensieren.
Der Lunch-O-Mat würfelt zufällig Mittagsrunden in großen Unternehmen und Organisationen aus. Während HR und Chefs bei ähnlichen Tools dem “Zufall” ein wenig nachhelfen können, indem sie die Teilnehmenden kategorisieren, geht das beim Lunch-O-Mat nicht. Denn nur so ist der Zufallszauber ehrlich gewährleistet.
Beim Tool zum systemischen Konsensieren werden Feature-Wünsche Dritter nur umgesetzt, wenn es sie wirklich als Nutzungsfall gibt und sie tatsächlich ein Problem lösen. Nicht nur, weil es sie hypothetisch geben könnte oder es nett wäre, das zu haben. Hierfür wollen die Techgenossen jetzt eine User-Community aufbauen und das lebende Produkt weiterentwickeln.
Zu guter Letzt
Was ich aus den Techgenossen Antworten noch rausgehört habe und keinem A zuordnen konnte: Die IT steckt noch in den Kinderschuhen. Was nicht ist, kann also noch werden. Wie gesagt, wenn wir es wirklich wollen.
Dabei müssen wir der Digitalität vielleicht manchmal was (Soziales) entgegensetzen, zumindest aber nicht immer mehr und immer Neues entwickeln. So sollten wir vermehrt Bestehendes und andere strategisch unterstützen. Und auch nicht jede Mode mitgehen, sondern auf etablierte Ökosysteme zurückgreifen. Amen.
