Lohnt sich eine Veränderung? Funktioniert ein Ansatz wirklich? Das können wir oft nicht durch bloßes Nachdenken herausfinden. Attraktivität und Plausibilität sind nett, gar notwendig - aber hinreichend sind sie nicht, damit wir Aufwand für etwas Neues treiben. Deshalb bleibt so manches eine interessante Idee und der Rest einfach beim Alten.
Das ist schade, oder? Denn damit verschenken wir ja Chancen, dass “es” besser wird. Schneller, leichter, angenehmer… das kriegen wir nur, wenn wir uns auf Neues einlassen.
Solchen Verbesserungswünschen steht aber natürlich der Wunsch nach Sicherheit gegenüber. Wir wollen ja durch Neues nichts verlieren, das wir schon haben. Sonst wird es nicht besser, sondern nur anders - und wir haben Aufwand getrieben. Das wäre auch schade, oder?
Verbesserung und Erhalt des Ist-Zustands stehen sich gegenüber. Aber nicht nur im Patt. Denn der Erhalt gewinnt, weil sich durch Inaktivität ja nichts verändert.
Angesichts der Ungewissheit, ob die Implementierung einer Idee wirklich zu Verbesserungen führen würde, und der Verständlichkeit des Erhaltungswunsches, stellt sich die Frage, wie denn aber doch dem Verbesserungspotenzial eine Chance gegeben werden könnte.
Ich denke, da helfen Experimente. Genau wie in der Wissenschaft geht es ja darum, eine Hypothese zu überprüfen. Mehr ist eine Idee, ein Veränderungsvorschlag, ein neuer Ansatz ja zunächst nicht. Selbst nicht, wenn die Idee woanders schon tausendfach ihr Versprechen eingelöst hat.
Nachdenken kann nicht helfen und muss nicht helfen. Ob Agilität, reactive programming, NoSql, Flow-Design, Continuous Build, TDD as if you meant it usw. usf. etwas für Sie sind, stellen Sie nur fest, indem Sie es ausprobieren.
Ausprobieren klingt für mich allerdings ein bisschen unverbindlich. Deshalb sage ich Experiment. Der Unterschied liegt in der Ernsthaftigkeit. Beim Ausprobieren tun Sie nicht mehr, als dass Sie an einer Sache in eng begrenztem und geschütztem Umfeld herumspielen. Das ist nicht schlecht und steht immer am Anfang. Doch der Erkenntnisgewinn ist begrenzt.
Bei einem Experiment hingegen, geht´s ans Eingemachte. Das findet für mich in vivo statt. Da wird nicht ausprobiert, sondern real eingesetzt. Man nimmt die Idee ernst und implementiert sie. Allerdings nur für einen überschaubaren Zeitraum.
Insofern fordert man sich selbst heraus. Schafft man es, sich auf die Idee einzulassen?
Und die Idee wird auch wirklich herausgefordert. Schafft sie es, ihre Versprechen einzuhalten?
Ideen kommen oft “absolut” daher, mit großem Anspruch und der Suggestion, es ginge nur ganz oder gar nicht. Davon sollten wir uns aber nicht beeindrucken lassen. Jedenfalls heute nicht mehr. Ideen stehen in einem Wettbewerb. Und da gilt: Die bessere mögen gewinnen. Dafür jedoch müssen wir ihnen eine Chance geben. Aber nicht nur nebenbei, von ernsthaft.
Matt Cutts hat dafür ein leidenschaftliches Plädoyer bei TED gehalten:
Damit geht der Druck raus aus den Entscheidungen für oder gegen Ideen. Wir müssen nicht einmalig den Kurs auf Gedeih und Verderb ändern. Nein, wir können es für einen begrenzten Zeitraum tun. “Nur” 30 Tage reichen für vieles aus.
30 Tage TDD, 30 Tage daily standups, 30 Tage ein Entwicklertagebuch, 30 Tage 10 Seiten in einem Fachbuch lesen, 30 Tage im Team ein Code Review, 30 Tage eine neue Codierungsrichtlinie… und währenddessen, aber vor allem anschließend reflektieren. Wie fühlt es sich an, eine Idee ernsthaft 30 Tage lang zu implementieren?
Bei www.my30dc.com gibt es dafür sogar ein Tool. Wenn da das Geek-Herz nicht höher schlägt ;-)
Ich habe da auch gerade eine “30 day challenge” laufen. Mein Experiment ist, nur während 8 Stunden pro Tag zu essen. Das soll sich positiv auf Wohlgefühl und Gewicht auswirken. Ob das stimmt? Keine Ahnung. Ich werde es nach 30 Tagen wissen. Durch Nachdenken könnte ich das nicht herausbekommen.
Also: Lassen Sie sich von Ideen nicht ins Bockshorn jagen. Fühlen Sie sich nicht belastet durch Zweifel und endgültigen umfassenden Adoptionsaufwand.
Wenn sie Ihnen halbwegs interessant erscheinen, machen Sie “nur” ein Experiment. Möglichst unverzüglich, solange die Motivationsenergie noch hoch ist. Das geht persönlich oder im Team. Nutzen Sie die “30 day challenge” Plattform oder schreiben Sie ein bisschen Experimentiertagebuch ein einem Notizbuch. Egal. Tun und reflektieren sind das Wichtigste. Taten statt Warten.
Ich habe auch noch eines zum Thema Programmierung gestartet. Im Verlauf von 30 Tagen will ich einen Web-Dienst realisieren. Sie können meinen Fortschritt im github Repository verfolgen. Dort sammle ich nicht nur Code, sondern auch Tagebucheinträge.
2 Kommentare:
Spannender Ansatz. Finde es aber bedenklich neue Ideen in bestehende Systeme einzubinden.
Ich teste Neues in der Regel in eigenen Projekten. Mindestens bis ich eine solide Basis für ernsthafte Umsetzung habe.
Es geht nicht darum, halsbrecherisch zu sein, sondern ernsthaft. Das kann man, wenn man an speziellen Experimentalprojekten etwas ausprobiert. Aber das, was man daran ausprobiert, ist oft begrenzt. Es behält den Nimbus des "Spielens". Und für manche Veränderung wird das auch niemand erlauben. Wo wäre das nicht reale Projekt, an dem ein Team Scrum ausprobiert?
Nein, ich bleibe dabei: Wirklich ernst werden Experimente erst, wenn auch etwas auf dem Spiel steht. Das ist ja der Trick: auch dann immer noch im Experimentiermodus sein zu können.
Aber das gehört für mich zur Agilität im weitergefassten Sinn: nichts als abgeschlossen, als endgültig eingeführt zu betrachten. Experimente sind insofern für mich auch keine Besonderheiten, sondern der Normalfall.
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.