Creo que otros ya proporcionaron buenas respuestas, pero agregaré las mías solo porque creo que su equipo acaba de hacer la transición a Scrum y ahora ustedes están en una posición muy similar a la que teníamos cuando comenzamos.
En primer lugar, nuestra introducción a Agile y más específicamente a Scrum no fue muy fluida. Básicamente, la gerencia bajó y dijo, a partir de este día harás Scrum y este es un proceso que todos seguirán. Demasiado para las personas sobre el proceso .
El proceso que seguimos originalmente (a ciegas, podría agregar) terminó muy similar a cómo lo describiste. A las personas se les asignan tareas, todos se reservan y todos volvemos a nuestros escritorios y nos desconectamos. Luego tenemos una aburrida reunión de pie todos los días.
La clave para darse cuenta es que Agile, y Scrum incluido, en realidad se trata de personas. Cuando el equipo entra en la planificación de iteración, no permita que su maestro Scrum (quien probablemente sea su gerente) le asigne horas, historias y tareas. Está completamente a la altura del equipo. Creo que para muchas personas es un concepto muy difícil de entender porque durante años antes habían venido a trabajar y tendrían un jefe (gerente, líder técnico ...) que simplemente asignaría trabajo. Se sumergen en Scrum, pero todos (incluido el mismo scrum master) continúan operando en el mismo modo.
Un día, te cansarás de esto, así que comenzarás a leer libros, blogs y seguirás haciendo preguntas como esta en el intercambio de fichas. La comprensión que obtendrá es que usted, como desarrollador y sus compañeros de equipo, deben ser la fuerza impulsora detrás de comprometerse con historias y asignar tareas. Si ustedes creen que se beneficiarán de la programación de pares, por supuesto, creen 2 tareas para cada uno de los ingenieros y asignen a ambos horas. Lo único que debería estar haciendo scrum master es medir la velocidad contra historias completadas que entregaste COMO UN EQUIPO en la iteración anterior.
También otra cosa que me molesta es cómo se les dice a las personas que su capacidad SIEMPRE ES el 75% del total de horas, por lo que es a lo que se comprometen y luego, durante toda la duración de la iteración, se quejan de que a) no pueden ayudarlo o b) no pueden hacer lo correcto porque les han asignado demasiadas horas. ¡A las personas no se les debe decir cuántas horas deben comprometerse y sin duda deberían retroceder si scrum master intenta hacer algo como esto! Todos deberían comprometerse a exactamente con qué se sienten cómodos. Por ejemplo, soy un líder de equipo y, con frecuencia, terminaba en una discusión de diseño no planificada al azar, o ayudaba a alguien con el código o solucionaba problemas con cosas extrañas, por lo que mi capacidad nunca supera el 50%.
Le tomó a nuestro equipo 4 ciclos de lanzamiento para aprender a no hacer las cosas que acabo de mencionar y, aunque definitivamente hemos mejorado, si le preguntas a los expertos, ni siquiera somos medio ágiles. Así que todavía hay mucho que aprender a hacer.
Actualización 1: Respuesta al comentario de Cliff
Bueno, ofreció sus oídos, así que aquí está ...
Tiene razón, el cambio cultural es clave, pero este cambio no necesita suceder a nivel ejecutivo. Su propio gerente de grupo puede cambiar la cultura dentro de su equipo y aislarlos de las BS corporativas con las que tiene que lidiar. Lo que usted está describiendo fue EXACTAMENTE sobre nosotros de 2007 a 2010. Nuestro equipo (y otros equipos también) fracasaron lanzamiento tras lanzamiento. En uno de los lanzamientos que utilizan el "proceso para ser ágil" de la gerencia, logramos que 9 personas produzcan el trabajo que generalmente haría una sola persona y nos llevó el doble de tiempo. Tenía tanto tiempo libre que incluso actualicé mi currículum.
Luego, tuve una conversación con mi jefe y le expliqué todo lo ágil que es sobre las personas y que si quieres que nos preocupemos por el producto, déjanos tomar decisiones que afecten la forma en que trabajamos y entregamos el producto. Creo que decidió convertirlo en un experimento, hizo todos los cambios que ... bueno, sobre todo yo mismo, pero hablo mucho con el resto del equipo, de ahí el 50% de capacidad :) ... propuso. Es posible que se haya dado cuenta de que si hace todos los cambios que estamos pidiendo y aún fallamos, regresará con un victorioso "Te lo dije".
Entonces, en los últimos 12 meses, hemos eliminado tanto "estúpido" que ni siquiera es gracioso. Nuestras reuniones de pie realmente tienen sentido ahora porque trabajamos juntos, no de forma aislada. Todavía tenemos la propiedad (al menos por ahora) de partes específicas del producto, pero también nos cruzamos con mucha frecuencia en el código de los demás. Constantemente hacemos revisiones de código para que no solo los miembros del equipo aprendan otro código, sino que también aprendan mejores técnicas de codificación y diseño. Hemos dividido el equipo monolítico gigante "ágil" en 3 equipos diferentes, por lo que la planificación y otras reuniones son mucho más cortas y la gente realmente se preocupa por ellas porque no se sientan y escuchan cosas que no les importan. YO' Hemos visto noches en las que 4 de cada 5 de nuestros muchachos (uno de los equipos) estarían en línea a las 11 p.m. de la noche y en realidad nadie nos dijo que teníamos que trabajar duro ni nos presionaron para que trabajáramos más de 40 horas. Las personas a las que no les importaba menos hace medio año, de repente están comprometidas y entusiasmadas con el trabajo que están haciendo. Y todo lo que hizo falta para que nuestro gerente hiciera fue decir: "ustedes deciden qué es lo correcto y hacen lo que deben hacer, y mantendré a las BS corporativas fuera del equipo tanto como pueda".
Comenzó como un experimento (mi sospecha, él nunca me dijo eso), pero ahora nuestro grupo está pateando el trasero en comparación con otros grupos de desarrollo en el departamento e incluso tenemos otros desarrolladores que ahora están tratando de venir y unirse a nosotros.
El mayor obstáculo para nosotros desde que ocurrió este cambio (y sigue siendo un problema hoy) fue el hecho de que los ingenieros en un entorno corporativo normal son como ratones experimentales en una jaula. Incluso cuando su gerente decide ser realmente "ágil" y retira la jaula, todos han estado en esa jaula durante tanto tiempo que ni siquiera se dan cuenta de que son libres. Entonces, incluso con toda la libertad, continúan actuando como si todavía estuvieran limitados. Creo que lo que ayudaría es tener al menos pocas personas en el equipo (como usted), que salgan de los límites del grupo y busquen mejores formas de hacer las cosas. Luego regresa a ese grupo y revuelve un poco.
En su caso, tal vez la programación emparejada no sea una solución si está buscando otra fuerza externa que venga al equipo y les diga cómo trabajar. En cambio, descarte las reglas, siéntese con ellas, sin administración, y pregúnteles qué quieren hacer. ¿Qué los hará felices? ¿Productivo? Identifique los mayores problemas y luego pregunte a EL EQUIPO cuál creen que debería ser la solución.