-->

Dienstag, 26. April 2011

Wie Kanban hilft, sich von agilen Irrtümern zu lösen

Neulich habe ich wieder eines meiner "Agil Extrem"-Seminare gehalten. Wie bei allen vorhergehenden Seminaren waren wieder überwiegend Führungskräfte von Unternehmen dabei, die bereits seit geraumer Zeit versuchen, agile Methoden in ihrer Organisation einzuführen, mit den Ergebnissen aber nicht wirklich zufrieden waren. Und nein, es liegt nicht an diesen Führungskräften, dass die bisherigen Versuche gescheitert sind. Diese Menschen sind fachlich und sozial sehr kompetent, haben sich umfangreiches Wissen über agile Methoden angeeignet, Seminare besucht, Coaches engagiert – und trotzdem kommen ihre Teams nicht so ins Laufen, wie sie sich das vorstellen.

Wie kann das sein, wenn agile Vorgehensweisen im Großen und Ganzen und insbesondere Scrum doch recht einfach daher kommen? Man hängt ein Board auf, steckt alle Entwickler in einen Raum, macht brav seine Schätzungen und Daily Standups ….



Scrum ist für viele Entwicklerteams einfach nicht geeignet

Wenn ein Team mit Scrum Probleme hat, dann kommt in Foren oder bei Scrum-Stammtischen gerne eine Antwort im Stil von: "Na, ist doch klar, der Scrum-Master darf nie auch gleichzeitig der Product-Owner sein." Oder: "Ihr müsst euren Kunden eben beibringen, dass es produktiver ist, ein Team während dem Sprint ungestört arbeiten zu lassen".

Diese Antworten haben leider nur einen Schönheitsfehler: Die Welt, die ist nicht so, wie es im Scrum-Manual steht. Und dies führt dazu, dass die Umsetzung von Scrum im realen Leben überall dort auf Schwierigkeiten stößt, wo auch nur eines(!) der folgenden Kriterien erfüllt ist:

  • Wenn das Team sehr divers ist, z.B. der alte C-Spezialist neben dem Web-Praktikanten sitzt, dann werden gemeinsame Sprintplanungen schnell mühselig und frustrierend,
  • wenn nicht nur ein neues Produkt entwickelt, sondern parallel auch mehrere laufende Produkte gepflegt werden müssen: Kritische Bugs oder SLAs richten sich nicht nach Sprintbacklogs, diese werden deshalb laufend unterlaufen und es ist beim besten Willen keine Velocity mehr messbar,
  • wenn der Scrum-Master oder gar der Product-Owner im Team selbst produktiv mitarbeiten müssen und ständig zwischen ihren Rollen und Aufgaben als "Leitender" und "Teammitglied" oszillieren müssen,
  • Wenn die Befugnisse des Scrum-Masters nach innen und nach außen unklar sind. Statt dass die Dinge flüssiger laufen, entsteht ständig neue Reibung,
  • wenn über Einstellungen und Entlassungen entschieden werden muss – in vielen Scrum-Handbüchern ist der Scrum-Master einfach nur nett, Personalentscheidungen sind nicht vorgesehen. 


Kanban eröffnet völlig neue Perspektiven für agiles Arbeiten

Da Waterfall-Planung aus einleuchtenden Gründen nicht funktioniert, Scrum aber oft nicht zu den real existierenden Umständen passt, ist das gelebte Resultat häufig in vielen Organisationen eine Art von Durchwurschteln. Um diese Situation zu verbessern, starten viele Teams in letzter Zeit einen neuen Anlauf mit Kanban. Tatsächlich lassen sich damit, zumindest theoretisch, viele der mit der Scrum verbundenen Probleme lösen:

  • Kanban ist unabhängig von der formalen Struktur einer Organisation, es braucht z.B. keinen Scrum-Master,
  • es kann auch in heterogenen Teams verwendet werden,
  • es kann schrittweise und verträglich ("non-disruptive") eingeführt werden und
  • ohne dass es zu dabei einem signifikanten Performance-Verlust kommt.

Aber auch die Experimente mit Kanban liefert scheinbar recht häufig nicht den erhofften Qualitäts- und Produktivitätsschub.

Woran liegt es dann diesmal?

Kanban ist noch weniger greifbar

Der Grund ist, dass es in Kanban gibt ein paar Anweisungen gibt wie „modelliere deinen Prozess“, „setze Limits“, „messe den Work in Progress“ und ähnliches.  Aber diese sind recht vage gehalten und im Endeffekt kommt Kanban konzeptionell damit sogar noch schwerer greifbar daher als Scrum. So gibt es z.B. keine vordefinierten Rollen, keine standardisierten Meeting-Formate, keine Standard-Boards, kurz: keine Patentrezepte. 

