Diesen Rat hat jeder von uns bestimmt schon ein paar tausend mal gehört, doch die Zeiten ändern sich, und gerade im Umfeld Agiler Methoden ist dieser Gedanke komplett falsch. Theoretisch wissen wir das auch, doch allzu oft verhalten wir uns komplett anders.
Als mir zum ersten mal jemand geraten hatte, mich in meinem Job unentbehrlich zu machen, klang das für mich noch verdammt einleuchtend. Ich war jung und unerfahren, hatte keine Ahnung von Agilen Methoden und moderneren Businesssystemen, hatte Begriffe wie Holacracy oder Selbstorganisation und Wissenstransfer noch nie gehört. Meine Vorstellungen orientierten sich an alten Arbeitsmodellen aus Handwerk und Industrie oder klassischem Management.
Die Argumentation war sehr leicht nachvollziehbar: wenn Du Dinge weißt und kannst, die kein anderer weiß oder kann, dann kann Dich Dein Unternehmen nicht feuern. Du machst Dich wertvoller und wirst besser bezahlt. Grundsätzlich logisch, oder?
Genau das ist irgendwo auch das Dilemma. Im Prinzip stimmt das noch immer. Wenn ich Wissen habe, das kein anderer hat, habe ich mein Unternehmen im Schwitzkasten und mache mein Team, meine Abteilung oder auch das ganze Unternehmen in gewisser Weise von mir abhängig. Wäre ich ein selbstgerechtes Arschloch, könnte ich nun anfangen, Forderungen zu stellen. Seien wir ruhig ehrlich: dieses Verhalten begegnet uns noch immer täglich.
Scrum – oder auch andere Agile Methoden – spricht jedoch davon, dass wir Wissen im Team verteilen, und dass wir unsere Teams mit „Spezialisierten Generalisten“ oder „Generalisierten Spezialisten“ füllen, damit wir alle anfallenden Aufgaben von mehreren (im Idealfall von allen – aber das ist im allgemeinen vollkommen unrealistisch) Personen erledigen lassen können.
Wir möchten möglichst frei entscheiden können, wer welche Anforderung umsetzt, um unter anderem auch zu vermeiden, dass einzelne Kollegen überlastet werden, während die anderen den ganzen Tag nur Tetris spielen können. Wir haben also die Verteilung von Wissen und Fähigkeiten im Team immer im Hinterkopf und berücksichtigen das ständig (z.B. durch Pair Programming).
Ein Problem dabei ist nicht nur, dass wir Ungleichheiten bei der Verteilung schaffen, wir bringen uns auch immer wieder selbst in Schwierigkeiten, weil wir unseren eigenen Flaschenhals pflegen und nicht ausweiten. Der eine Kollege, der diese eine Sache kann, die wir immer wieder benötigen, hat Urlaub, ergo haben wir ein Problem. Der Kollege entscheidet sich, das finanzielle Angebot eines Mitbewerbers anzunehmen, weil dieser auch scharf auf das Wissen dieser einen bestimmten Person ist, und schon haben wir ein riesiges Problem. Der Kollege ist fein raus und schwimmt wie Dagobert Duck im Geld, während wir händeringend versuchen, den Schaden in Grenzen zu halten und andere Kollegen zu schulen.
Sich eben nicht unentbehrlich zu machen, liegt auch in meinem eigenen Interesse. Ich will doch garnicht der einzige sein, der irgendetwas kann. Wir wissen doch alle, wie das endet: wir werden dann immer wieder unter Höchstlast stehen, weil uns kein anderer entlasten kann. Wer hat schon Lust, jeden freien Tag, den er sich nehmen will, lang und breit erklären zu müssen? Will irgendeiner von Euch Lesern seinen Sommerurlaub von Kundenanforderungen abhängig machen?
Und wenn wir schon ehrlich miteinander sind, sollten wir hier nicht stoppen. Eine der Motivationen für dieses Unentbehrlichkeitsding ist die Angst davor, gefeuert zu werden, und exklusives Wissen ist ein guter Schutz davor, doch ich stelle einmal ganz frech die Frage, ob diese Angst überhaupt noch Bestand haben sollte. Gute Entwickler, Product Owner, Scrum Master usw. können sich ihre Jobs aussuchen. Wer bei Xing vorsichtig signalisiert, dass er eventuell bereit wäre, sich ein Angebot anzuhören, wird mit Anfragen zugespammt.
Fassen wir einmal zusammen: Was habe ich also davon, über exklusives Wissen zu verfügen? Sehr wahrscheinlich mehr Arbeit und ständig jemandem an meinem Rockzipfel (auch wenn ich keinen Rock trage), der mir damit in den Ohren liegt, dass ich jetzt nicht in Urlaub gehen könnte. Auf der Haben-Seite liegt die Möglichkeit, mein Unternehmen auszuquetschen und mich zum Arschloch zu machen.
Welche Probleme hat das Team mit exklusivem Wissen bei einzelnen Personen? Es befindet sich in einer Abhängigkeit und muss viele Tätigkeiten auf eine Person ausrichten. Dem steht kein einziger Vorteil gegenüber. Wir haben nur Nachteile. Natürlich wird jetzt jeder schreien, dass wir die Wissensverteilung im Team vorantreiben müssen, dem entgegne ich jedoch die Frage, wie sollen wir das anstellen?
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Die Anworten darauf sind die üblichen Verdächtigen: Pair Programming, gemeinsame Schulungen usw., doch was hilft uns das, wenn die Notwendigkeit für verteiltes Wissen nicht wirklich verstanden wird? Ganz genau: nichts. Unser erster Schritt ist also wieder einmal die gemeinsame Sicht auf die Dinge. Sagen Sie jetzt bitte nicht, dass das jeder bereits wissen müsse. Die Antwort darauf lautet: theoretisch ja, aber wir wissen doch alle, was wir von Theorien halten können, oder?
Ebenfalls immens wichtig ist, dass wir uns über unser Ziel klar werden. Ich empfehle auf jeden Fall, diese beiden Themen mit dem gesamten Team zu besprechen, um sowohl das Verstehen als auch das gemeinsame Zielbild zu schaffen.
Stecken Sie Ihr Ziel nicht zu hoch. Ich höre immer wieder, dass davon gesprochen wird, dass alle im Team alle Aufgaben erledigen können sollen. Bei cross-funktionalen Teams ist das nicht ganz so einfach. Erwarte ich tatsächlich von meinem Designer, dass er am offenen Herzen im Core entwickelt? Natürlich nicht. Realistischer ist meistens das Ziel, für jede Aufgabe mindestens zwei Personen im Team zu haben. Wir werden uns auch nicht vollständig von den Spezialisten verabschieden können. Unser Ziel ist nicht die vollkommen homogene Masse, unser Ziel ist, dass sich die Kollegen gegenseitig unterstützen können. Unser Ziel ist, dass wir kein riesiges Problem bekommen, wenn ein Kollege mal Urlaub macht. Wir werden immer Spezialisten haben. Wir werden immer Kollegen haben, die eine Sache ganz besonders gut können, schon aus dem ganz einfachen Grund, dass unterschiedliche Menschen unterschiedliche Interessen haben. Wenn wir das ignorieren, nehmen wir unseren Kollegen viel Spaß an ihrer Arbeit.
Wie sehen also meine Teams am Ende aus? Ich habe Wissen und Fähigkeiten soweit verteilt, dass jede Anforderung von mindestens zwei Personen im Team erledigt werden könnte. Je mehr, umso besser, aber eben mindestens zwei. Und ich kann die Anforderungen nicht nur von zwei Personen erledigen lassen, ich kann auch immer mit mindestens zwei Personen diskutieren. Ich bekomme zu jedem Thema, zu jeder Aufgabe im Team Input von mehreren Seiten aus dem Team, immer mehrere Aspekte, niemals nur die Sicht einer einzelnen Person. Das ist das wirklich Wertvolle. Nur über verteiltes Wissen komme ich erst in eine Diskussion.
Bleibt noch die lästige Frage danach, wie man am besten vorgehen sollte, und ich kann wieder einmal nur antworten, dass dies vom Team selbst abhängt. Trotzdem ergibt sich daraus kein Problem, wenn das Bewusstsein bei allen gegeben ist, dass es ein sinnvolles Ziel ist, Wissen und Fähigkeiten zu verteilen. Das Team wird seine eigenen Regeln aufstellen. Jeder Entwickler hat zumindest schon von Pair Programming gehört. Im Refinement wird man fast ganz automatisch die Frage stellen, ob diese Anforderung etwas sei, dass man sich zu zweit ansehen sollte. Auch Scrum Master oder PO können diese Frage mal in den Raum werfen.
Unsere beiden Arbeitsbühnen für den Wissenstransfer sind Refinement und Umsetzung. In der Umsetzung kann ich über Pair Programming oder Mob Programming gehen, im Refinement ist der erste und einfachste Schritt, wenn ich feststelle, dass es nur eine Person gibt, die sich in einer bestimmten Ecke auskennt, diese Person zu bitten, kurz alle anderen abzuholen und den Sachverhalt zu erklären. Wenn es komplexer ist, muss man vielleicht eine Extrasession einschieben. Erwarten Sie aber nicht zu schnell zu viel. Diese Dinge müssen wachsen. Wir können natürlich nicht annehmen, dass jeder, nachdem er einmal 30 Minuten über einen Teilbereich der Software aufgeklärt wurde in aller Tiefe mitdiskutieren könnte. Zuerst verschafft man sich einen ganz groben Überblick, den wir immer weiter vertiefen. Wir sind also gefordert, am Ball zu bleiben. Die Verteilung von Wissen und Fähigkeiten im Team ist niemals abgeschlossen. Einer lernt eine neue Sache, die Kollegen müssen(zumindest zum Teil) folgen.
Abschließend vielleicht noch ein kleiner Hinweis, weil das in vielen Gesprächen, die ich zu diesem Thema geführt habe, nicht immer klar war. Wir sprechen von Wissens- und Fähigkeitenverteilung nicht nur vertikal, also dass ein Architekt auch entwickeln sollte, und dass ein Backender auch ein wenig Frontend beherrschen sollte, wir sprechen vor allem auch über die horizontale Verteilung von Wissen. Es kann und darf nicht sein, dass bestimmte Teilbereiche der Anwendung in exklusiver Hand liegen. Um es anders zu formulieren: wir haben ein Problem, wenn nur einer weiß, wie das Abrechnungsmodul funktioniert.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
