Ich denke, andere haben bereits gute Antworten geliefert, aber ich werde meine nur hinzufügen, weil ich denke, dass Ihr Team gerade zu Scrum gewechselt ist und Sie sich jetzt in einer sehr ähnlichen Position befinden, als wir angefangen haben.
Zunächst einmal war unsere Einführung in Agile und insbesondere in Scrum nicht sehr reibungslos. Grundsätzlich kam das Management herunter und sagte, von diesem Tag an werden Sie Scrum machen und dies ist ein Prozess, dem Sie alle folgen werden. Soviel zu People over Process .
Der Prozess, dem wir ursprünglich gefolgt sind (blind, möchte ich hinzufügen), verlief sehr ähnlich wie Sie es beschrieben haben. Die Leute bekommen Aufgaben zugewiesen, jeder wird gebucht und wir gehen alle zurück zu unseren Schreibtischen und stecken weg. Dann haben wir jeden Tag ein langweiliges Stand-up-Meeting.
Der Schlüssel zu erkennen ist, dass es bei Agile und Scrum tatsächlich um Menschen geht. Wenn das Team mit der Iterationsplanung beginnt, lassen Sie sich von Ihrem Scrum-Master (der wahrscheinlich Ihr Manager ist) nicht Stunden, Geschichten und Aufgaben zuweisen. Es liegt ganz beim Team. Ich denke, für viele Leute ist dies ein sehr schwieriges Konzept, weil sie jahrelang zuvor zur Arbeit gekommen waren und einen Chef (Manager, technischer Leiter ...) hatten, der einfach Arbeit zuweisen würde. Sie tauchen in Scrum ein, aber jeder (einschließlich Scrum Master selbst) arbeitet weiterhin im selben Modus.
Eines Tages werden Sie es satt haben, also werden Sie anfangen, Bücher und Blogs zu lesen und beim Stapeltausch immer wieder Fragen wie diese zu stellen. Die Erkenntnis, die Sie erhalten, ist, dass Sie als Entwickler und Ihre Teamkollegen die treibende Kraft hinter dem Festlegen von Geschichten und dem Zuweisen von Aufgaben sein sollten. Wenn Sie der Meinung sind, dass Sie von der Paarprogrammierung profitieren werden, erstellen Sie auf jeden Fall zwei Aufgaben für jeden der Ingenieure und weisen Sie beiden Stunden zu. Das einzige, was Scrum Master tun sollte, ist die Geschwindigkeit anhand abgeschlossener Storys zu messen, die Sie in der vorherigen Iteration als Team geliefert haben.
Eine andere Sache, die mich nervt, ist, wie den Leuten gesagt wird, dass ihre Kapazität IMMER 75% der Gesamtstunden beträgt. Deshalb verpflichten sie sich dazu und beschweren sich dann für die gesamte Dauer der Iteration, dass a) sie nicht können Ihnen helfen oder b) sie können nicht das Richtige tun, weil ihnen zu viele Stunden zugewiesen wurden. Den Leuten sollte nicht gesagt werden, wie viele Stunden sie festlegen sollen, und sie sollten auf jeden Fall zurückschieben, wenn der Scrum Master versucht, so etwas zu ziehen! Jeder sollte sich genau dazu verpflichten, womit er sich wohl fühlt. Zum Beispiel bin ich ein Teamleiter und lande häufig in einer zufälligen ungeplanten Designdiskussion oder helfe jemandem mit Code oder bei der Fehlerbehebung bei seltsamen Dingen, sodass meine Kapazität nie über 50% liegt.
Unser Team hat 4 Release-Zyklen gebraucht, um zu lernen, die oben genannten Dinge nicht zu tun, und obwohl wir uns definitiv verbessert haben, sind wir nicht einmal halbwegs agil, wenn Sie die Experten fragen. Also noch viel zu lernen.
Update 1: Antwort auf Cliffs Kommentar
Nun, Sie haben Ihre Ohren angeboten, also hier ist es ...
Sie haben Recht, kultureller Wandel ist der Schlüssel, aber dieser Wandel muss nicht auf Führungsebene stattfinden. Ihr eigener Gruppenmanager kann die Kultur in Ihrem Team ändern und Sie von der Unternehmens-BS isolieren, mit der er sich befassen muss. Was Sie beschreiben, waren genau wir von 2007 bis 2010. Unser Team (und auch andere Teams) haben Release für Release gefloppt. In einer der Releases, die den "Prozess des Agilismus" des Managements verwenden, schaffen wir es, dass 9 Personen die Arbeit produzieren, die normalerweise von einer einzelnen Person erledigt wird, und wir haben die doppelte Zeit gebraucht. Ich hatte so viel Freizeit, dass ich sogar meinen Lebenslauf aktualisiert habe.
Dann hatte ich ein Gespräch mit meinem Chef und erklärte ihm all diese Dinge, wie agil Menschen sind. Wenn Sie möchten, dass wir uns um das Produkt kümmern, lassen Sie uns Entscheidungen treffen, die sich auf unsere Arbeit und Lieferung des Produkts auswirken. Ich denke, er hat beschlossen, daraus ein Experiment zu machen, er hat jede einzelne Änderung vorgenommen, die wir ... nun, hauptsächlich ich selbst, aber ich spreche viel mit dem Rest des Teams, daher 50% Kapazität :) ... vorgeschlagen. Es ist möglich, dass er dachte, wenn er alle Änderungen vornimmt, die wir verlangen, und wir immer noch scheitern, wird er mit einem siegreichen "Ich habe es dir gesagt" zurückkommen.
In den letzten 12 Monaten haben wir so viel "Dummes" beseitigt, dass es nicht einmal lustig ist. Unsere Stand-up-Meetings sind jetzt tatsächlich sinnvoll, weil wir zusammenarbeiten, nicht isoliert. Wir sind (zumindest vorerst) immer noch Eigentümer bestimmter Teile des Produkts, aber wir wechseln auch sehr häufig in den Code des jeweils anderen. Wir führen ständig Codeüberprüfungen durch, damit nicht nur die Teammitglieder anderen Code lernen, sondern auch bessere Codierungs- und Designtechniken. Wir haben das monolithische, riesige "agile" Team in drei verschiedene Teams aufgeteilt, sodass Planungs- und andere Besprechungen viel kürzer sind und die Leute sich tatsächlich um sie kümmern, weil sie nicht herumsitzen und über Dinge hören, die ihnen egal sind. ICH' Ich habe Nächte gesehen, in denen 4 von 5 unserer Jungs (eines der Teams) abends um 23 Uhr online waren und niemand uns tatsächlich gesagt hat, dass wir hart arbeiten müssen oder uns jemals unter Druck gesetzt haben, über 40 Stunden zu arbeiten. Menschen, die sich vor einem halben Jahr nicht weniger interessieren konnten, sind plötzlich engagiert und aufgeregt über die Arbeit, die sie leisten. Und alles, was unser Manager brauchte, war zu sagen: "Ihr entscheidet, was richtig ist und tut, was ihr tun müsst, und ich werde Corporate BS so weit wie möglich aus dem Team heraushalten."
Es begann als Experiment (mein Verdacht, das hat er mir nie gesagt), aber jetzt tritt unsere Gruppe im Vergleich zu anderen Entwicklungsgruppen in der Abteilung in den Hintern und wir haben sogar andere Entwickler, die jetzt versuchen, zu uns zu kommen und sich uns anzuschließen.
Die größte Hürde für uns seit dieser Änderung (und auch heute noch ein Problem) war die Tatsache, dass Ingenieure in einer normalen Unternehmensumgebung wie experimentelle Mäuse in einem Käfig sind. Selbst wenn Ihr Manager beschließt, wirklich "agil" zu werden und den Käfig zu entfernen, sind alle so lange in diesem Käfig, dass sie nicht einmal erkennen, dass sie frei sind. Trotz aller Freiheit tun sie so, als wären sie immer noch eingeschränkt. Ich denke, was helfen würde, wenn mindestens wenige Leute im Team wären (wie Sie selbst), die über die Grenzen der Gruppe hinausgehen und nach besseren Möglichkeiten suchen, Dinge zu tun. Dann komm zurück in diese Gruppe und rühre sie ein wenig auf.
In Ihrem Fall ist gepaarte Programmierung möglicherweise keine Lösung, wenn Sie nach einer anderen externen Kraft suchen, die in das Team kommt und ihnen sagt, wie sie arbeiten sollen. Werfen Sie stattdessen die Regeln raus, setzen Sie sich ohne Management zu ihnen und fragen Sie sie, was sie tun möchten. Was wird sie glücklich machen? Produktiv? Identifizieren Sie die größten Probleme und fragen Sie das Team, welche Lösung Ihrer Meinung nach sein sollte.