Aquí está la historia (sin juego de palabras):
Como Scrum Master, le dije al desarrollador que dejara de trabajar en cualquier cosa que el propietario del producto no priorizara, independientemente de si tenía tiempo propio o no.
Le dije al desarrollador que dejara de trabajar en cualquier cosa que no haya sido priorizada por el propietario del producto, independientemente de si tiene tiempo propio o no.
Desde el punto de vista del marco, es probable que este sea el enfoque correcto. Sin duda, es lo que yo recomendaría como declaración de política de la organización. Refuerza los procesos y prácticas de Scrum (por ejemplo, time-boxing) y reduce los riesgos para la organización, el equipo y el propio desarrollador.
Sin embargo, desde un punto de vista psicológico, la respuesta correcta de gestión de equipos es menos clara. La personalidad y los impulsos de una persona, así como sus requisitos individuales para permanecer firmemente comprometidos con un proyecto, deben equilibrarse en términos de los beneficios generales tanto para él como para el proyecto en su conjunto.
Lo que sigue es un examen de algunos de los beneficios y riesgos asociados con permitir el trabajo fuera del horario laboral. Ciertamente no es exhaustivo, pero debería proporcionar un sólido punto de partida para su propio análisis de riesgo/beneficio. Su millaje definitivamente variará.
Hay algunos beneficios potenciales de dejar que el desarrollador trabaje en algo que le apasiona en su tiempo libre. Estos pueden incluir:
Apoyando sus pasiones.
Muchos trabajadores del conocimiento valoran los logros personales, el orgullo por su trabajo y la aprobación de sus compañeros al menos tanto como valoran un cheque de pago. Apoyar estos valores puede ser bueno para la moral individual y del equipo.
Crecimiento personal.
Animar a los desarrolladores a crecer como programadores ampliando su conocimiento de las técnicas de programación para resolver problemas que encuentran interesantes puede conducir a una mejor calidad del código y nuevos conocimientos para el equipo. Hacer esto fuera del horario laboral no le cuesta nada económicamente a la empresa.
Inversión individual.
Es probable que alguien que se sienta lo suficientemente apasionado por un servicio o producto como para trabajar en él en su propio tiempo esté más comprometido que alguien que solo quiere presentarse todos los días y cobrar un cheque de pago.
Calidad del producto.
Las personas apasionadas por su trabajo pueden inspirarse durante sus actividades fuera del horario laboral, ya sea que esas actividades estén o no directamente relacionadas con el proyecto. El proyecto sin duda puede beneficiarse de tal inspiración y (salvo los riesgos que se detallan a continuación) tales contribuciones pueden mejorar el valor general o la calidad del producto del equipo.
En resumen, preocuparse por el trabajo de uno o por un proyecto que consume cerca del 40% de la vida de uno es generalmente Good Thing™. A primera vista, parecería haber pocas razones para desalentar esto, pero las ventajas potenciales deben sopesarse cuidadosamente con las desventajas potenciales para todos los involucrados.
El riesgo para el equipo es que puede alentar a la organización a pensar en las horas no facturables como disponibles para sus estimaciones. Scrum se trata específicamente de establecer un ritmo sostenible dentro de las iteraciones con un límite de tiempo, por lo que el trabajo que ocurre fuera del límite de tiempo sesga las métricas y establece expectativas insostenibles para el equipo.
Además, existe el riesgo de confusión sobre algunos principios ágiles básicos, como:
Si bien es poco probable que sea un problema legal significativo con los contratos de trabajo por contrato unilaterales que la mayoría de los trabajadores de TI firman en estos días, sigue siendo un mal precedente aceptar trabajo privado no remunerado en una base de código comercial que no está bajo un abierto -licencia de origen. Es posible que desee consultar con su departamento legal acerca de esto, pero me parece una mala idea™.
El desarrollador mismo corre algunos riesgos aquí. En particular:
¡Es una situación interesante la que describe allí!
Obviamente, no se le puede negar al desarrollador que busque una solución en su tiempo libre. Sin embargo, tiene que haber una separación clara entre su trabajo de tiempo libre y el proyecto. Si trabaja en el código del proyecto, probando/integrando una solución, la separación ya no es clara. Este es un problema que usted, como Scrum Master, debe evitar.
Experimenté una situación similar no hace mucho: trabajé en un equipo de estudiantes en un proyecto de 1 año. Usamos Scrum. Un colega estaba realmente interesado en encontrar una solución elegante para la lógica de arranque de nuestro programa. A pesar de nuestra "solución de trabajo", dedicó más tiempo a implementar una aún mejor; por interés personal. Resultó ser más complicado de lo que esperaba, pero como ya invirtió mucho tiempo, siguió gastando más y más. Al final, esto redujo efectivamente su tiempo de trabajo, porque después de dedicar mucho tiempo al tema, no trabajaría en otra cosa por tanto tiempo. Tenía la intención de separar las tareas, pero no logró hacerlo, porque en algún lugar de su cabeza trabajando en el proyecto todavía estaba trabajando en el proyecto.
Tanto por el riesgo. El final de la historia es: el desarrollador apareció con una solución muy elegante que nos ahorró mucho trabajo desde ese día. No sé si tanto como gastó, pero, al final, algunos dirán que valió la pena.
Sin embargo, la diferencia entre mi proyecto y el suyo es que nosotros éramos estudiantes, mientras que ustedes son empleados. Puede que esto facilite la separación, pero a mis ojos también la hace más importante. Especialmente si la orden de compra ya le dio tiempo adicional (varias veces) para el problema y no pudo solucionarlo. Si es un caso de esquina para él que no vale la pena más esfuerzo, entonces esta es su decisión. Los desarrolladores tienden a tener una visión diferente de estas cosas, especialmente si su orgullo personal está involucrado. Pero es decisión del PO. El equipo tiene que aceptar eso. Período.
Si quiere encontrar una solución para el error en el marco de código abierto, puede hacerlo en casa, en su propia configuración. No debe trabajar en él desde la empresa, ni usar el código del proyecto. Si se le ocurre una solución y todavía está interesado en integrarla, puede volver a hablar con el PO. Entonces puedes decirle que será mucho y mucho esfuerzo y lo sabes, porque tu desarrollador ya lo probó y funcionó. Si no es demasiado trabajo, estoy bastante seguro de que el PO aceptará el cambio. Después de todo, él quiere un producto robusto.
Espero que esto ayude un poco.
Como Scrum Master, le dije al desarrollador que dejara de trabajar en cualquier cosa que el propietario del producto no priorizara, independientemente de si tenía tiempo propio o no.
Este es un enfoque horrible, y huele a falta de perspicacia en la gestión. Es posible que no deba estar trabajando en ello, pero también es posible que deba hacerlo. En lugar de dictar cómo avanzar, debe abrir un cuadro de diálogo que integre los comentarios de los desarrolladores en los sprints.
Si no haces esto, los mejores desarrolladores se irán. A medida que los desarrolladores que quedan se vuelvan cada vez más hábiles, también se irán, y usted se quedará con una alta rotación, gastos generales de capacitación y desarrolladores mediocres.
Esta es una situación incómoda. Realmente me gustó la respuesta de TL; DR , y estoy completamente de acuerdo con todo lo relacionado con los beneficios: apoyar las pasiones, el crecimiento personal, la inversión individual y la calidad del producto.
Los riesgos para el equipo podrían mitigarse fácilmente al tener una reunión de equipo para discutir el deseo de este miembro del equipo. De esa manera, todos los miembros del equipo tienen la oportunidad de expresar su apoyo o su preocupación al respecto. Si la decisión es ir a por ello, el equipo en su conjunto acepta los riesgos. Si no funciona, esa decisión la dicta el equipo, no usted, lo que posiblemente evite un resentimiento más concentrado.
Además, si la tarea se eliminó de cualquier sprint activo y se colocó en la parte inferior del trabajo pendiente, ¿qué hay de eliminarla del trabajo pendiente o cambiar su tamaño a 0 para no afectar la velocidad? Podría sentar un mal precedente, pero podría ser una forma de impulsar la historia sin afectar la velocidad y la sostenibilidad.
Todd A. Jacobs
Ashok Ramachandran