Eine häufig postulierte Annahme ist es, dass jedes Mitglied eines Teams „alles“ können muss. Das bedeutet, es spielt keine Rolle, wer aus dem Team sich welchen Task nimmt, denn die Fähigkeiten im Team sind ja gleich verteilt.
Full-Stack-Entwickler sind nach diesem Prinzip ausgebildet – sie haben alle notwendigen Fähigkeiten, so dass nicht zwischen Backend- und Frontend-Entwicklern unterschieden werden muss.
Jeder kann alles?
Einerseits weist diese Annahme schon auf die richtige Fährte. Andererseits gibt es möglicherweise doch ein paar Missverständnisse, auf die ich im Folgenden näher eingehen werde.
Betrachten wir also die Annahme „jeder im Team hat die gleichen Fähigkeiten/Skills und kann demnach alle Aufgaben im Team (gleich gut) lösen“ etwas näher. Ist das immer so, und lässt sich das in der Praxis gut realisieren?
Ein Blick auf ein klassisches Softwareteam zeigt zum Beispiel Teammitglieder, die sich auf einzelne der folgenden Bereiche spezialisiert haben:
- Testen
- Architektur
- Frontend
- Backend
- Datenbanken
- UX/UI
Es gibt also einen Architekten im Team, mehrere Frontend- und Backend-Entwickler, einen Datenbank-Entwickler, einen Tester und einen UXler.
Herausforderung Realität
In vielen Fällen werden nun eben hauptsächlich die Bereiche von den Entwicklern bearbeitet, auf die sie sich spezialisiert haben. Man macht das am liebsten, was man gut kann und kennt, und das einem per Titel/Position zugesprochen wurde.
Das hat typischerweise zur Folge, dass innerhalb einer Iteration Staus entstehen. Wer schon einmal das Spiel getKanban mit seinen Ereigniskarten gespielt hat, weiß wovon ich spreche. Wenn der Tester plötzlich für einige Wochen ausfällt oder der einzige freie Entwickler beim Testen aushelfen muss, rennt man in genau dieses Problem.
Wie realistisch und praxisnah ist es nun, dass ein Tester sich einen Task schnappt, in dem es beispielsweise um eine „Optimierung von Datenbankabfragen geht, die zu teuer sind“?
Nicht besonders, oder? So viel zum Thema: „Jeder im Team hat die gleichen Fähigkeiten/Skills und kann alle Aufgaben im Team (gleich gut) lösen.“ Das wird meiner Meinung nach nicht funktionieren.
Flexibilität zählt
Deutlich besser aufgestellt sind da Teams mit Full-Stack-Entwicklern und einem guten Verständnis von Softwareentwicklung: Dort ist bekannt, dass Testen zur Aufgabe eines Entwicklers dazu gehört. Und da es keine Unterscheidung zwischen ausschließlichen Frontend- und Backend-Skills gibt, können einzelne Aufgaben besser verteilt umgesetzt werden. Es entsteht also eine Effizienz innerhalb einer Iteration, gepaart mit einer gewissen Ausfallsicherheit. Flexibilität ist hier das Zauberwort.
Dies sind wichtige Faktoren. Sie sind hilfreich, um das eigentliche Ziel – nämlich das kontinuierliche Ausliefern werthaltiger, funktionierender Softwareinkremente – zu verfolgen und sicherzustellen. Doch heißt das nun, dass alle Full-Stack können müssen und UXler keine Daseinsberechtigung in einem Team haben? Nicht unbedingt …
Get in shape!
Dazu bediene ich mich des Gedankenmodells des T-shaped/Pi-shaped/Paint-drip Developers. Im Laufe der Zeit einer Entwicklertätigkeit oder der Zugehörigkeit in einem Produktentwicklungs-Team eignen sich die einzelnen Teammitglieder weitere Skills an.
So könnte also die obige Teammitglieder-Auflistung wie folgt aussehen:
- Testen (UX/UI)
- Architektur (Security, Datenbanken)
- Frontend (Backend)
- Backend (Frontend)
- Datenbanken (Architektur, Security)
- UX/UI (Testen)
Schon wird sichtbar, dass sich die einzelnen Kompetenzen viel stärker innerhalb des Teams verteilen und zu den Kern-Skills noch weitere Fähigkeiten hinzukommen, die effektiv einsetzbar sind. Über die Zeit verschwimmen die Grenzen also immer mehr, und wir nähern uns dem ursprünglichen Full-Stack-Gedanken an.
Das hat große Vorteile: Das Bewusstsein für gutes Testen strömt in das gesamte Team hinein. Und Architektur wird nicht mehr nur von einem Architekten vorgegeben, sondern vom gesamten Team gemeinschaftlich entwickelt.
Klar, dass die Teammitglieder mit hoher Erfahrung in Architektur gewisse Taktgeber sind. Noch besser ist es, wenn sie innerhalb des Teams zum Coach werden und somit dafür sorgen, dass Architektur-Skills sich permanent bei allen weiterentwickeln, wenn auch in unterschiedlichen Ausprägungen.
… und die Experten?
Wenn man von außen auf die agile Welt und die agilen Teamstrukturen schaut, ist man versucht, die Nase zu rümpfen. „Wir brauchen doch Experten“, rufen die einen. Nun, Expertise im Sinne von tiefgreifenden Kenntnissen hat jedes der oben genannten Teammitglieder nach wie vor. Somit ist also auch die Einbringung individueller Kompetenzen und Neigungen möglich.
Durch eine Verteilung innerhalb des Teams rückt jedoch das eigentliche Ziel zurück in den Fokus: Die kontinuierliche Lieferung werthaltiger Softwareinkremente.
PS: Wer mehr über die Definition eines Paint-Drip Developers erfahren möchte, schaut sich die Notiz von Kent Beck auf Facebook an.
Unsere Serie Agile Missverständnisse
Schreibe einen Kommentar