07.09.2012, Von Stephan Schwab
Software wird von Spezialisten entwickelt. Spezialisten verfügen über überdurchschnittliche Kenntnisse und langjährige Erfahrung in ihrem jeweiligen Fachgebiet. Doch leider bleibt ihnen oft nicht die Zeit auch Erfahrungen in benachbarten Gebieten zu sammeln oder organisatorische Fähigkeiten zu entwickeln.
Arbeitsgruppen aus Spezialisten bringen unterdurchschnittliche Leistung, weil die darin versammelten Spezialisten nicht wirklich zielgerichtet zusammenarbeiten können. Wenn z.B. ein Datenbankexperte mit vielen Jahren Berufserfahrung im Entwurf und der Optimierung von SQL-Datenbanken mit einem Java-Programmierer der ersten Stunde eine Anwendung entwickeln soll, wird das Ergebnis die Erwartungen nicht erfüllen. Der Datenbankexperte wird dazu neigen alle Daten in SQL-Tabellen zu halten und mittels "stored procedures" innerhalb der Datenbank zu bearbeiten. Der Java-Programmierer mag eine alternative Speicherform vorschlagen und die Daten mittels Java-Code bearbeiten wollen. Die beiden Experten reden aneinander vorbei und statt um die Lösung des vom Auftraggeber genannten Problems wird es mehr um die jeweiligen Technologien gehen. Keiner der beiden macht etwas falsch. Es ist einfach so, daß es den Spezialisten schwer fällt aus der Enge ihres Fachgebietes herauszutreten.
Als Coach arbeite ich über mehrere Monate mit demselben Personen. Meine Aufgabe besteht dabei nicht darin den erfahrenen Fachleuten zu zeigen, wie sie ihre Arbeit fachlich besser machen können. Stattdessen geht es darum die Schnittstellen zwischen diesen Spezialisten zu verbreitern und so unnötige Reibungsverluste durch Mißverständnisse und Wartezeiten zu vermeiden.
Ganz so wie im Mannschaftssport geht es darum jedem Teammitglied zu vermitteln wie er/sie das gesamte Team unterstützen kann, statt einfach nur innerhalb des begrenzten Rahmens der eigenen Position zu bleiben.
Coaching für Teams außerhalb des Sports ist ein recht neues Konzept. Daher halte ich es für erforderlich kurz darzustellen was ein Coach nicht ist bzw. was er nicht macht.
Ein Coach ist kein Scrum Master. Die Rolle des Scrum Masters ist darauf beschränkt auf die Einhaltung der Scrum-Regeln und Zeremonien zu achten und dem Team bei der korrekten Anwendung von Scrum zu helfen. Das ist kein Team-Coaching.
Ein Coach ist auch kein Projektleiter, kein Manager, kein Teamleiter, kein Trainer oder andere Form von Lehrer. Als Coach helfe ich Fachkräften, die sehr gut im Durchführen ihrer fachlichen Aufgaben sind. Ich mische mich nicht in ihre fachlichen Aufgaben ein - es sei denn es wird ausdrücklich gewünscht -, sondern helfe jedem Einzelnen organisatorische Fähigkeiten für die Arbeit im Team zu entwickeln.
Diese organisatorischen Fähigkeiten sind etwas, welches der Einzelne wirklich nicht außerhalb des Teams für sich selbst lernen kann. Wer sich als Programmierer weiterbilden möchte, kann das allein tun. Zum Erlernen von Teamarbeit kann man das nicht. Dafür braucht es das Team und den Coach.
Ein typisches Team für Software-Entwicklung besteht mindestens aus Programmierern und Testern. Typischerweise kommt dann noch ein Analytiker für das Definieren der Anforderungen hinzu. Nehmen wir einmal an dieses Team besteht aus 6 Programmieren, 2 Testern und einem Analytiker.
Die Geschäftsleitung beschließt diesem Team aus 9 Personen einen Coach zur Verfügung zu stellen. Der Coach ist die ersten drei Monate für jeweils drei Tage pro Woche anwesend und nach dem anfänglichen Intensiv-Coaching zieht er sich zurück. Um aber den Coaching-Erfolg zu kontrollieren und eventuellen Bedarf für weitere Maßnahmen rechtzeitig entdecken zu können, hilft er dem Team danach über zwei Monate alle zwei Wochen beim Durchführen einer Team-Retrospektive.
Für die nachfolgende Grafik habe ich marktübliche Jahresgehälter und einen üblichen Tagessatz für Coaching herangezogen. Die auf 5 Monate begrenzte Coaching-Maßnahme steuert somit ungefähr 15% der Personalkosten für das Team bei.
Die Frage, ob sich Coaching für ein Team rechnet, läßt sich nun recht einfach beantworten. Wir müssen einfach nur die Verbesserung der Zusammenarbeit messen und dann mit der Investition in die Coaching-Maßnahme vergleichen.
Ein Weg, den wir zur Messung beschreiten können, ist eine Wertstromanalyse vor und nach der Coaching-Maßnahme zu machen. Wenn dann beispielsweise die Wartezeit auf neue Fähigkeiten der Software, an welcher das Team arbeitet, um mehr als 15% gesunken ist, dann hat sich die Investition sofort ausgezahlt.
Beispiel: Ein Team benötigt etwa 30 Tage (das ist bereits in vielen Fällen schnell) für das Liefern eines neuen features gemessen vom Beginn der Anforderungsanalyse bis zum Zeitpunkt wann es in Produktion für die Anwender/Kunden verfügbar ist. 15% von 30 Tagen sind 4,5 Tage. Wenn also durch Coaching erreicht wird, daß das Team features durchschnittlich 4,5 Tage früher liefert, dann ist Coaching bereits durch diesen kleinen Fortschritt rentabel. Das entspricht einer Steigerung der Produktivität um 120%. Gelingt es neue Anforderungen in funktionierende Software innerhalb von 10 Arbeitstagen umzusetzen, dann wäre die Produktivitätssteigerung gar 300%. 10 Arbeitstage ist die Dauer eines typischen Scrum-Sprints.
Teams bestehen aus ihren Mitgliedern. Investiert man in Coaching für das gesamte Team, darf man natürlich das Team nicht am Ende eines Projektes auflösen. Täte man das, so würde man das Gelernte wörtlich über Bord werfen. Das macht keinen Sinn. Stattdessen sollte man Teams niemals auflösen, sondern immer Projekte zu langfristig bestehenden Teams bringen. Damit erreicht man zwei Vorteile. Zum einen wird die Investition in Coaching noch viel mehr rechnen und zum anderen erlaubt man dem Team sich eigenständig weiterzuentwickeln.
Wollen Sie diesen Artikel mit anderen teilen?
| Tweet |
