Coaching von Software-Teams ohne vom Fach zu sein?

Kann man Teams in der Softwareentwicklung sinnvoll und nachhaltig zur Verbesserung ihrer technischen und organisatorischen Fähigkeiten coachen ohne selbst langjährige Erfahrung in der Entwicklung von Software-Produkten zu haben? Das ist die Frage, die mir schon seit einiger Zeit durch den Kopf geht.

Verbesserung von Fertigkeiten, um Fähigkeiten zu haben

Während meiner Zeit in USA hatte ich das Vergnügen häufig mit Coaches zusammenarbeiten zu dürfen, die selbst auch ziemlich gute aktive Softwareentwickler sind. Dort werden Coaches meist für den “skill uplift”, also die Verbesserung von Fertigkeiten, in’s Haus geholt. Die dortige Auffassung von Coach ist, daß ein Coach den Teammitgliedern beibringt eine bessere Arbeit zu leisten als ohne (get better at the job). Das ist wie im Sport. Auch dort ist der Coach vom Fach. Der Sportcoach war früher meist ein ziemlich guter Sportler in der jeweiligen Disziplin und hat sich zum Coach fortentwickelt, sodaß er nun in der Lage ist den Nachwuchs auf sein eigenes früheres Niveau zu heben oder darüber hinaus. Das deckt sich auch mit dem Ursprung des Wortes “coach” und seiner Referenz an die Kutsche, die jemanden zum Ziel trägt.

Entsprechend stehen auch viele dieser Coaches der Bewegung software craftsmanship sehr positiv gegenüber.

In Deutschland ist mir aufgefallen, daß unter “Coaching” teilweise etwas ganz anderes verstanden wird, als ich diese bisher in USA kennengelernt habe. Ich habe seit meiner Rückkehr Personen getroffen, die sich häufig als Scrum Master vorstellen und Software-Teams coachen. Mancher berichtete dann auch, daß er/sie eine Ausbildung zum systemischen Coach gemacht hat oder in irgendeiner Weise etwas mit einem der vielen Coaching-Verbände zu tun hat.

Mir war gar nicht bewußt, daß es im relativ kleinen Deutschland eine Vielzahl Verbände für Coaching gibt. Also habe ich ein wenig recherchiert und ich finde zum Thema Coaching alles Mögliche. Es reicht von Hilfe in schwierigen Lebenslagen, über das Bauen von Brücken im Wald als Teambildungsmaßnahme bis hin zum Coaching von Führungskräften. Mir scheint als hätten viele der Beteiligten Psychologie oder eine andere Geisteswissenschaft studiert.

Das alles ist natürlich nicht falsch und es steht mir wirklich fern irgendjemanden in einem mir fremden Betätigungsfeld zu kritisieren. Das ist nicht meine Absicht. Ich möchte in diesem Artikel über Coaching in der Softwareentwicklung sprechen.

Ein Blick in’s Wörterbuch

Oben sprach ich vom Ursprung des Wortes “Coach”. Das Wörterbuch der englischen Sprache sagt, daß “to coach” ausbilden bedeutet. Das tun auch die Wörter “to train” und “to educate”, doch spricht man von “to coach” erst wenn die Ausbildung mit dem Verfeinern von bereits existierenden Fertigkeiten zu tun hat. Das von mir benutzte Wörterbuch erwähnt auch den Coach im Sport als Ausbilder eines Teams explizit. Im Deutschen würde man den als Trainer bezeichnen. Aber auch das Wort Trainer ist ein importiertes Wort. Die deutschen Begriffe wären Lehrer oder Ausbilder.

Ziel: Ein Meister werden

Softwareentwicklung ist eine Tätigkeit, die Elemente von Forschung, Design, Handwerk, Kunst und auch ein wenig Psychologie und cognitive sciences beinhaltet. Ein erfahrener Softwareentwickler sollte meiner Meinung nach in der Lage sein ein Produkt von der Idee bis zur Auslieferung an Endanwender zu realisieren. Wenn man das japanische Modell Shu-Ha-Ri oder das deutsche Modell Lehrling-Geselle-Meister zu Grund legt, dann wäre diese Person auf dem Ri-Niveau bzw. ein Meister. Ich meine damit natürlich nun nicht, daß alle aufgeführten Tätigkeiten von einer einzelnen Person durchzuführen seien. Es braucht schon ein Team für eine so große Aufgabe. Ein Handwerksmeister arbeitet auch mit vielen anderen Menschen zusammen. Als Meister kann er aber jederzeit helfen und aushelfen - ganz egal worum es geht.

Je mehr Meister eine Organisation beschäftigt, desto eher wird sie in der Lage sein fortwährend gute Produkte zu erschaffen. Es sollte im ureigensten Interesse der Organisation sein möglichst viele Mitarbeiter in jedem Tätigkeitsbereich zu Meistern ihres jeweiligen Faches fortzuentwickeln.

