Scrum = murcS
"Sie wissen ja, was Scrum rückwärts heißt?" Diese Frage stellte mir vor kurzem ein Entwicklungsleiter - nennen wir ihn Herr Ypsilon - mit süffisantem Grinsen im Gesicht.
"Ja, murcS. Das, was heraus kommt, wenn Scrum nicht richtig gelebt wird!", war meine Antwort.
"Das ist ja alles ganz nett, aber wenn ein Softwareentwickler bei der Hardwareentwicklung mitschätzen soll, dann hört es bei mir auf!", versuchte er nachzusetzen.
Lasse ich diesen Satz auf der Zunge zergehen, drängt sich mir unmittelbar die Frage auf: Ist dem wirklich so? Wie weit bringen uns die Scrum-Werte in Cross-Functional-Teams, wenn cross-functional einmal nicht gleichzusetzen ist mit "das kann ich auch, ich habe lediglich zu wenig Übung darin"?
"Das ist ja alles ganz nett, aber wenn ein Softwareentwickler bei der Hardwareentwicklung mitschätzen soll, dann hört es bei mir auf!"
In einem nahezu homogenen sozialen Umfeld ist eine Diskussion auf Augenhöhe nicht schwierig, oder?
Sehen wir uns folgende Situationen an: Ein Team hat die Aufgabe eine Webapplikation zu entwickeln. HTML5, CSS3, Javascript und Backend as a Service, eine gehostete Lösung. In diesem homogenen Umfeld wird kein Teamglied die Qualifikation seines Kollegen beim Planning in Frage stellen. Die Schätzungen der Story Points werden konstruktiv und auf Augenhöhe im Team diskutiert. Teambildung ist in diesem Fall nicht schwer.
Wie sieht es aus, wenn das Backend selbst entwickelt wird, z.B. mit Java und die Daten in einer SQL-Datenbank gespeichert werden sollen? Das Team wird sich womöglich thematisch etwas gruppieren z.B. in ein HTML/Javascript-Grüppchen, ein Java-Grüppchen und ein SQL-Grüppchen. Das eine oder andere Teammitglied sieht sich vielleicht in mehreren Welten; fühlt sich "cross-functional". Hier wird gleichermaßen konstruktiv und auf Augenhöhe diskutiert werden. Schließlich "sind das alles Programmiersprachen", denn "jeder hat das mal gelernt" und "könnte das auch, es fehlt nur ein bisschen die Übung". Jeder bekommt das Gefühl, er kann die Komplexität der Aufgaben einschätzen und ist offen für die Meinungen seiner Team-Mitglieder.
Was jedoch, wenn das Team tatsächlich cross-functional aufgestellt ist und Komponenten für Industrieanlagen entwickelt werden, die aus Soft- und Hardware bestehen. Unter Umständen ist Know-How von Maschinenbauern gefragt. Hat Herr Ypsilon recht? Hört es in dieser Konstellation auf?
Die Antwort gibt Scrum implizit durch die Scrum Values. Das persönliche "Commitment" ist Ausdruck des eigenen Einsatzes für den Projekterfolg. Das gemeinsame Ziel wird in den "Focus" gerückt und verfolgt. Die "Openness" unterstützt dabei, da erst durch die Offenheit gegenüber Anforderungen und Lösungsansätzen das Verständnis für die zu erledigende Arbeit geschaffen wird. Folglich wird es - um bei dem Beispiel von oben zu bleiben - einem Softwareentwickler wichtig sein zu verstehen, wie die Hardware entwickelt wird, was dabei auf ihn zukommt, welche Aufgaben entstehen. Er benötigt "Courage", den Mut die entsprechenden Fragen zu stellen. Der "Respect" erzeugt das Umfeld, in dem diese klar und konstruktiv beantwortet werden.
Commitment
Focus
Openness
Courage
Respect
Wieviel Mut braucht es die Meinung des anderen zu respektieren?
Kurioserweise ist es oft der Respekt, der sich als der Beginn von Schwierigkeiten im Team identifizieren lässt.
- Wie viel davon ist notwendig, die Meinung eines Kollegen - der sogar eine technische Ausbildung oder ein entsprechendes Studium absolviert hat - zuzulassen?
- Welches Maß an Mut ist aufzubringen, sich in einer Diskussion auf die Argumente einer Kollegin einzulassen, erst recht wenn sie aus einem anderen Fachbereich kommt?
- Wie schwer ist es offen Einwände oder Einschätzungen in die eigenen Überlegungen einzubeziehen?
Ein gutes Scrum-Team etabliert und lebt einen aufgeschlossenen, respektvollen Umgang miteinander, damit in den Refinements - frei von persönlichen Angriffen und Mimositäten - ein Tauziehen um die beste Lösung entsteht. Folglich ist es kein "murcS" und nicht "nur ganz nett" - dann ist es Scrum.