Algún tipo de reconocimiento grupal de los esfuerzos de un miembro del equipo puede ser un motivador valioso, pero en este caso parece que está siendo mal aplicado. Usted declara que el MVP se elige por votación, pero hay muchas menciones sobre la cantidad de errores corregidos por sprint. Parece que su tiempo tiene una definición divertida de MVP: supongo que la persona que merece el título de "más valioso" es la persona que agregó más valor al software en ese sprint. Si un miembro del equipo está detectando errores que se pueden solucionar rápidamente, explotándolos lo más rápido posible y causando errores de regresión y otros problemas a su paso, entonces no están agregando valor, están creando más trabajo para quien tenga seguirlos para identificar y solucionar esos problemas.
Mi sugerencia sería tratar de comenzar una discusión adecuada la próxima vez que su equipo tenga uno de estos votos. No lo conviertas en un espectáculo de manos; háblalo primero. Si alguien parece estar ganando votos en función de la gran cantidad de "arreglos" que ha realizado, señale (con tacto) dónde esos arreglos causaron regresiones, y sugiera que tal vez la persona que arregló esas regresiones debería ser nominada para limpiar a otras personas lío. Si alguien pasó todo el sprint esclavizándose por un problema desagradable, señale eso al equipo, destacando el hecho de que, aunque el conteo de arreglos de esta persona es uno, solo han resuelto un problema importante con su software, un problema que fue tan desagradable que nadie más quería tocarlo.
Escoger soluciones fáciles y hacerlas de manera apresurada o al azar no es valioso, por lo que los desarrolladores que simplemente hacen eso probablemente no deberían calificar como candidatos MVP. Cuando seleccione el nuevo MVP, olvide todo sobre el equipo y las personas que lo componen, y mire el software. Elija el cambio más importante en ese software desde la última vez. Me refiero a soltero aquí; "No tantos errores pequeños" no es un cambio importante. ¿Se ha solucionado un error particularmente evidente? ¿Se ha agregado una gran característica nueva? Una vez que haya identificado cuál es este gran cambio, pregunte quién fue el responsable. Una de esas personas es probablemente tu MVP real. Si "no tantos errores pequeños" es la única diferencia, entonces y soloentonces, el conteo de errores es una medida válida de MVP, e incluso entonces, vería la proporción de errores corregidos a los errores de regresión causados. Cada error que alguien causa deduce al menos 1 de su recuento. De hecho, diría más de 1, porque una mala solución causará un error desconocido que luego debe encontrar, que es peor que un error conocido que ya se ha encontrado. Un error conocido requiere esfuerzo del desarrollador para solucionarlo; un error desconocido requiere un esfuerzo de control de calidad para encontrarlo y el esfuerzo del desarrollador para solucionarlo, y luego existe el riesgo de que el control de calidad lo pierda.
En teoría, si los desarrolladores se dan cuenta de que el camino hacia el premio es solucionar menos problemas mayores, buscarán los más difíciles, los complejos y los defectos de bloqueo. Esto requerirá que se unan algunas veces, ya sea porque no hay suficientes problemas carnosos para evitar, o porque el problema es lo suficientemente complicado como para requerir más pares de ojos . Quizás sugiera que en casos como este, el premio podría compartirse si no está claro de inmediato qué grupo de personas trabajó más para solucionar un error, y recuerde, ¡trabajo realizado! = Líneas de código escritas. Los desarrolladores probablemente lo sabrán, pero usted dijo que la administración está involucrada, y la administración no siempre comprende ese punto.
Y oye, si todo lo demás falla, olvida el programa MVP. Hable con sus colegas desarrolladores fuera de los scrums y señale el impacto negativo que los premios MVP están teniendo en el software. Vea si puede lograr que lo ignoren, o no lo conviertan en un gran problema. Deje el trofeo en un cajón, gaste el premio en efectivo en una ronda de bebidas para el equipo después del trabajo, use el almuerzo gratis para obtener algo que pueda compartir, como un montón de pastelitos. Agile es un sistema de equipo; resaltar los riesgos de desempeño individual enfrentando al equipo entre sí. Unidos está de pie, dividido envía software lleno de errores, después de la fecha límite, sobre presupuesto.