Tenemos un equipo SCRUM "típico" y nos comprometemos a trabajar para un sprint, y también a mantener una cartera de pedidos. Recientemente nos hemos topado con el problema de intentar integrar / manejar el trabajo de un desarrollador que supera el rendimiento y que está trabajando fuera de banda (eligiendo trabajar fuera de las horas normales de trabajo / sprint).

Para dar un ejemplo, si el equipo toma 50 puntos de trabajo, digamos que completarán todo ese trabajo dentro del marco SCRUM al final del sprint y ellos y la compañía estarán contentos. Uno de los miembros del equipo decide trabajar por su cuenta, en un elemento atrasado, en su propio tiempo libre. No verifican este trabajo, sino que lo guardan (usamos TFS y está en una estantería).

¿Cómo manejar esto? Algunos de los problemas ...

• Durante el próximo sprint, los miembros de este equipo dicen que el trabajo de programación está hecho al 99% y solo necesita revisión y prueba del código. ¿Cómo lidias con esto en la metodología SCRUM y ágil?
• Otros desarrolladores se quejan de no estar involucrados en las decisiones de diseño relacionadas con estas historias, ya que el trabajo se realizó fuera de banda.
• El propietario de nuestro producto está tentado a realizar este trabajo "gratuito" y los miembros que logran más resultados probablemente lo hagan a propósito para obtener más funciones en el producto que el equipo no podría lograr en el (los) sprint (s). Existe la opinión de que esto está rompiendo el "proceso". Obviamente, el trabajo de control de calidad, IU y documentación aún debe realizarse en este trabajo.

Veo mucha discusión sobre no obligar a un equipo SCRUM a trabajar horas extras, pero ¿qué pasa con un miembro del equipo que trabaja por encima y más allá de las expectativas planteadas durante la planificación y ejecución de los sprints? Dudaría en reinar a esta persona y decirle que no puede trabajar más (advirtiendo sobre el agotamiento, por supuesto), pero al mismo tiempo parece estar causando algunos problemas con ciertos miembros del equipo (pero no todos).

¿Cómo integrar el trabajo realizado por un miembro sobresaliente en SCRUM y el proceso ágil para el desarrollo de software?

Muy bien, entonces alguien está escribiendo con entusiasmo un gran código que debe hacerse, pero no en orden. Con el debido énfasis:

DÉJALOS

Está causando algunas complicaciones en tus carreras de scrum. ¿Realmente importa en el gran esquema de las cosas? Si está logrando lo que se supone que debe hacer, entonces déjelo seguir y construir grandes cosas para usted.

Conozco a varios programadores increíbles que han dejado las empresas porque no dejaron a los programadores fuera de las limitaciones de un sistema artificial como Scrum (yo mismo dejé mi último trabajo después de ser tratado como nada más que un QA glorificado). Si hay quejas de otros desarrolladores sobre la entrada (quejas perfectamente válidas, puedo agregar), puede ser mejor introducir un programa de "20% de tiempo" para que él (y otros) hagan lo que hacen mejor con una mínima interferencia.

En lugar de historias futuras (que pueden requerir el aporte de otros), deje que el desarrollador experimente con nuevas tecnologías o características. Es posible que encuentre una gran oportunidad nueva que nunca se habría explorado de otra manera. Estoy seguro de que este desarrollador tiene algunas cosas que les gustaría probar si las dejas.

Hay dos cosas que creo que deberías considerar aquí:

1. No obstaculice el flujo creativo de alguien.
   • Si un desarrollador quiere hacer un trabajo fuera de horario, déjelo.
2. No cree trabajo para otros.
   • Si un desarrollador quiere hacer un trabajo fuera de horario, es mejor no crear más trabajo para otros .

El punto 2 es probablemente lo que preocupa a los otros desarrolladores.

Como mencionó, no les gusta el hecho de que el código se escriba sin la aportación de todo el equipo. Esto puede deberse a que, en términos de diseño, termina siendo inferior. Y el código con un diseño inferior tiene una forma de infectar otro código a su alrededor.