Das Ziel kennen

Kann man gute Softwareentwickler zu Meistern fortentwickeln ohne selbst erfahren zu haben wie eine von einem Meister gemachte Arbeit eigentlich aussieht? Kann man dies nur mit theoretischem Wissen oder Beoachtungen im Fachgebiet erreichen?

Coaching ist eine Vorgehensweise

Entsprechend meiner bisherigen Erfahrung in USA und entsprechend der Bedeutung des Wortes “to coach” ist Coaching nichts anderes als eine bestimmte Vorgehensweise für die Ausbildung von Menschen, die bereits reichlich Erfahrung haben.

Es gibt da das Modell von Dreyfus zur Wissensaneignung. Je nachdem auf welchem Niveau sich jemand oder ein Team befindet sollte der Ausbilder unterschiedliche Techniken benutzen.

Wechsel zwischen verschiedenen Methoden

Wenn ich z.B. einem Programmierer, welcher bisher noch nie testgetriebene Entwicklung (TDD) gemacht hat, helfen soll dies zu erlernen und von vornherein abgesprochen ist, daß dieser TDD lernen will, dann wäre Coaching die verkehrte Vorgehensweise. Da muß ich ganz direkt als eine Art Lehrer agieren und ihm die Grundlagen dieser Technik vermitteln und mit ihm gemeinsam praktische Aufgaben lösen. Das geht nicht durch Frontalunterricht. Das geht aber auch nicht durch geschicktes Fragenstellen. Also werde ich am Anfang eher klare Anweisungen geben (“wir schreiben jetzt den Test in der Form”), dann immer mal wieder den Schüler eigene Wege gehen lassen (er kann ja programmieren) und wieder zu einer direkteren Form zurückkehren. Am Ende ist die Vorgehensweise eine Mischung aus unterschiedlichen Vorgehensweisen.

Fertigkeiten verbessern oder nur Denkanstöße liefern

Das gerade Beschriebene kann jemand, der selbst kein Softwareentwickler ist, nicht leisten. Ein Coach, der nicht vom Fach ist, kann durch Lesen erfahren, daß es verschiedene hilfreiche Techniken gibt. Ob das jetzt TDD oder Scrum ist, spielt eigentlich keine Rolle. Aber er kann unmöglich den “skill uplift”, die Verbesserung von Fertigkeiten, erreichen. Wer nicht vom Fach ist, kann nur Denkanstöße liefern, aber nicht bei der Umsetzung helfen.

Aus Fertigkeiten werden Fähigkeiten

Am Ende des Tages wird von Software-Teams erwartet funktionsfähige Software abzuliefern, die einem bestimmten Zweck dient. Das sagt auch z.B. der Scrum-Guide, nach dem am Ende eines jeden Sprints ein potentially shipable product increment, also eine potentiell auslieferbare Verbesserung der Software, erwartet wird. Es muß funktionieren und benutzbar sein.

Verfügen die Mitglieder eines Teams über gut entwickelte Fertigkeiten, die für die gestellte Aufgabe hilfreich sind, dann verfügt das Team über Fähigkeiten. Gute Zusammenarbeit untereinander und mit dem Auftraggeber ist eine organisatorische Fähigkeit. Fertigkeiten, die es ermöglichen qualitativ hochwertige Software zu erstellen, bilden technische Fähigkeiten. Nämlich die Fähigkeit Anforderungen auch tatsächlich umzusetzen.

Also ist es die Aufgabe eines Coaches in der Softwareentwicklung den einzelnen Personen und dem Team als Ganzes bei der Entwicklung von organisatorischen und technischen Fähigkeiten zu helfen. Ein Scrum Master, welcher keine Erfahrung in der praktischen Softwareentwicklung hat, kann das nicht. Und seine Rolle ist entsprechend dem Scrum Guide ja ohnehin darauf beschränkt sicherzustellen, daß Scrum verstanden und korrekt angewandt wird. Als Coach muß man zunächst einmal ein Meister des Faches sein und dann zusätzlich über die Fähigkeiten verfügen, die es ermöglichen Wissen und Erfahrung an andere weiterzugeben.

Aktualisierung 31.10.2012

Stefan Haas wies mich auf Developing Great Agile Coaches - Towards a Framework of Agile Coaching Competency von Lyssa Adkins, Autorin des Buches Coaching Agile Teams und Michael K. Spayd, Agile Coach und einer der Teilnehmer am ersten Treffen der Stoos-Bewegung, hin. Besonders gefällt mir an diesem Vorschlag, daß “domain mastery”, also fachliches Wissen, neben dem Beherrschen von Techniken zum Vermitteln von Wissen gefordert wird. Paßt genau zu meiner eigenen Denkweise.

27 Oct 2012

This article has been posted to social media sites. There might be comments. Just follow the links: