Primero, deja de medir la velocidad individual. La velocidad debe medirse a nivel de equipo para un Sprint, y no para individuos. Su equipo entrega un producto de software potencialmente entregable incluso después de Sprint, no individuos. Dado que Scrum se basa en equipos multifuncionales autoorganizados, su velocidad debe incluir todo lo relacionado con la creación de la entrega, desde la preparación de los requisitos hasta la prueba y la verificación.

El siguiente problema es una cuestión de gestión de personal. Si está utilizando Scrum, el proceso se basa en un equipo multifuncional. Si el equipo de desarrollo necesita capacitación adicional para ser lo suficientemente multifuncional, debe tener la educación y la capacitación necesarias. Esto podría ser programación en pareja, sesiones de capacitación entre equipos, almuerzos y aprendizaje, cursos de capacitación externos, traer instructores. La carga recae en las personas para comprender qué habilidades necesitan desarrollar y trabajar con la gerencia para desarrollar esas habilidades. La gerencia también debería estar haciendo lo mismo: identificar las brechas en las habilidades, proporcionar los recursos necesarios para cerrar esas brechas y alentar al personal a hacerlo.

Si tiene un empleado que no se está desempeñando de acuerdo con las necesidades de la empresa, se trata de un problema de gestión de recursos humanos. No se aborda en el marco Scrum.

Así que es difícil saber qué está pasando exactamente. [...]

¿Cómo puedo mejorar la productividad del revelador más lento?

Primero, revisa tus expectativas. ¿Se supone que deben hacer el mismo trabajo? ¿Tienen el mismo título, les pagan lo mismo? ¿Es uno realmente lento en una escala absoluta, o el otro es realmente bueno?

Si tuviera solo dos de los lentos, ¿los conservaría? Si no, ¿qué harías en su lugar y por qué no lo haces ahora con solo uno?

Con esas preguntas respondidas por ti mismo, es poco lo que puedes hacer desde afuera. Pregúntale a tu desarrollador qué problemas tiene. Pregúntale si necesita algo. Ayuda, capacitación, mejores herramientas, tal vez otro horario de trabajo. Trabaja con él para que se mejore. Si no lo hace, debe continuar con las acciones de acuerdo con las respuestas que se le ocurrieron antes.

Todo esto no es un proceso Scrum. Es una gestión normal. Scrum solo funciona con equipos y tu equipo está teniendo problemas. Está formado por muy pocos miembros, mide cosas que no deberían medirse (la velocidad individual no existe) y parece que el 50 % de tu equipo está descontento con el trabajo del otro 50 %. Si desea mantener esto "ágil", debe incluir las preguntas sobre cómo ayudar a su desarrollador más lento a trabajar de manera más efectiva en su reunión retrospectiva.

'el otro desarrollador debería hacer esto, se le delegó originalmente'

Scrum funciona mejor como un modelo pull, no como un modelo push. Ningún trabajo debe ser delegado a nadie, nunca. El equipo pone trabajo en el Sprint. Los miembros del equipo sacan el trabajo del Sprint a sus vueltas. Siguiendo ese modelo, su desarrollador principal no se quejará de que "no debería tener que hacer esto" porque el trabajo no es propiedad hasta que realmente se inicia .

En ese momento, el único problema se convierte en la velocidad individual, que es una preocupación que debe manejarse dentro del propio equipo.

El desarrollador rápido me ha dicho que el desarrollador lento a veces está inactivo y trabaja a borbotones.

No hay nada de malo en esto. De hecho, sería increíblemente preocupante si un desarrollador no estuviera a veces inactivo. Si siempre vas a toda velocidad sin parar, te vas a quemar mucho. Asimismo, trabajar a rachas es una preferencia personal; no hay nada inherentemente malo en ello.

Ha dicho 'ok', pero luego dice 'oh, no me di cuenta de que el trabajo era tan complejo'.

Suponiendo que el desarrollador está hablando en serio y no solo tratando de desviar la culpa (lo que plantearía problemas completamente nuevos, como por qué las personas están más preocupadas por culpar que por solucionar los problemas en primer lugar), entonces este es un problema que puede y debe ser dirigido. Potencialmente en una retrospectiva. Si las tareas se subestiman debido a su complejidad invisible, entonces una posible solución es dedicar más tiempo a analizar las tareas durante la reunión de planificación (o planificación previa, si su organización tiene una).

¿Cómo puedo mejorar la productividad del revelador más lento?

¿Has probado a preguntarle esto? ¿O mejor aún, al Equipo en general? "¿Alguno de ustedes puede pensar en maneras en las que podemos mejorar su productividad?" Si no obtiene nada, pregunte con ejemplos. "¿Programación en pareja? ¿Entrenamiento? ¿Nuevas herramientas? ¿Cafeína?"

