Haben Sie manchmal Lust, Leute zu feuern und dann in den Prozess Ihrer Teams handfest einzugreifen? Es soll Manager geben, die kommen auf diese Idee, weil sie an Scrum- oder Kanban-Teams schier verzweifeln. Der Manager beobachtet aus seiner Sicht zum Beispiel folgendes:

  • die Teams tun nicht, was sie sollen,
  • die von den Teams erstellte Software performt nicht,
  • die Leute verstehen nicht, was die eigentliche Aufgabe der Firma ist,
  • die hervorgebrachte Architektur kennt oder versteht man außerhalb der Teams nicht,
  • die Teams brauchen viel zu lange, um etwas zu entwickeln,
  • und vieles dergleichen mehr.

Klingt das für Sie vertraut? Hatten Sie auch schon Lust, mit dem eisernen Besen zu kehren, so nach dem Motto: „Da kann doch mit der angeblichen Selbstorganisation etwas nicht stimmen! Ich gehe hin und sage denen jetzt mal, was Sache ist … Wenn die Leute das selbst nicht können, muss ich halt ran!“.

Das kann ja wirklich so sein. Bevor Sie als Manager jedoch Leute feuern, lassen Sie mich noch ein paar Fragen stellen:

  • Wenn die Teams nicht tun, was sie sollen … Woran hätten die Mitarbeiter erkennen können, was sie tun sollen? Haben Sie z.B. Abnahmekriterien oder Entscheidungsfilter ausgegeben? Woran erkennen Sie, dass die Leute nicht das tun, was sie sollen? Ist es möglich, dass die Leute etwas vermeintlich oder tatsächlich Besseres tun?
  • Wenn die Software nicht performt … Haben Sie eigentlich klar vorgegeben, was Performance im jeweiligen Kontext  genau heißt? Antwortzeit? Durchsatz? Speicherverbrauch? Wann haben Sie’s den Leuten ins Backlog gestellt?
  • Wenn die Leute nicht verstehen, was die eigentliche Aufgabe der Firma ist … Haben Sie ihnen erzählt, welchen Wert Ihre Firma für Ihre Kunden stiftet? Welche Fähigkeiten Ihre Kunden dadurch haben, dass sie Ihre Software einsetzen? Und: Was daran eigentlich so genial ist, dass alle neidisch auf Ihre Firma sein müssten? Wo ist das Feuer, wann haben Sie den Menschen Begeisterung ermöglicht?
  • Wenn die Architektur unsichtbar ist oder niemand sie versteht … Haben Sie von Ihren Teams und Architekten auch klar verlangt, was Sie sehen möchten? Und zwar früh genug, gleich nach jeder umgesetzten User Story? Zum Beispiel: Komponenten und ihre Verantwortlichkeiten, wichtige Abläufe im System, Deployment-Zuordnung von Komponenten zu Maschinen und Kommunikationskanälen, Lösungen für nicht-funktionale Anforderungen?
  • Wenn die Leute viel zu lange brauchen, um etwas umzusetzen … Wie groß war das Paket, das die Leute auf einmal stemmen mussten? Haben Sie auf dem Bestellzettel des Paketes alles klar genug vermerkt? Wie groß war die Klarheit und Qualität der gestellten Anforderungen? Wie oft bekamen die Leute Feedback? Was mussten die Leute Unnötiges tun, was sie abgehalten haben könnte (z.B. Stundenzettel ausfüllen)?

Worauf ich mit diesen Fragen hinaus will, ist folgendes:

  1. Intelligente Leute verhalten sich in guten Systemen (z.B. gut geführten Teams oder Firmen) vernünftig – niemand will ein Trottel oder ein Spielkind sein.
  2. Mitarbeiter wollen professionelle, gute Arbeit machen und damit Erfolg haben.
  3. Menschen wollen selbst operative Entscheidungen treffen, zu Meistern ihres Faches werden und wissen, welchen Sinn und Zweck das Ganze hat.
  4. Ist das gegeben, dann ist es nur noch eine Frage der Kompetenz und ob ihnen jemand dabei hilft, Grundbedingungen schafft und Hindernisse aus dem Weg räumt.

Fragen Sie sich einmal folgendes:

  • Wenn der Mitarbeiter nicht tut, was er soll – würde er es denn tun, wenn sein Leben davon abhinge? Zum Beispiel wie bei einer Polarexpedition?

Lautet die Antwort „ja“, so hat er die Kompetenz und ist lediglich demotiviert oder konfus/desorientiert. Fragen Sie sich dann, ob es an Ihnen oder an der von Ihnen gestalteten Firma liegt. Wenn ja, tun Sie etwas, um die Systembedingungen zu verändern und es für den Mitarbeiter einfach zu machen, das zu tun, was für die Firma am besten ist.

Lautet die Antwort „nein“ (er würde es also auch nicht tun, wenn sein Leben davon abhinge!), so hat er die Kompetenz nicht. Fragen Sie sich (und/oder ihn selbst) dann, ob er diese erwerben oder etwas anderes Wertvolles für Sie tun kann. Erst wenn die Antwort darauf ebenfalls „nein“ lautet, feuern Sie ihn.

In jedem Fall: Schaffen Sie Attraktoren – das sind Punkte mit gewünschtem Verhalten, zu dem die Leute fliegen wie Motten zum Licht. Scheuchen Sie die Motten nicht (da haben Sie nämlich viel zu tun!). Stellen Sie stattdessen klar erkennbare Lampen auf, die ständig leuchten.

, Agile Entwicklung , Prozesse und Kultur