Führungskräfte stehen manchmal vor der Frage "machen wir Scrum oder Kanban"? Und wie muss dann das Team aufgestellt sein?
Keine Forderungen
Kanban stellt mit seinem Credo "Beginne mit dem, was du gerade tust" keine Anforderungen an die Zusammensetzung eines Teams. Das bedeutet, es muss weder crossfunktional sein noch müssen alle zusammen sitzen – auch wenn beides in vielen Fällen sehr schlaue Ideen sind. Aber Kanban ist erst einmal wertneutral. In der Kanban-Methode selbst ist kein Urteil darüber enthalten, was gut und was schlecht ist. Sie gibt uns aber die Möglichkeit, das, was wir vorfinden, zu verbessern.
Veränderungen erzeugen Widerstand
Anforderungen durch eine Methode erzeugen typischerweise Veränderungen – die wenigsten Unternehmen oder Teams sind genau so aufgestellt, wie es die Methode erfordert.
Nehmen wir als Beispiel einen Designer in einem Scrum-Team. Der könnte vom ScrumMaster aufgefordert werden, bei den Planungsrunden jede User-Story mitzuschätzen. Der Mitarbeiter muss also wegen einer Methode sein Verhalten ändern. Auch bei so kleinen Änderungen wie dieser kann das zu Widerstand führen. Besonders ärgerlich ist das bei Änderungen, die vielleicht gar nicht notwendig wären.
Ein Team hat normalerweise eine Reihe von Aufgaben, die es erfüllen soll. Die Frage, die auf dieser Team-Ebene gestellt werden muss, beschäftigt sich nicht damit, wie das ideale Team aufgestellt ist und welche Aktivitäten es durchführt. Sie lautet stattdessen: "Welche Unzufriedenheiten existieren aktuell in Bezug darauf, wie die gestellten Aufgaben erfüllt werden?" Diskussionen über die Teamstruktur und das Verhalten können dann anhand von wirklich auftretenden Problemen geführt werden. Das ist bezüglich unnötiger Widerstände ein riesiger Unterschied!
Das Team als Service
Sehen wir ein Team abstrakt unter Zuhilfenahme der "Kanban-Linse" ( Zur Kanban-Linse folgt noch ein Artikel. Hier sei erst einmal auf David Anderson verwiesen) an, entsteht eine Dreiteilung: Die Service-Schnittstelle zur Annahme von Aufgaben, die Serviceerfüllung und die Bereitstellung der Ergebnisse.
Für diese drei Punkte können eine ganze Menge Unzufriedenheiten innerhalb und ausserhalb des Services auftreten:
- Mangelnde Geschwindigkeit im Durchlauf
- Zu geringer eigener Anteil am Eingangsvolumen – "Ich komme nicht häufig genug dran!"
- Geringe Qualität der Servicebereitstellung – "Es kommen nur fehlerhafte Produkte heraus."
- Übermäßige Interne Belastung der Mitarbeiter oder technischer Ressourcen
- Mangelhafte Eigenschaften des erbrachten Services ("Nicht nur Konzepte! Vollfunktionale Software möchte ich!")
Unzufriedenheiten zuordnen
All dies sind valide Unzufriedenheiten und man sollte keine von Ihnen verurteilen oder leichtfertig beiseite wischen. Es werden allerdings maximal zwei davon durch die Teamzusammensetzung beeinflusst: Der Service sollte sowohl in der Lage sein, die geforderten Eigenschaften zu erfüllen, als auch die Qualität des Ergebnisses zu sichern. Bei einem Softwareentwicklungsteam sollte also mindestens ein Programmierer an Board sein, sonst kommen nur Designs und Powerpointfolien hinten heraus.
Kanban sieht die Verantwortung , die restlichen Unzufriedenheiten zu beheben, bei allen, die das Arbeitssystem drum herum gestalten.
Lösungen beim Problem ansetzen
Um mit den Unzufriedenheiten umzugehen, sieht Kanban dieses Vorgehen vor: Unzufriedenheit identifizieren, Erwartungen klären, gemeinsam Experimente zur Veränderung beschliessen. Dann später ansehen, wie sich die Unzufriedenheiten entwickelt haben und gegebenenfalls Änderungen einbringen.
Die Lösung muss sich dabei immer am Problem orientieren. Sie muss also die Unzufriedenheiten lösen. Man sollte also nicht vorschnell Proxy-Performance-Indikatoren verwenden, von denen man meint,
dass Sie das Problem ausreichend abbilden. Nach meiner Erfahrung tun sie das nie.
Zurück zur Teamzusammensetzung: Qualität und Form des Service werden durch die Teamzusammensetzung beeinflusst. Hier muss also zuerst geklärt werden, welche Erwartungen an den Service gerichtet werden, damit danach die Zusammensetzung oder Qualifikation des Teams verändert werden kann. Kanban schreibt also nicht vor, wie das Team – oder abstrakt gesprochen der Serviceerbringer – strukturiert sein muss, es ist situationsabhängig.
Beispiel Teamzusammensetzung bei Scrum
Bei Scrum sind gewisse Vorbedingungen durch das Framework an und für sich gegeben, beispielsweise der Einsatzort: "Entwicklung und Wartung komplexer Produkte". Dies erfordert enge Zusammenarbeit verschiedener Disziplinen in einem grossfunktionalen Team. Diese Zusammenarbeit funktioniert am besten, wenn alle an einem Ort sitzen und von Angesicht zu Angesicht kommunizieren können, daraus folgt die Forderung nach gemeinsamen Arbeitsplätzen. Erwartet man also ein komplexes Produkt, das möglichst innovativ sein sollte und das eine hohe Qualität besitzt, sollte man sich nicht wundern, wenn das nicht eintritt, wenn die Bedingungen dafür nicht herrschen. Wenn diese Erwartungen – und die Unzufriedenheit übe reine Nichterfüllung – klar sind, kann man über eine Neubesetzung oder Ergänzung des Teams nachdenken.
Ausblick: Unternehmen um die Arbeit herum strukturieren
Die Implikation der Denkweise, dass der Serviceerbringer zur erwarteten Servicequalität passen muss, ist: je volatiler die Erwartungen an einen einzelnen Service oder ein Netzwerk aus Services sind, desto agiler muss die Organisation in ihrer Restrukturierung sein. Die Frage ändert sich also von "Wie müssen wir Arbeit schneiden, damit wir sie mit den bestehenden Teams erfüllen können" zu "Wie müssen wir die Organisation verändern, um die anstehende Arbeit möglichst gut zu erledigen". Hier kann ein kleiner Wink in Richtung Beta Codex nicht ausbleiben.
Zur Beruhigung: Viele Märkte ändern sich nicht stündlich. Im "noch weiter anzupassen"-Stadium werden die meisten Teams und Abteilungen trotzdem bleiben.