¿Entonces que puedes hacer?

Deje el ambicioso código de desarrollo a su gusto, pero deje en claro que no hay razón para suponer que se utilizará su código extracurricular .

Después de todo, él es parte de un equipo, por lo que el equipo debe participar en cómo se desarrolla todo el código.

Sin embargo, si su trabajo es sólido y encaja con el diseño acordado por el equipo, entonces podrá usar gran parte de lo que ya ha escrito (¡bonificación!). De lo contrario, lo obligará a pensar más en su diseño la próxima vez que decida adelantarse.

De esta manera, a nadie se le dice que NO , y nadie tiene trabajo extra creado para ellos.

Devuélvelo al equipo

Debería preguntarse a sí mismo (o mejor al equipo, incluido el mayor rendimiento):

¿Por qué es este comportamiento un problema?

Dado que etiquetas al desarrollador como un sobreproductor, supongo que su trabajo es de buena calidad, así que supondré que esto no es un problema.

Pero parece que hay otros problemas:

• El trabajo extra no se prueba adecuadamente
• no está documentado
• el resto del equipo no lo sabe
• el desarrollador decide lo siguiente a implementar, no el PO
• El desarrollador no recibe ningún comentario de los distintos interesados ​​para incorporar en su trabajo.

El siguiente por qué lo haría es:

¿Por qué lo hace el desarrollador?

• Si al final del sprint no queda suficiente trabajo, debe haber una decisión del equipo (incluido el PO) sobre qué abordar a continuación. ¿Por qué el desarrollador evita esta decisión?

Una vez que haya respondido a estas preguntas, puede comenzar a responder su propia pregunta:

• Si no es un problema, que haga lo suyo. Aunque algunas personas tratan a SCRUM como una religión, no debería ser así.
• Lo más probable es que tenga dos problemas en el equipo: el uno o los problemas causados ​​por el desarrollador no autorizado y los que desencadenan el comportamiento del desarrollador no autorizado. Encuentre una manera de resolver el último y el primero desaparecerá.

Por mucho que me guste la idea de que agregar trabajo gratuito a la mezcla es algo bueno, no es trabajo libre, a menos que ese desarrollador único sea también el probador, y el control de calidad y el tipo de compilación y el diseñador y todo lo demás. Si su trabajo se puede poner en el próximo sprint sin ningún impacto, entonces ... adelante. Pero creo que ese nunca es el caso. Todos los demás, como mínimo, tienen que entender lo que ha hecho y el impacto que tiene en ellos. Tienen que entender que sus cambios están en marcha y, por lo tanto, no duplicar sus esfuerzos: es difícil decirle a alguien que han trabajado duro en una tarea solo para encontrar que el tipo rebelde lo hizo la semana pasada.

Sin embargo, está trabajando en un entorno ágil, y una cosa que sí sé sobre ágil es que está diseñado para trabajar para usted, no en su contra. Por lo tanto, debe cambiar su forma de trabajar para permitir que este tipo de actividad extracurricular suceda. Eso significa obtener el aporte y el acuerdo de todos, no puede hacer esto sin su aceptación. Es vital. Si al equipo no le gusta, el pícaro deja de hacerlo. Final de. No es un hombre haciendo lo que le gusta, no importa cuán bueno sea su trabajo, es un esfuerzo de equipo en todo momento. El equipo es lo primero.

Por lo tanto, debe sentar a todos en la próxima reunión de planificación y discutir esto, todos los miembros del equipo deben decidir permitirlo o cambiar su proceso para administrar mejor este tipo de actividad.

Tal vez obtendrá una solución en la que todos trabajen en sus proyectos favoritos y los traiga a la mesa (puede imaginar el caos en su entrega que causaría :) que resalta el problema con él en primer lugar) o puede ordenar El área donde cada desarrollador tiene automatización para desarrollar cualquier solución que les guste es la 'contribuida' de manera similar a la cantidad de proyectos de código abierto que funcionan, o puede darles a todos un poco de tiempo libre para experimentar (el 20% de tiempo anterior).