Se acepta comúnmente que existe una variación masiva en la productividad entre los desarrolladores muy buenos y los promedio. Lea Michael Lopp Manejando humanos para una buena explicación.

Hay dos problemas:

En primer lugar, el más lento de los dos vale el dinero que la empresa les está pagando. Si es así, mantenlos en marcha. Haz lo que puedas para entrenarlos y alentar su desarrollo para mejorar. De lo contrario, debe lidiar con el hecho de que no pueden hacer de manera competente y productiva el trabajo para el que fueron contratados.

En segundo lugar , y más importante, asegúrese de que su desarrollador más productivo sea reconocido y recompensado por su capacidad adicional. Si se sienten resentidos porque su compañero de equipo gana lo mismo y no es tan productivo ni trabaja tan duro, corre el riesgo de que se sienta resentido y pierda un buen desarrollador (a otro empleador como yo que cuidará de ellos :).

Todos los mejores desarrolladores están acostumbrados a trabajar con otros que no trabajan tan eficazmente como ellos. No es un problema mientras sea reconocido y recompensado.

Desarrolladores rápidos vs lentos, pregunta difícil. Rápido no significa bueno, las soluciones quickAndDirtyTM siempre le morderán la espalda más adelante. Las soluciones más lentas pueden valer mucho más si son fáciles de leer y mantener. Relajarse para pensar también podría no ser tan malo, la mayoría de los desarrolladores solo codifican el 10% de su tiempo. El resto están leyendo y pensando.

Medir la productividad de un desarrollador individual es difícil, pero tenga cuidado con los programadores que producen negativos netos.

"Hay programadores de producción negativa neta (NNPP) en casi todos los proyectos, que insertan suficiente deterioro para exceder el valor de su producción. Por lo tanto, es importante hacer una declaración audaz: sacar a un trabajador de bajo rendimiento del equipo a menudo puede ser más productivo que agregar uno bueno".

http://c2.com/cgi/wikix?NetNegativeProducingProgrammer

Puede ser duro, pero he visto que eliminar el programador lento puede acelerar significativamente el equipo.

Aún así, intentaría ver si el equipo puede llevar a sus miembros al mismo nivel.

• Programación en pares para aumentar la base de código y el conocimiento de la técnica de programación
• Retrospectivas específicas para descubrir problemas que están frenando a algunos desarrolladores. Permítales intentar encontrar soluciones.

Cuando el desarrollador lento se atrasa en su sprint, el desarrollador rápido hace parte del trabajo restante.

Así es como se supone que debe funcionar el equipo Scrum. No trabaja en sus cosas , su único objetivo es producir incrementos de software potencialmente entregables al final de Sprint.

Al desarrollador rápido no le importa hacer el trabajo, pero ha hecho comentarios como 'el otro desarrollador debería hacer esto, se le delegó originalmente'.

Esta declaración se contradice a sí misma, no le importa pero se queja.

Me preocupa que mi desarrollador lento pueda estar deslizándose, sabiendo que el desarrollador rápido tomará un poco de la holgura para que podamos alcanzar el objetivo del sprint. Le mencioné al desarrollador lento que debemos trabajar para aumentar su velocidad durante el sprint. Ha dicho 'ok', pero luego dice 'oh, no me di cuenta de que el trabajo era tan complejo'. Así que es difícil saber qué está pasando exactamente. El desarrollador rápido me ha dicho que el desarrollador lento a veces está inactivo y trabaja a borbotones.

Esto muestra una falta fundamental de confianza entre usted y ambos miembros del equipo. No quiero defender al tipo lento, pero así son las cosas en el software: las estimaciones generalmente no se cumplen y es demasiado complejo predecir con precisión.

Habiendo dicho eso... es posible que se encuentre en una situación en la que realmente tenga un desempeño más lento o deficiente en el equipo y Scrum y las iteraciones no tengan nada que ver con eso.

Mejoremos la productividad de los desarrolladores

¿Cómo puedo mejorar la productividad del revelador más lento?

No sabes por qué es "más lento" . La pregunta que está haciendo se puede comparar con "¿cómo puedo curar los estornudos?" sin preguntar qué lo causó .

Su desarrollador "lento" podría estar: - desmotivado en su rol/proyecto/equipo

• falta de habilidades de tecnologías específicas

• tener algunos problemas personales (enfermedad/problemas en casa/etc)

• no ser el adecuado para ser desarrollador (sí, sucede)

En la parte superior de mi cabeza puedo pensar en un par de razones más posibles.

Solución a su problema de rendimiento inmediato

Intenta abordarlo desde dos vías. En primer lugar, hable con él y pregúntele abiertamente si está bien, ya que notó que parece estar atrasado con el trabajo y no quiere adivinar cuál es la razón.

