Bei der Einführung von BDD steht zuerst natürlich die Frage im Raum wie funktioniert das alles? Hier scheint es mir sinnvoll zunächst gemeinsam die Kerninhalte von BDD in einem Workshop und idealerweise mit echten Beispielen aus dem Projekt, zu erarbeiten. Doch für gewöhnlich machen die Feinheiten den Unterschied und es tauchen schnell Probleme mit Formulierung und Aufbau der Szenarien auf. Habt ihr vielleicht schon Erfahrungen mit solchen Problemen bei "Feinheiten" und wie würdet ihr in der Rolle als Scrum Master hier unterstützen? Ich freue mich auf eure Antworten!
2 Antworten
Zunächst einmal, wäre es mir wichtig, die Argumente zu überprüfen, warum man BDD überhaupt einsetzen möchte. Was erwartet man sich davon? Das muss zunächst allen klar sein. Dann kann man auch zielgerichtet BDD ausprobieren und üben. Falls die Erwartungshaltung noch nicht allen klar ist, dann würde ich hier zuerst ansetzen und dies klären. Und falls sich heraus stellt, dass man eigentlich gar keine große Erwartungshaltung hat... dann aufhören! BDD anzuwenden, nur um BDD zu machen wäre das Schlechteste von allen Argumenten.
Bzgl. des Vorgehens: Hm, wenn es den einen Weg gäbe, wie man BDD perfekt anwendet, dann würden es einfach alle so machen. Den gibt es aber nicht. Es ist so ähnlich wie mit Skifahren. Wie das perfekt aussieht, kann man sich im Fernsehen ansehen. Wie man dahin kommt? Üben, üben, üben.
Zur Unterstützung würde ich als Scrummaster versuchen, mit dem Team herauszufinden, wie man den messen könnte, ob die BDD-Bemühungen eine positive Auswirkung auf die Arbeit haben. Z.B., wie oft (oder wie viel weniger) müssen wir noch etwas nachreichen, damit der Kunde wirklich zufrieden mit der Lösung ist. Wie oft gibt es Unklarheiten während der Entwicklung? Nehmen diese ab durch die Anwendung des BDD-Prinzips? Falls nicht, weiter bohren, was helfen könnte. Einen Einstieg bzw. ein paar konkrete Referenzbeispiele gut angewendeten BDDs findet man leicht im Internet. Ausgehend davon, wie das abstrakte Prinzip in der Praxis von anderen angewendet wird, kann man üben, das auf die eigene Situation anzuwenden. Und wenn es nicht von Anfang klappt... dran bleiben. Es ist noch kein Meister vom Himmel gefallen :) Apropros Meister: Warum nicht einen ausgewiesenen Könner auf dem Gebiet für ein paar Tage ins Haus holen? Als Scrummaster muss man ja nicht alles selbst können, sondern man ist insbesondere auch dann eine Hilfe für sein Team, wenn man ein entsprechendes Training für sein Team mit einem externen Könner organisiert, vorbereitet und durchführt. Das kann z.B. sein für ein entsprechendes Trainings-Budget beim Management zu werben, einen passenden Könner im Internet zu recherchieren, vielleicht eine bewusst externe Location suchen und auswählen, Erwartungshaltung und Zielstellung vorab klären usw.
Bzgl. des Vorgehens: Hm, wenn es den einen Weg gäbe, wie man BDD perfekt anwendet, dann würden es einfach alle so machen. Den gibt es aber nicht. Es ist so ähnlich wie mit Skifahren. Wie das perfekt aussieht, kann man sich im Fernsehen ansehen. Wie man dahin kommt? Üben, üben, üben.
Zur Unterstützung würde ich als Scrummaster versuchen, mit dem Team herauszufinden, wie man den messen könnte, ob die BDD-Bemühungen eine positive Auswirkung auf die Arbeit haben. Z.B., wie oft (oder wie viel weniger) müssen wir noch etwas nachreichen, damit der Kunde wirklich zufrieden mit der Lösung ist. Wie oft gibt es Unklarheiten während der Entwicklung? Nehmen diese ab durch die Anwendung des BDD-Prinzips? Falls nicht, weiter bohren, was helfen könnte. Einen Einstieg bzw. ein paar konkrete Referenzbeispiele gut angewendeten BDDs findet man leicht im Internet. Ausgehend davon, wie das abstrakte Prinzip in der Praxis von anderen angewendet wird, kann man üben, das auf die eigene Situation anzuwenden. Und wenn es nicht von Anfang klappt... dran bleiben. Es ist noch kein Meister vom Himmel gefallen :) Apropros Meister: Warum nicht einen ausgewiesenen Könner auf dem Gebiet für ein paar Tage ins Haus holen? Als Scrummaster muss man ja nicht alles selbst können, sondern man ist insbesondere auch dann eine Hilfe für sein Team, wenn man ein entsprechendes Training für sein Team mit einem externen Könner organisiert, vorbereitet und durchführt. Das kann z.B. sein für ein entsprechendes Trainings-Budget beim Management zu werben, einen passenden Könner im Internet zu recherchieren, vielleicht eine bewusst externe Location suchen und auswählen, Erwartungshaltung und Zielstellung vorab klären usw.
Wenn es einen Grund gibt zu glauben, dass BDD die Lösung für ein existierendes Problem sein kann, dann sollte man es ausprobieren. Ich halte viel von BDD. Es funktioniert aber nur, wenn alle Beteiligten die Vorgehensweise unterstützen und mitmachen.
Egal wie viel man sich vorbereitet, es wird am Anfang Schwierigkeiten geben, man wird sich unsicher beim Formulieren der Anforderungen fühlen oder man wird es alles nicht ganz richtig machen. Das ist aber nicht schlimm. Schlimm wäre nur a) sich nicht zu trauen das auszuprobieren und b) nicht aus den Fehlern zu lernen.
Egal wie viel man sich vorbereitet, es wird am Anfang Schwierigkeiten geben, man wird sich unsicher beim Formulieren der Anforderungen fühlen oder man wird es alles nicht ganz richtig machen. Das ist aber nicht schlimm. Schlimm wäre nur a) sich nicht zu trauen das auszuprobieren und b) nicht aus den Fehlern zu lernen.