Scrum und Agile zu praktizieren ist auch für Entwickler schwierig

Ich führe gerade den Scrum-Prozess in der Entwicklungsabteilung eines großen Unternehmens ein. Ich habe die Probleme vorweggenommen, die wir derzeit mit dem Rest der Organisation haben. Die Spezifikationen sind vage und mehrere Monate alt, Personen, die wir für Informationen und Feedback benötigen, sind schwer zu finden. Also kurz gesagt, die üblichen Hindernisse. Wenn Sie Entwicklungsteams beobachten, werden Sie in der Regel hören, wie sich die Mitarbeiter über diese Dinge beschweren. Aber es wird nicht oft darüber gesprochen, dass auch Entwickler, die neu in Scrum sind, einige Dinge zu überwinden haben. Scrum-Praktiken Es gibt ein paar Dinge, die Scrum erzwingt, die aber nicht immer vom Entwicklungsteam akzeptiert werden. Die Zeit, die Scrum für Besprechungen wie das Stand-up und die Sprint Review benötigt, wird als Overhead betrachtet. Es ist schwer, die Leute zu motivieren, innezuhalten und über ihren Prozess nachzudenken oder über ihre Probleme zu sprechen, wenn sie nur daran denken, wie sie aus diesem Meeting herauskommen. Es ist auch ziemlich schwer für die Leute, nicht an all die Dinge zu denken, die schon immer schief gelaufen sind, sondern nur an die Probleme, die Sie im letzten Sprint hatten. Sich über Probleme zu beschweren, die außerhalb Ihres Einflussbereichs liegen, ist nicht produktiv, aber sich nur auf ein paar Wochen zu konzentrieren, ist anstrengender, als ich erwartet hatte. Handeln Sie In Scrum werden Entscheidungen schnell getroffen und gleichzeitig aktiv nach Feedback zum Ergebnis gesucht. Das kann auch eine Störung der gewohnten Arbeitsweise sein. Normalerweise werden Entscheidungen sehr sorgfältig getroffen, mit vielen Diskussionen über das Für und Wider. In Scrum gehen wir davon aus, dass Entscheidungen schnell getroffen werden sollten, um das Projekt am Laufen zu halten, und in den meisten Fällen ist das Endergebnis akzeptabel. Entwickler daran zu hindern, verschiedene Optionen zu erforschen und Proof of Concepts zu erstellen, fühlt sich an, als würde man sie in ihrer Arbeitsweise einschränken. Ich denke, dass Scrum viel Freiheit zulässt, aber nicht die Freiheit, Zeit damit zu verschwenden, sich mit Optionen aufzuhalten. Der Produktverantwortliche entscheidet Am schwierigsten ist für mich die Entscheidung über technische Fragen. Der Product Owner entscheidet über die Prioritäten, auch über die Aufgaben, die sich die Entwickler ausgedacht haben. Das Team ist dafür verantwortlich, die Arbeit so zu erledigen, wie sie es für richtig halten, und dabei die Qualitätsstandards einzuhalten, aber anderen Dingen wie 'wir sollten alle Tests automatisieren' kann der Product Owner eine niedrigere Priorität einräumen. Die Erstellung eines Testskripts für Funktion X" ist vielleicht weniger ehrgeizig und erhält eine höhere Priorität oder kann sogar als notwendiger Schritt zur Fertigstellung einer Funktion angesehen werden. Dieses Feilschen zwischen dem Product Owner und dem Team ist ein neues Phänomen, das in Frustration enden kann, weil den Entwicklern nicht die Zeit gegeben wird, die Dinge 'perfekt' zu machen. Alles sollte sich an den Geschäftszielen orientieren, und das lässt manchmal keinen Raum für Optimierungen oder Optimierungen. Hören Sie auf das Team Was kann der Scrum Master also tun? Hören Sie zunächst einmal dem Team zu. Meistens haben die Frustration und die Beschwerden eine ernsthafte Ursache. Fordern Sie das Team auf, sich etwas einfallen zu lassen, um diese Ursachen zu beseitigen. Aber an manche Dinge in Scrum muss man sich erst gewöhnen, manche Dinge werden sich für die Entwickler nie richtig anfühlen. Ich denke, wenn Scrum eingeführt wurde, ist die Zusammenarbeit im Team und die Befriedigung darüber, dass die Dinge erledigt werden und die Stakeholder zufrieden sind, mehr als genug Belohnung, um das Team motiviert zu halten.