Tauchen Schwierigkeiten oder Hindernisse auf, soll "das Team diese lösen". Wie dies aber konkret geschehen soll und aufgrund welcher Logik von Ursache-und-Wirkung Kanban insgesamt funktioniert, das bleibt in vielen Beiträgen und Veröffentlichungen im Dunkeln. 

Selbstorganisation ist kein sozialdarwinistisches Experiment

Im Zusammenhang mit Agil (Scrum, XP) oder Lean (Kanban) fällt an diesem Punkt dann oft das Schlagwort von den selbstorganisierenden Teams. Die weist zwar in die richtige Richtung, aber manche Evangelisten scheinen dies mit einem sozialdarwinistischen Experiment zu verwechseln. Da wird dann recht schlicht dazu aufgerufen, dem Team „zu Vertrauen“ und die „Mitarbeiter einfach mal machen lassen“. 

Auf dem Gipfel der Selbstorganisation schöbe der Scrum-Master höchstens noch ab und an noch einen Zettel unter der Tür durch, um abzufragen, ob mehr Pizza, Cola oder sonst etwas benötigt würde. Und nach sechs Monaten, wenn man die Tür wieder aufschlösse, fände man ein Welt-Klasse-Team vor, das ganz alleine ein paar Jahrtausende an Diskussionen über die richtige Organisation und Führung übersprungen hat und ganz bestimmt von selbst auf die <joke> Beste aller Lösungen </joke> gekommen ist.

Der tiefere Grund für agile Krisen: Vor den Methoden kommt eine anspruchsvolle Führung

Tatsächlich, so behaupte ich, kommen viele Teams mit Scrum (oder Kanban) deshalb nicht zurecht, ist, weil es nicht einfach um eine andere Form der Projektorganisation geht. Wer sich zu Beginn mit Arbeitstechniken wie Daily Standups oder Cumulative Flow Diagrams beschäftigt, verschwendet seine Zeit. Solche Dinge bringt man intelligenten Menschen - und die meisten Entwickler sind sehr intelligente Menschen - in zehn Minuten bei. 

Worum es bei agilen Methoden und bei Kanban wirklich geht, ist ein fundamental anderes Konzept von Führungsaufgaben. Es geht weder darum, die Arbeit der anderen wie im traditionellen Modell vorzuplanen und Top-Down zur organisieren, noch darum, sich aus der Führung zu verabschieden. Viel mehr kommt es darauf an, als Leiter eines Team dieses und seine Mitglieder zur Selbstorganisation zu befähigen. Und das Schlüsselwort hier heißt „befähigen“. Es geht um einen bewusst und aktiv gesteuerten Entwicklungsprozess. Eine Führungskraft, die erfolgreich agile Teams leiten möchte, muss verstehen:

  • Was Menschen und Gruppen motiviert,
  • welche Bedeutung Informationsfluss und Feedbackschleifen haben,
  • Warum die „Ergonomie“ der Organisation entscheidend ist und welches die möglichen Stellschrauben sind,
  • welche Rolle Werte und Kultur spielen (und was Teamkultur überhaupt ist),
  • wie man Lernprozesse initiiert, steuert und aufrecht erhält

  • und wie man diese und weitere Faktoren zu einem funktionierenden Ganzen zusammen fügt und aktiv am Laufen hält.


Kanban als Weckruf
Die für viele mechanistisch denkenden, agilen Evangelisten schlechte Nachricht ist also, dass, zumindest meiner Beobachtung nach, Scrum und andere agile Mythen derzeit zunehmend entzaubert werden. Vieles, was die letzten Jahre in Blogs und Foren und auf Events an Rezepten gepredigt wurde, wird von einem zunehmend kritischen Publikum als waschechter Fall von  Cargo-Kult-Management entlarvt.

In diesem Prozess geschieht meines Erachtens derzeit aber noch anderes, hochinteressantes. Über die  Bereitstellung eines sehr wirksamen Management-Konzepts wird Kanban ganz nebenbei offen legen, wie anspruchsvoll agiles Projektmanagement tatsächlich ist.

Die Diskussion um Kanban wird dazu beitragen, dass einige Irrtümern bezüglich agiler Patentrezepte offensichtlich werden und dass es Zeit wird, sich von diesen zu verabschieden. 

It's time to get real!


P.S. Einen ersten Überblick über Kanban als Führungskonzept gibt es in dem neuen Kompaktseminar, dass ich ab sofort anbiete. Zum ersten Mal am 10. Mai, 13:30 bis 18:00 Uhr im Business Alliance Center in der Bundesallee 171. Mehr Infos gibt es hier.