Warum Sie mit Design Thinking anfangen sollten, wenn Sie ein erfolgreiches Scrum Projekt starten.
Als Agile Coach habe ich in den letzten Jahren die Möglichkeit gehabt, verschiedene Scrum Einführungen zu begleiten und unterschiedliche Teams zu coachen. Hierbei konnte ich mit den Teams bei der Effizienz und Zuverlässigkeit große Erfolge erzielen. In einem zentralen Bereich blieben meine Teams allerdings hinter meinen Erwartungen zurück: Nutzerzentrierung (User Centricity).
Um dieses Problem besser zu verstehen, möchte ich Ihnen von dem besten Team erzählen, mit dem ich zusammenarbeiten durfte. Es handelte sich um ein recht neu zusammengestelltes Scrum Team aus zum größten Teil jungen Kollegen und einem unerfahrenen Product Owner. Unterschiedliche Erwartungen, besonders an die Qualität bei der Abnahme der User Stories, führten zu Spannungen zwischen Development Team & Product Owner. Da sich das Development Team nicht genug vom Scrum Master verstanden fühlte, habe ich dessen Aufgabe übernommen, um Spannung aus dem Team zu nehmen.
Wir haben es relativ schnell geschafft, mit den zuständigen Managern und Stakeholdern den Backlog neu zu priorisieren und den Druck auf das Team zu reduzieren. Durch realistischere Schätzungen des Umfangs der User Stories waren wir daraufhin in der Lage, erwünschte Qualität zum versprochenen Zeitpunkt zu liefern. Auch wenn ich durch verschiedene Maßnahmen in Retrospektiven, Workshops und Events versucht habe, ein starkes Team zu formen, ist keine Maßnahme so effektiv wie Erfolge. Deshalb sind es besonders die ersten beiden Maßnahmen gewesen, die es ermöglicht haben, aus diesem Team – deren erste Erfahrungen von Misstrauen und Misserfolgen geprägt waren – ein Team zu formen, das für Zutrauen und Zuverlässigkeit steht.
Es war abzusehen, dass dieses Team meine Unterstützung bald nicht mehr brauchen würde und wieder von einem weniger erfahrenen Scrum Master übernommen werden konnte.
Würde ich die Geschichte hier beenden, wäre es eine reine Erfolgsgeschichte, aber ich wollte, dass auch meine letzten Wochen bei diesem Team zählen.
Deshalb habe ich das Team dazu gedrängt, sich einem Feature anzunehmen, auf das ein spezifischer Kunde schon lange gewartet hat. Ich dachte, es ist ein gutes Beispiel, um mehr Kundenzentrierung zu erreichen. Es war nicht so, dass dies gar nicht berücksichtigt wurde. Es gab zwei Treffen pro Jahr, in denen allen Kunden die Ergebnisse des letzten halben Jahres vorgestellt wurden und ein Ausblick auf die Zukunft gegeben wurde.
Allerdings war ich der Meinung, dass dies nicht ausreicht, um die Kundenwünsche genau zu verstehen. Also haben wir angefangen, regelmäßig mit dem Kunden in kurzen Skype Meetings über das Feature zu reden. Als wir der Meinung waren, eine gute Lösung gefunden zu haben, vereinbarten wir einen Termin, in dem wir vormittags unsere Lösung und ein paar andere Themen vorstellen wollten und nachmittags eine Werksführung anstand.
Wir haben den Trip zu unserem Kunden als richtiges Event geplant und sind mit einer verhältnismäßig großen Delegation und einem richtig guten Gefühl losgeflogen. Bei unserem Kunden angekommen, wurden wir sehr herzlich empfangen, da wir diejenigen waren, die endlich das ersehnte Feature dabei hatten. So zumindest war der Plan.
Schon in der ersten Stunde unseres Meetings stellte sich heraus, dass unsere Lösung zwar theoretisch den Requirements entsprach, aber für unseren Kunden praktisch wertlos war. Wir haben das Meeting unterbrochen, um im Team und mit unseren Kollegen zuhause unter Hochdruck eine andere Lösung zu finden.
Doch schnell wurde klar: Mit dem, was wir vorbereitet hatten, würden wir nicht die Wünsche des Kunden erfüllen können. Also, zurück ins Meeting: Fehler eingestehen, wieder „zurück auf Los“, Stimmung am Boden.