¿Este desarrollador escribe pruebas y código limpio / sólido o simplemente está sacando todo lo que puede hacer rápidamente? Personalmente, no permitiría que nadie trabaje fuera de las horas definidas, ya que arruinará sus estimaciones y, como señaló, se producen otros problemas.

Sin embargo, nunca debe ser rígido en su proceso. Scrum es solo un marco de trabajo, por lo que siempre puede ajustar el proceso para incluir el tiempo extra (pero nuevamente es difícil planificar lo que alguien podría hacer).

También puede pedirle que trabaje en otras cosas que no sean el proyecto. Mirando nuevas tecnologías o creando capacitación en cosas que hace de manera diferente. Sin embargo, todo lo que se haga fuera de su horario planificado destruirá sus estimaciones y no dejaría que eso suceda.

Nos enfrentamos con lo mismo también, básicamente cometimos algo así como 20 puntos, pero la semana pasada o incluso a mitad del sprint nos quedamos sin tareas de codificación, sin embargo, debido a las Pruebas y al resto del proceso, no nos arriesgamos a elegir otro PBI, ¿y qué? ¡Los programadores hicieron para investigar el trabajo atrasado y comenzar a desarrollar futuros PBI (en silencio!) e informar al resto del equipo en la planificación de que PBI está listo para la revisión y prueba del código. tal como dijiste

En realidad, generó cierta preocupación por parte de nuestros OP de que parece que somos más capaces, pero no utilizamos completamente el potencial de nuestro equipo, lo cual era en parte cierto, pero sí, tal vez nuestros programadores podrían hacer más, pero nuestros evaluadores no pudieron seguir esa velocidad, por lo que existía el riesgo de fallar el sprint. Después de pensar en este tema, descubrimos que necesitamos cambiar nuestra opinión sobre el scrum y el problema principal es que las personas no quieren correr ese riesgo es porque nos comprometemos con PBI, por lo que el equipo no se sintió bien para correr el riesgo de elegir nuevos PBI en caso de que tengamos programador gratuito.

Simplemente comenzamos a pronosticar los PBI en lugar de comprometernos. El pronóstico básicamente significa que elegimos 25 puntos en la planificación y el inicio del sprint, y cuando el programador se libera a mitad del sprint, porque no hay más tarea de codificación, por lo que elige uno de los futuros PBI y lo coloca en Current Sprint y comienza a trabajar en él, si el PBI puede pasar todo el proceso (prueba, fusión, etc.) dentro del mismo sprint, es un punto de bonificación para el equipo si NO no fallamos el sprint debido a ese PBI y solo llevamos adelante el trabajo restante ( prueba o meging o etc.) al siguiente sprint y re poker para el trabajo restante. Por lo tanto, se puede hacer en dos sprints diferentes en el peor de los casos. Sé que puede sonar a Scrumbut, pero en realidad mejoró la forma en que trabajamos. Solo puedo resumir sus beneficios de la siguiente manera:

• Derrota la fobia de fallar el sprint por correr el riesgo de tomar más PBI
• Hace visible el trabajo extra de sus programadores y equipo
• Aumenta la velocidad de tu equipo

Sin embargo, tal vez para un equipo con menos experiencia, tal vez reduzca el empuje que el compromiso le da al equipo para terminar los PBI

Algunas de las otras respuestas han sugerido que el desarrollador que "supera" es "pícaro" o "viola los principios de Scrum". Esto es incorrecto y debería alentarse a este desarrollador (aunque no debe pedirle a la gente que trabaje en algo específico en este tiempo extra, pero puede hacer sugerencias y ayudar a fomentar ideas).

No hay nada en Scrum que prescriba cómo trabajan las personas y cualquier cosa adicional que hiciera se incorporaría naturalmente a la velocidad del equipo.

