Als Follow-Up zum vorhergehenden Artikel über Lernen nehmen wir jetzt einmal an, dass Lernen das Wesentliche in der Softwareentwicklung ist. Aus dieser Sicht stellt sich Erfolg vor allem dann ein, wenn das Team, das einmal (möglichst kompetent) ausgesucht ist, optimale Bedingungen zum Lernen hat. Diese Bedinungen möchte ich in diesem Artikel näher betrachten.
Es gibt hier sehr viele einschlägige Erkenntnisse aus der Pädagogik und Lernforschung. Ich bin hier natürlich kein Experte, finde es aber interessant in diesem Bereich tiefer zu schauen.
Meine Liste der optimalen Lernbedingungen lautet wie folgt:
- Motivation
- Kultur
- Regelkreis
Motivation
Bevor ich auf Motivation eingehe, möchte ich eine unangenehme Wahrheit loswerden. Lernen ist per se erst einmal ziemlich demotivierend. Hierzu ein paar Diagramme aus der Lernforschung mit Mäusen oder Ratten, die zeigen, dass man schon Frustrationstoleranz mitbringen muss, um nachhaltig lernen zu wollen. Der Punkt den ich damit machen möchte, ist, dass der primäre Faktor schlicht und einfach die Motivation der Leute ist, das harte Geschäft des Lernens anzugehen.
Gehen wir also davon aus, dass kontinuierliches Lernen nur dann stattfinden wird, wenn Leute wirklich besser werden wollen, sprich top motiviert sind. Daraus leitet sich gleich die nächste Frage ab: Was ist es, was Leute motiviert, ihre Sache richtig toll machen zu wollen?
Das folgende Video von Dan Pink zeigt auf eine Art, die man immer wieder gerne ansieht, was ein Team braucht, um wirklich motiviert sein zu können. Die Schlüsselbegriffe sind:
- Autonomy (Autonomie)
- Mastery (Meisterschaft)
- Purpose (Sinn)
Motiviert werden Individuen also sein, die autonom entscheiden können und nicht andauernd um Erlaubnis fragen müssen (Autonomy).
Befriedigung kann aus dem Stolz auf die eigene Meisterschaft und aus dem Fortschritt selbst schon kommen. (Mastery)
Schließlich wollen Menschen einen Sinn im großen Ganzen sehen und nicht zum Werkzeug degradiert sein (Purpose).
Klar unterscheiden sich die einzelnen Typen darin, was für sie wichtiger ist und vor allem, was jeder Punkt im Detail für jedes Individuum bedeutet. Aber generell sind diese drei Faktoren schon ziemlich brauchbar, um sich dem Phänomän Motivation zu nähern.
Ein konkretes Beispiel aus meiner Managementpraxis
Eines unserer Teams sollte eine WebUI für eine existierende Datenschnittstelle entwickeln. Die Funktionalität der Schnittstelle stand vor dem Projekt fest. Für alles musste es eine UI geben. Darum wurde auch die Funktionalität der UI außerhalb des Teams in einer Analyse festgelegt. Die Schnittstelle wurde offshore entwickelt und die Kommunikation mit den Entwicklern des Backends war von Projektmanagern, die das Budget im Backend bewachen mussten, limitiert. Es gab außerdem benannte Rollen – den Projektmanager und den Architekten. Jeder folgt der Spec und ggfs. technisch dem Architekten, inhaltlich dem Projektleiter. Ideen zur Verbesserung, die eine Änderung auf der anderen Seite brauchen, sind blockiert. Mit der Autonomie war es daher in gewisser hinsicht nicht sehr weit her.
Die Schnittstelle hatte technische Mängel und zwang unsere Leute in diesem Bereich handwerklich unter ihren Standards zu arbeiten. Hier wurde der Drang zur Mastery enttäuscht.
Zu guter Letzt haben einige der Entwickler den Sinn des Auftrags in Frage gestellt. Es bestand das Risiko, dass die Featurefülle der Spezifikation von zukünftigen Nutzern nicht angenommen werden würde. Kontakt zu echten Usern, die eventuell Dankbarkeit zeigen würden, war leider nicht vorhanden. Da die UI nur ein Teil des Ganzen war, konnte das Team auch nicht so leicht auf das Schaffen von ganzheitlichem Wert stolz sein. Das Sinnempfinden dieser Mannschaft war also vom Umfeld nicht optimal unterstützt.
Dennoch hat sich das Team nach Kräften motiviert. Wie haben sie es angestellt? Nun, sie haben ihre Energie in ein gehöriges Maß an technischer Excellenz gesteckt. Es gab automatische Tests in Hülle und Fülle, generell das Level an Automatisierung hatte Referenzcharakter. Zudem wurde eine funky funktionale Programmiersprache eingesetzt, deren Twists alle begeistert haben. Aus Managersicht heikel: Viele dieser Techniken waren projektunabhängig und neu. Es musste also viel Technik gelernt werden. Eventuell zu viel. Hätte ich mich als Manager aber gegen diese Dinge gestellt, wäre das Maß an Autonomie noch mehr in den Keller gefahren und die letzte verbleibende Bastion der Motivation – die Mastery auch blockiert. Die Gefahr wäre real gewesen, dass die Leute begonnen hätten, Dienst nach Vorschrift zu machen.
Dieses Beispiel zeigt anhand aller drei Faktoren (Autonomy, Mastery, Purpose), wie doch recht alltägliche Bedingungen im Softwarebusiness eine Situation hervorrufen können, die demotivierend wirkt. Und sie zeigt auch, wie ein Team sich die Motivation auf jeden Fall sucht, indem es sich typischerweise auf Meisterschaft verlegt (Autonomie und Sinn sind oft außerhalb der Einflusssphäre eines Entwicklerteams). Wenn ihre Entwickler also zu tolles und teures Zeug bauen, wäre es einen Versuch Wert, anstatt zu schimpfen, einmal die Bereiche Autonomie und Sinn zu adressieren.
Kultur
Umgang mit Fehlern
Was passiert, wenn jemand einen Fehler macht? Ist dies in der vorliegenden Kultur ein Hinweis darauf, dass dieses Individuum im Grunde fehl am Platz ist, oder ein Hinweis darauf, was der Mensch selber und die Organisation lernen kann? Letzteres Mindset ist natürlich dasjenige, was Lernen und Wachstum begünstigt. Siehe hierzu das gleichnamige Buch Mindset von Carol Dweck, dass ich sehr empfehlen kann. Carol Dweck zeigt hier, wie der so genannte Open Mindset, also die Grundhaltung die eigenen Fähigkeiten als Variable anzusehen, dazu führt, dass Menschen ihre Fehler als positive Hinweise auf ein besseres Verhalten nehmen, anstatt auf den Beweis ihrer statischen Unzulänglichkeit. Will eine Organisation den Open Mindset herbeiführen, muss sie darauf ausgerichtet sein, dass sich die Fähigkeiten der Individuen massiv verändern können. Das muss natürlich nicht heißen, dass man sich die Leute nicht mehr aussucht. Hierzu aber später mehr.
Kultur der Dankbarkeit
Eine andere Kulturfrage ist die der Dankbarkeit. Welche Rolle spielt in der Unternehmenskultur die Dankbarkeit, welche Rolle die Kritik. Keine Kritik ist Lob genug? Diese Kultur ist natürlich fatal für’s Lernen. Carol Dweck und so ziemlich jeder, der über’s lernen schreibt, sind sich einig: Positives Feedback ist wirksamer und nachhaltiger als negatives.
Aber Achtung: Dankbarkeit bei weitem nicht das selbe wie Lob. Dankbarkeit ist offen ausgesprochener Selbstausdruck. Jemand hat mir etwas erfüllt, ich zeige es ihm von mir. Das setzt voraus, dass ich mich freuen kann, dass es mir gut genug hierzu in dem Umfeld geht. Lob auf der anderen Seite richtet sich an den anderen mit einer Bewertung. „Das hast Du gut gemacht“. Der Lobende stellt sich außerhalb des Geschehens, im schlimmsten Fall sogar über den gelobten. Die Gefahr besteht, dass Lob als Zuckerbrot (im Gegenstück zur Peitsche) verstanden und auch gemeint wird. Die Autonomie und andere wichtige Beziehungseigenschaften gehen flöten.
Diese Unterscheidung ist übrigens eine wichtige Unterscheidung in der Gewaltfreien Kommunikation nach Rosenberg. Hier ein Video von 11 Minuten, in dem Rosenberg himself erklärt, was der Unterschied zwischen dem „Management Talk“ – Danke und der echten Dankbarkeit ist.
Regelkreis
Um gut zu lernen, sollte unser Vorgehen einem Regelkreis entsprechen. Diese Erkenntnis ist so alt wie zentral. Hierzu kennen viele den berühmten Deming-Cycle, der uns zu einem zyklischen Vorgehen anleitet, in dem bewusstes Planen, Handeln, Überprüfen des Erfolgs und die Verhaltensanpassung einen Kreis ergeben, in dem wir immer besser werden können. Natürlich geht das alles erst auf, wenn das Ziel und die Vision sehr klar und einleuchtend sind und man kommt mit diesen Formalitäten auch nicht so weit wie möglich, wenn die Kultur und die Motivation verhindernd wirken. Dennoch, im Deming Cycle steckt viel Weisheit.
Anstatt den bekannten Deming Cycle noch einmal zu erklären, möchte ich aus dem Abschnitt über optimales Lernen aus dem tollen Buch Influencer der Autorengruppe Vital Smarts referieren. Hier werden folgende Faktoren zum optimalen Lernen herangezogen:
- Kleine geplante und bewusste Schritte (small steps)
- Frühes representatives Feedback an Hand eines unmissverständlichen Ziels (early feedback against a clear standard)
- Bewußte, verhaltensorientierte Selbstbeobachtung beim häufigen wiederholten Üben (deliberate practice)
Ich kann das Buch nur empfehlen. Generell geht es hier nicht (nur) um Lernen sondern um Veränderung, wovon Lernen ja ein Subset ist (nämlich die Veränderung persönlicher Fähigkeiten).
Nur wie gehen wir in der Software kleine Schritte? Wie bekommen wir darüber repräsentatives Feedback? Wie können wir uns unser Verhalten bewußt machen und konkrete Verhaltensänderungen ableiten?
Scrum
Wir sollten Scrum machen. In diesem Framework wird im Grunde alles berücksichtigt, was in diesem Artikel gesagt wurde. Anders als das Lean Framework, welches in vielen Punkten sehr verwandt ist und auf die Optimierung des Wertfulsses abzielt, schafft Scrum mit den agilen Werten, den Idealen der Selbstorganisation und den relativ tief verstandenen Rollen ein relativ vollständiges Framework, um das Lernen bei der Entwicklung zu unterstützen.
Das Scrum Team als Motivator
Nehmen wir beispielsweise das Ideale Team in Scrum, das als autonomes und multidisziplinäres Team von Experten mittels Pull-Planung regelmäßig ganze Features mit ganzheitlichem Wert schafft. Klingt das nicht beinahe 1:1 wie die Forderung nach Autonomy – Mastery – Purpose?
Hinzu kommt noch die Diversität des multidisziplinären Teams. Es sind dann ganz andere Leute da, von denen man lernen kann. Diversität auch der Persönlichkeiten tut daher einem Team sehr gut. Hierzu mehr, wenn’s darum geht, wie man Teams aus der Perspektive des Lernens am besten baut.
Agile Werte als Grundlage zur Feedbackkultur
Nehmen wir dann die dem Scrum Framework zu Grunde liegenden fünf agilen Werte, bestehend aus:
- Communication
- Simplicity
- Courage
- Feedback
- Respect
Auch diese werden zu einer lernenden Feedback-Kultur mit der Erlaubnis mutig Fehler zu machen führen. Nur der Begriff Simplicity passt scheinbar nicht zu 100% in das bisher gesagte. Es zeigt sich, dass mein Artikel keine mathematische Theorie darstellt. Dennoch bin ich im Vertrauen, dass hier kein fundamentaler Widerspruch besteht. (Schließlich gilt ja: nur einfache Dinge lassen sich gut kommunizieren, lernen und auch leicht verändern, was das Lernen wieder fördert).
Product Backlog – Kleine Schritte
Die Idee, das Produkt im Product Backlog in möglichst kleine Schritte – Product Backlog Items – mit ganzheitlichem Wert zu zerlegen, passt 1:1 zu dem Lernideal aus Influencer, in kleinen Schritten zu lernen.
Planning und Review – ready -> done – optimales Feedback
In der Sprint Planung wählt das Entwicklerteam autonom einzelne Items aus. Der Product Owner vermittelt neben den benötigten Details für diese Items möglichst erlebbar, 3D und in Farbe das Ziel wie sie sein müssen um ganz fertig (done) zu sein. Das Item, das der Product owner mitbringt muss sich dafür zunächst mal eignen, es muss also „ready“ sein – sprich es dürfen nicht zu viele Fragezeichen dranhängen und das Ziel muss wirklich klar werden.
Erst wenn das Ziel wirklich klar ist, haben wir die Voraussetzung für klares Feedback am Sprint-Ende, aus dem das Team lernen kann.
Geht das Team nach den Scrum Idealen vor (was natürlich unendlich schwierig ist), sind die Items am Ende des Sprints wirklich „done“, also ganz fertig. Aus diesem Verhältnis von „ready“ und „done“ ergibt sich, dass das Ziel sehr klar war und das Feedback am Ende des Sprints maximale Aussagekraft hat. Es gibt dann keine Zweifel an der Gültigkeit des Feedbacks – etwa nach dem Motto: „Das kann ich mir so noch nicht vorstellen, wird schon stimmen, denn da kommt ja später noch irgendwas“.
Retrospective – bewusste Verhaltensorientierte Reflexion
Die Regelmäßige Retrospektive ist ein strukturelles Element, welches genau der Forderung aus Influencer nach Selbstbeobachtung und der verhaltensorientierten Reflexion entspricht (deliberate practice), welche Lernen in optimaler Weise fördert. Entscheidend ist hier der Bezug auf konkretes Verhalten und die regelmäßige Wiederholung. Entscheidend sind auch hier wieder die möglichst kleinen Schritte.
So sehr ich die Retrospektive also liebe und hochhalte. Evtl. ist die Retrospektive am Ende des Sprints zu spät und zu selten, wenn wir wirklich optimal lernen wollen. Schließlich sind manche Fehler und manches Verhalten, was nicht optimal war, hier schon relativ lange her. Denkbar wäre auch eine tägliche Mikroretrospektive am Ende eines Tages. Mit dieser Idee habe ich aber noch keine Erfahrung.
Ich bin mir sicher, dass noch vieles in Scrum dem Lernen dient. Generell fühlt sich Scrum für mich wie ein Framework an, dass das Lernen zentral auf die Agenda setzt. In einem folgenden Artikel möchte ich über eine Reihe agiler Praktiken und ihrem Verhältnis zum Lernen schreiben. Für heute ist erst mal Schluss.
Green Agility 