Der reinen Lehre nach ist alles klar: Der Product Owner schreibt die User-Stories, für die das Agile Team in der Software-Entwicklung eine Lösung entwickeln soll. Er schreibt jede User-Story so, dass sie – umgesetzt – einen Mehrwert erzeugt. Und anschließend legt er die Reihenfolge fest, nach der das Team die Stories bearbeiten soll: Die Story, die den größten Mehrwert bietet, sortiert er ganz oben ein. Auf diese Aufgabe stürzt sich das Team gemeinschaftlich und mit geballter Kraft, bis sie umgesetzt ist. Dann folgt die nächste Story in der Rangierung.
So weit die Theorie. In der Praxis sieht das jedoch oft anders aus.
Nur die Marie
„Nee, du, das kriegen wir so nicht hin!“ Entwickler Kevin zeigt Product Owner Richard im Planning die Liste der Stories auf dem großen Bildschirm.
„Und warum?“, fragt Richard.
„Ganz einfach:“, erwidert Kevin, „Wenn wir die Story zuerst angehen sollen, drehen Johannes und ich nächste Woche Däumchen. Wir sind Oberflächenentwickler. Wir haben für diese ganzen Analytik-Geschichten nicht die richtigen Skills. Das kann bei uns nur die Marie. Und sie kann auch nicht hexen, sondern braucht ihre Zeit.“
„Ja, und jetzt?“ Richard schaut Scrum Master Jens halb zornig, halb ratlos an.
Flexibel im agilen Team – oder doch nicht?
Jens zuckt mit den Achseln: „Weiß ich auch nicht. Ich habe dem Chef schon ein paar Mal gesagt, dass wir mehr Leute mit Analytik-Skills brauchen. Aber der winkt nur ab und meint, wozu wir eigentlich ein Agiles Team sind? Wir könnten uns doch gegenseitig flexibel unterstützen. Können wir aber eben nicht. Analytik und Oberflächenentwicklung sind zwei paar Stiefel.“
Beide starren auf den riesigen Bildschirm an der Wand. Dann greift Jens die Maus und fährt die Liste der Stories ab.
„Schau,“ sagt er schließlich zu Richard, „wenn wir diese zwei Stories hier unten und noch die drei da nach oben priorisieren, dann haben auch Johannes und Kevin etwas zu tun. Und wir schaffen im Output diese Woche eine vorzeigbare Zahl an erledigten User Stories …“
Keiner findet’s gut
Passt die Verteilung von Skills in einem Agilen Team nicht zu den Aufträgen, die es bekommt, dann entsteht eine Schieflage: Die einen haben mehr als genug zu tun, während die anderen herumsitzen. Das findet im Team keiner gut, weil das zu Spannungen führt. Das findet aber auch im Management keiner gut, weil die Ergebnisse hinter den Erwartungen zurückbleiben.
Und doch habe ich schon oft von Scrum Mastern gehört, dass sie bei ihrer Führungskraft auf taube Ohren stoßen, wenn sie auf das Ungleichgewicht bei den Skills im Team hinweisen. Das ist eine gefährliche Vogel-Strauß-Politik von Seiten des Vorgesetzten.
Eine Frage der Skills
Wenn Sie von Ihrem Scrum Master etwas in der Richtung hören, haben Sie zwei Möglichkeiten: entweder Sie sorgen für eine Teambesetzung mit der nötigen Skill-Verteilung – oder Sie schrauben Ihre Erwartungen an die Ergebnisse nach unten.
Damit Sie von solchen Ergebniseinbrüchen nicht überrascht werden oder – noch besser – sie von vorne herein vermeiden, empfehle ich Ihnen als Führungskraft folgendes: Gehen Sie proaktiv auf Ihre(n) Scrum Master und die Teams zu. Fragen Sie ihn oder sie, ob die richtigen Leute an Bord sind. Oder wie das Team denn so funktioniert.
Oder Sie fragen den Product Owner, wie er seine Stories schreibt – denn Sie haben ja jetzt gesehen, warum die Antwort auf diese Frage für Sie wichtig sein kann.
Ihre Carolin Salamon