Su trabajo debe incluirse en la cartera de productos y estimarse en la próxima reunión de planificación. Si no puede predecir cuál es el esfuerzo restante de inmediato, debe calcular el tiempo del sprint para resolverlo (es decir, un Spike).

Es interesante que describa al desarrollador como "superando", supongo que esto significa que está agregando mucho más valor que los otros miembros del equipo.

Las dificultades que genera el trabajo extra implican que hay algo subóptimo (o tal vez incluso disfuncional) en su equipo.

Si este es el caso, debe preguntarse por qué está logrando tanto más, presumiblemente con solo un poco de esfuerzo adicional.

¿Es posible que permita que el resto del equipo logre más?

He visto la situación en la que los equipos han sido microadministrados, potencialmente sobre historias de usuarios prescriptivas, definición de hecho, que termina siendo sofocante para los desarrolladores. Está haciendo el trabajo que este desarrollador que quiere? Supongo que está tomando buenas decisiones. ¿Trabajar de esta manera en la semana laboral también ayudaría al resto del equipo?

Que ellos también sean maestros

Es genial que tengas un desarrollador estrella con las mejores y más avanzadas habilidades del grupo. Alabaría y felicitaría esto. A menudo, esas personas son el "pegamento" que mantiene unidas a las organizaciones.

Vería el desafío como "cómo acercar a los desarrolladores menos experimentados a la productividad del desarrollador más avanzado".

Una excelente manera de hacerlo es concentrarse en hacer que el desarrollador estrella pase más tiempo enseñando, entrenando y guiando a los miembros del equipo menos experimentados y más lentos. Primero hablaría de esto en un 1 a 1 con el desarrollador estrella para que sepan lo que está haciendo y por qué. De lo contrario, puede verse con recelo como una agenda oculta / mala gestión

Cuando hagas standups, una o dos veces al día, si esta persona se queda sin trabajo y otras siguen haciendo tareas, busca la programación en pareja para que pueda emparejarse con los miembros más jóvenes e impartir su gran conocimiento y experiencia. Asegúrese de hacer la pregunta "¿alguien necesita ayuda? ¿Alguien está buscando un par?"

También puede encontrar algún trabajo 'paralelo' para el mejor desarrollador para cuando no tienen trabajo, como mejorar el conjunto de herramientas que todos usan, ejecutar un grupo de discusión del club de libros técnicos o participar en otros proyectos organizacionales.

Voy a responder una pregunta diferente. Creo que cómo lidiar con esta situación en Scrum realmente no es importante. Scrum es más como una guía de todos modos. Si desea que esto suceda, busque una manera simple de adaptar su proceso, como simplemente suponiendo que el trabajo ya está hecho.

La verdadera pregunta es si quieres que este desarrollador haga lo que está haciendo. Creo que varios aspectos juegan un papel clave en la respuesta a esa pregunta:

1. ¿El programador está haciendo un buen trabajo?
2. ¿Están todos de acuerdo con que él haga su trabajo solo (sea bueno o malo)? ¡Está esquivando el proceso de diseño, después de todo!
3. Son las horas extras pagadas o no.

Todo esto influye en si tiene sentido para su producto que él esté haciendo lo que está haciendo. Nuevamente, incorporar su decisión en el proceso de diseño no es realmente un problema. Solo sé flexible.

Esto viola a un inquilino de Scrum porque el equipo no está decidiendo el trabajo en el sprint. Este es un equipo scrum . El equipo necesita disciplinar a este programador si se va a impartir disciplina.

Otro problema que esto crea es que se atornilla a la velocidad del equipo. El trabajo fuera de banda no cuenta para la velocidad y el agotamiento. Entonces, este trabajo fuera de banda se hace, el equipo promedia 50 puntos en velocidad, pero se hacen más de 50 puntos. El propietario del producto verá esto y exigirá una mayor velocidad en el próximo sprint. Velocidad que podría no ser posible.

El equipo (no el PO o el ScrumMaster) necesita abordar esto con el programador deshonesto.