T-Shaping – Jeder kann alles

4 April 2018
| |
Lesezeit: 2 Minutes

In jedem Team, in das ich komme, ist garantiert einmal folgender Einwand zu hören: „Bei uns kann Scrum nicht funktionieren. In Scrum muss ja jeder alles können, und unsere Arbeit ist viel zu schwierig, als dass das funktionieren könnte.“

„Jeder kann alles” ist eines der am meisten missverstandenen Konzepte in Agilität. Natürlich können nicht plötzlich alle Teammitglieder alles, was alle anderen können. Aber woher kommt dieses Missverständnis? Scrum bedeutet, dass wir in einem Team nur noch eine Rolle haben: Entwickler. Egal ob Tester, Datenbank-Entwickler oder Requirements-Engineer – das Team entwickelt zusammen ein Produkt. Also sind alle Entwickler. Damit entkommen wir einem Problem in der Planung.

Wenn wir ein Team mit sechs Personen haben, die alle nur über eine spezielle Fähigkeit verfügen und sie nur auf diesem einen Skill arbeiten wollen oder können, dann müssen wir so planen, dass alle schön ausgelastet sind. Somit können wir uns nicht mehr auf eine derzeit zentrale Priorisierung nach Business-Value einlassen. Denn verlässt man sich einzig auf dieses Kriterium, macht sich der Datenbank-Entwickler mitunter hinter eine Aufgabe, die auf der Prioritätenliste weit unten steht, nur damit er ausgelastet ist. Nicht nur führt das dazu, dass wir nicht das Wichtigste zuerst machen. Oft behindert das zusätzlich auch die Frontend-Entwickler, die gerade an der wichtigsten Pendenz arbeiten. Vielleicht muss sie ihm noch ein Interface bereitstellen, oder er baut einen Bug ein, der sie behindert.

Die Lösung liegt im T-Shaping. Dabei anerkennen wir, dass wir ohne Spezialisten nichts entwickeln können. Wir brauchen Tiefe, der senkrechte Strich im T. Um aber dem oben beschriebenen Planungsproblem zu entgehen, brauchen wir aber auch Breite, der Querbalken im T von T-Shaping. Die Spezialistinnen und Spezialisten müssen bereit sein, Skills aufzubauen, damit sie in den jeweiligen Engpässen helfen können. Dadurch werden sie nicht zu Expertinnen oder Experten in dem Gebiet, helfen aber den spezialisierten Teammitgliedern, sich auf die wirklich tiefgreifenden Probleme zu konzentrieren, indem sie ihnen einfachere Arbeit abnehmen. Mit der Zeit entwickeln sich die einzelnen Teammitglieder somit in die Breite.

Der Aufbau solcher Skills kostet. Das ist ein Investment, um zukünftig schneller und flexibler agieren zu können (“Go slow to go Fast”). Wenn wir das konsequent anwenden, werden wir bessere und schnellere Teams bekommen. Mit der Zeit kommen wir so mitunter sogar zu ∏-shaped – sprich: Pi-shaped – Mitarbeiterinnen und Mitarbeitern, die zwei oder noch mehr Spezialgebiete beherrschen.

Lead Consultant

David Baer

Kommentare (4)

Peter

5 April 2018 um 19:31

Und im Querbalken des T‘s entsteht dann Technical Dept, die am Ende die Experten von der Arbeit abhalten?

David Baer

David Baer

6 April 2018 um 14:24

VIelleicht habe ich mich nicht klar genug ausgedrückt. Im Querbalken sind die Kompetenzen die nicht so tiefgehend sind, nicht technische Schuld.
Aber vermutlich meinst du, dass wenn wir „Novizen“ auf die Themen der Spezialisten loslassen, wir uns technische Schulden einfangen. Das ist natürlich eine Gefahr, und wir möchten keineswegs auf Kosten der Qualität die Breite entwickeln.
Aber oft haben die Spezialisten Aufgaben in ihrem Spezialgebiet, die auch von Nicht-Spezilaisten erledigt werden können und ihnen so Zeit für die wirklichen Spezialistenthemen geben.
Und das Aufbauen von neuem Wissen ist natürlich immer eine Investition, daher sie kostet etwas. Da bietet sich beispielsweise Pairing an. Das nächste Mal kann diese Person dann schon besser alleine weiterhelfen. „Go slow to go fast.“

Peter

7 April 2018 um 10:04

Aber wenn ich Externen hohe Stundensätze zahle, dann will ich da nur Experten. Anders kann ich meiner Firma gegenüber das nicht verantworten. Leider habe ich es schon zu oft erlebt, das Leute mit ein bisschen Ahnung beschäftigt wurden und am Ende die Sicherheit, Usabilty oder allgemein die Qualität gelitten hat. Hätte man eher auf die Spezialisten gewartet, wäre immer günstiger gewesen. Heute braucht man halt fast immer Spezialwissen, daher funktioniert das in meinen Augen mit dem T-Ansatz nur auf dem Papier.

Till Ganzert

Till Ganzert

9 April 2018 um 08:22

Der PI Ansatz wirkt für mich durchaus sinnvoll. Ich persönlich sehe das Ganze sogar eher als Dreieck oder sogar Balkendiagramm.
Meiner Erfahrung nach ist es sinnvoll immer mindestens 2 Teammitglieder mit gutem Knowhow auf einem bestimmten Gebiet zu haben, denn auch ein Experte allein findet nicht immer die beste Lösung.
Um das Qualitäts-Problem anzugehen bieten sich Task-Kickoffs oder Designsessions, sowie Reviews und Pairing durchaus an. Mit etwas Übung sind die Ergebnisse hier häufig überraschend gut.

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.