Die Märkte ändern sich seit vielen Jahren. Kunden können Produkte von nahezu allen Unternehmen auf der Welt vergleichen und kaufen. Unternehmen welche ihre Kunden mit den richtigen Produkten erreichen wollen, sehen sich neuen Herausforderungen gegen über. Viele versuchen diesen Herausforderungen mit Transformationen in den verschiedensten Bereichen zu begegnen, neue Formen der Zusammenarbeit, intern, wie auch zum Kunden sind das Ziel. Ist es eine solche agile Transformation, sind es oft Agile Coaches, welche z.B. Scrum Master und Product Owner im Unternehmen unterstützen sollen. Mit welchen Mitteln ist eine agile Transformation erfolgreich, wie sollten die Personen sein, die diese begleiten und was macht einen guten Scrum Master und/oder Agile Coach aus?
Das Unternehmen
Die ReG AG ist ein Unternehmen, welches verschiedenste Softwareprodukte anbietet. Das Zugpferd war lange Jahre die SuS Suite, doch die Kunden wünschen sich mehr und andere Feature. Die aktuellen Strukturen sowohl im Unternehmen, wie auch in der Software Architektur, geben keine Möglichkeit, schnell auf die Kunden reagieren zu können. Britta ist eine erfahrene Expertin im Agilen Umfeld, sie hat schon viele agile Transformationen in Unternehmen begleitet, von einzelnen Teams, bis hin zu ganzen Bereichen. Silke ist der IT-Vorstand im Unternehmen, sie kennt Britta noch aus einem anderen Unternehmen und treibt die Transformation im Unternehmen voran. Howard ist recht neu im Unternehmen, er hat gerade eine Schulung zum Scrum Master gemacht und möchte nun durchstarten. Silke traut ihm zu, sein erstes Team, bestehend aus Developern und Product Owner, als Scrum Master zu unterstützen. Silke fordert allerdings, dass Britta ihn begleitet, was ihn nicht sonderlich begeistert. Er ist davon überzeugt, dass er für diesen Job nach der zweitägigen Schulung und der bestandenen Prüfung hinreichend gerüstet ist. Die 19 Seiten Scrum Guide, die kennt er, was soll ihm Britta schon noch beibringen. Howard weiß genau, was er will und wie er das Team befähigen will.
Das erste Refinement im Team
Am Montag steht das erste Refinement vom Team an, welches er begleiten will. Er ist sich nicht sicher, ob die Wocheneinteilung so richtig ist. Es wurde ihm übermittelt, dass die Sprints zwei Woche lang sind. Das Review und die Retrospektive sind Dienstagnachmittag und Mittwochvormittag ist das Sprint Planning. Das Team hat ihn zum Refinement eingeladen, da es ein paar Anforderungen aus dem Produkt Backlog besprechen möchte. Er hört sich die Diskussionen bzgl. der Anforderungen eine halbe Stunde an, rollt ab und zu mit den Augen. Seinem Empfinden nach, sind die Anforderungen einfach nicht genau genug beschrieben, irgendwie scheint der Product Owner nicht seinen Job zu machen. Das Team ist in einer regen Diskussion und ergänzt einzelne Anforderungen und schätzt einige.
Howard denkt sich, dass dieses Refinement viel effizienter ablaufen hätte können, so der Product Owner vorher richtig gearbeitet hätte, so viele Fragen, das scheint unnötig. Er geht zum Product Owner, bitte um ein Gespräch. Ohne abzuwarten, was der Product Owner zu sagen hat, schlägt er ihm direkt vor, dass alle Anforderungen, bevor sie mit dem Team besprochen werden, als User Story geschrieben werden müssen, ebenso soll sich der Product Owner über die Akzeptanzkriterien Gedanken machen, und diese direkt an die User Story anhängen. Der Product Owner fühlt sich etwas überfahren, sagt aber zu, bis zum Sprint Planning noch ein paar User Stories zu formulieren.
Sprint Planning
Am Mittwoch im Sprint Planning stellt der Product Owner mehrere User Stories vor, welche er gern im Sprint umgesetzt haben möchte. Der Product Owner hat ebenso Akzeptanzkriterien erstellt, welche er dem Team vorstellt. Howard ist sichtlich zufrieden mit dieser Story. Dass das Team keine weiteren Fragen hat, ist noch das Sahnehäubchen in seinen Augen, so kann das Sprint Planning schnell und effizient abgeschlossen werden.
Das Team setzt die User Story im Sprint genauso um, wie vom Product Owner beschrieben, alle Akzeptanzkriterien sind ebenfalls erfüllt. Im Review stellt sich heraus, dass die User Story zwar richtig entwickelt wurde, dennoch nicht die Richtigen sind, so nicht den Erwartungen der Stakeholder genügt. Howard ist enttäuscht vom Team und vom Product Owner. Zu Mittag trifft er sich mit Britta, um davon zu berichten. Er nimmt sich vor, die Zügel anzuziehen und dem Product Owner einen Business Analysten an die Seite zu stellen, damit der dieser entlastet ist und die Anforderungen genauer beschrieben werden.
Britta gibt zu bedenken, dass Howard die Thematik mit den User Stories und Akzeptanzkriterien wohl etwas zu einseitig betrachtet hat, die Vorgabe für den Product Owner zu einschränkend war. User Stories sind ein Kommunikationstool, gerade in der Kommunikation liegt der Schlüssel zum Erfolg. Britta erinnert Howard an das Agile Manifest #1 „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“.
Howard ist nachdenklich an diesem Tag, er möchte es besser machen .. nur wie ..