En segundo lugar, si eres su gerente, sería bueno saber cuál es su historial en la empresa. Cómo fue contratado, cómo terminó con su equipo, cuál es su experiencia profesional. Hay empresas que son muy inconsistentes en las prácticas de contratación y simplemente contratan a personas que no están calificadas para ser programadores, que son administradas por personas que no tienen calificaciones para ser gerentes. Cuando sepa más (o nos dé más detalles), puede comenzar a pensar en mejorar el desempeño de alguien.

tienes que aprender mucho

Mirando su publicación, parece que es un gerente principiante con una comprensión muy básica de Scrum y que se pierde todos los valores fundamentales detrás de él (por ejemplo, "Estoy administrando la velocidad de los equipos"). No pretendo que sea un insulto, sino una evaluación del conocimiento y una oportunidad para aprender. Si estás dispuesto a aprender, el cielo es el límite.

Recomendaría leer Peopleware para comprender lo que significa ser gerente de un equipo de software. Luego sígalo con un par de artículos de Joel Spolsky (comience con TOP10 en la parte inferior) y luego puede seguirlo con un libro con aplicaciones de la vida real de Scrum explicadas como: Gestión ágil de proyectos con Scrum . Después de eso, mire Management 3.0 y comprenda la gestión moderna.

Debes aceptar que el desarrollador más lento puede que nunca alcance el ritmo del más rápido.

No especifica los antecedentes del desarrollador en la publicación, y solo puedo suponer que el más rápido tiene más experiencia y / o ha estado más tiempo en el proyecto. En ambos casos, el tipo "más rápido" probablemente siempre será más rápido.

Todavía reconozco este problema, y ​​creo que debería continuar con las siguientes recetas:

1) De su publicación, tengo la sensación de que las tareas se asignan a los desarrolladores al comienzo del sprint. En la mayoría de los casos, esta es una mala práctica: intente tener una lista de tareas para realizar en equipo en el sprint, no listas individuales.

2) Cuando deja de asignar tareas al comienzo del sprint, será mucho más natural para los desarrolladores comenzar a implementar tareas juntos (también conocido como programación en pareja).

La programación en pareja puede parecerle aterrador; después de todo, ha contratado a dos desarrolladores para poder producir el doble del valor y, de repente, comienzan a trabajar en una tarea a la vez. Sin embargo, trabajar juntos en una tarea a la vez realmente mejorará su velocidad:

• la comunicación hecha en pareja la programación puede hacerla más rápida
• hace cumplir un mejor enfoque
• Es una gran oportunidad para que el desarrollador más lento aprenda, haciéndolo más rápido al implementar algunas de las tareas solo.

3) Tener retrospectivas después de cada sprint, si aún no lo haces. "Pensé que sería más fácil", "No me di cuenta de que era tan complejo": las reacciones se pueden expresar en retro, y la razón se puede expresar, y la situación se puede mejorar.

Diablos, esta situación puede incluso ser el resultado de que su desarrollador más rápido escriba un código tan difícil de leer/malo, que es difícil de trabajar para otros desarrolladores. Este tipo de situación es muy difícil de reconocer desde el exterior, ya que el desarrollador más lento puede no sentirse cómodo para mencionar el problema. Retros y una comunicación más efectiva es la forma de resolver estas cosas.

Etiquetó esto con #scrum y #agility, así que dirigiré las respuestas hacia esas dos cosas.

Este no es un problema de procesos o herramientas, es un problema de individuos e interacciones. Mire lo que funciona para motivar a las personas. Sugeriría leer "Drive" como un resumen básico de la ciencia motivacional básica durante el último medio siglo. He aquí un resumen rápido:

Conduce por Dan Pink

Como gerente, concéntrese en los impedimentos ambientales, incentivos, normas culturales, etc. que desmotivan. Encontré este modelo útil al explorar los impedimentos para la motivación, la efectividad en los equipos Scrum, etc.

La agilidad nos enseña que las personas y sus interacciones suelen ser más valiosas que los procesos y las herramientas. Un corolario es que un problema con un individuo o sus interacciones no se resolverá de manera efectiva con procesos o herramientas... solo se mitigará.

Por último, trabaje para crear un sistema en el que esta persona pueda autoseleccionarse fuera del equipo o fuera de la empresa si las cosas están realmente tan mal. Alternativamente, podría construir un sistema que fomente y permita una cultura y resultados de alto rendimiento del equipo Scrum y le dé a ese equipo un recurso para su propia membresía. Aumente la confianza tratando a estos miembros con respeto y exija un comportamiento responsable. Dedícate a practicar Scrum o algún otro medio para establecer la transparencia, la inspección y la adaptación como práctica normativa. La transparencia expondrá los problemas, la inspección determinará las causas fundamentales y la adaptación producirá un cambio positivo. Por supuesto, esto puede implicar la mejora personal de este individuo o su éxodo del equipo u organización.