Recientemente he estado involucrado en un proyecto ágil (usando scrum) en el que a la gerencia se le ocurrió la idea de que el equipo nominaría a un desarrollador 'MVP', así como un QA 'MVP' al final de cada sprint, votado por el equipo. El MVP obtiene una pequeña recompensa monetaria y almuerzo gratis, así como un trofeo para exhibir en su escritorio. Hasta ahora hemos tenido dos sprints con este sistema de recompensas.
Lo bueno que veo de esto es lo siguiente:
- Se han solucionado más errores (que es lo que la alta dirección quiere ver, un cambio de número en la dirección que desean)
- El MVP de cada 'equipo' es reconocido y recibe un aumento de autoestima (¿o es un aumento de ego?)
He notado algunos de los aspectos que consideraría malos para hacer algo así (al menos desde el punto de vista del desarrollador):
- Hay algunos desarrolladores que están tan preocupados por el número que la calidad de las correcciones de errores se ha reducido. Las correcciones en un área están causando regresiones en otra.
- Hay algunos desarrolladores que están escogiendo errores "más fáciles / más rápidos" para aumentar su número de errores. Podría ser bueno o malo aquí, supongo.
- Los defectos de mayor prioridad (que muchas veces se correlacionan con defectos 'más difíciles / más largos de solucionar') en realidad se vuelven de menor prioridad.
- Los defectos de bloqueo no se abordan de manera oportuna, ya que generalmente tardan más y requieren una mayor coordinación con el control de calidad.
- El aspecto del equipo dentro del equipo de desarrollo se ha perdido. El aspecto del equipo de Dev y QA trabajando juntos como uno tampoco ha mejorado, pero realmente no ha cambiado demasiado desde antes.
- Trabajar más allá de las correcciones de errores, o trabajar hacia ESO número, no es fácilmente reconocible / rastreado.
Creo que cada uno de los "malos" anteriores puede abordarse hasta cierto punto, dependiendo de cómo el equipo maneja cada uno.
Mi pregunta es, entonces, ¿alguien ha logrado con éxito algo como esto, donde reconoces un MVP por sprint? Si es así, ¿qué crees que contribuyó a ese éxito?
fuente
Respuestas:
Agile enfatiza el esfuerzo del equipo , no el esfuerzo de los individuos. Entonces no, este enfoque claramente no es ágil.
En lugar de alentar la colaboración del equipo, esto alienta a los miembros de cada equipo a centrarse en su propio resultado. Incluso puede hacer que los miembros eviten ayudarse entre sí (o peor), lo que a la larga impedirá que el equipo mejore.
Sugiero recompensar al equipo en su conjunto si hicieron un buen trabajo.
fuente
Creo que es un buen ejemplo de aplicación de -bad- gamificación . El problema es que sus programadores potencialmente tenían una motivación intrínseca para resolver problemas y ganar desafíos (encontrar y corregir errores) Y, desde que implementó Scrum, trabajaron como EQUIPO. En otras palabras, potencialmente querían hacer un buen trabajo.
Ahora, al menos para algunos de ellos, esta motivación intrínseca o parte de ella ha sido reemplazada por una motivación extrínseca que consiste en títulos ("MVP de la semana") y recompensas (cantidad monetaria y almuerzo gratis), que a menudo son parte de la mecánica del juego. de un proceso gamificado.
La gamificación se puede aplicar con éxito en el trabajo, pero hay que tener mucho cuidado al aprovechar la motivación intrínseca / extrínseca. La motivación extrínseca debe potenciar la autodeterminación para que la motivación se vuelva intrínseca. Sin embargo, lo que sucedió aquí es lo contrario, los programadores están "jugando el juego" para ganar .
Lo que puede hacer para solucionar esto es pedirle a la administración que cambie un poco las reglas:
Sin embargo, reducir la posibilidad de que aparezcan errores de regresión es otro problema. Podría, por ejemplo, aplicar puntos negativos, pero estoy seguro de que no es una buena idea, ya que sería una forma de castigo. Quizás lo mejor sería comenzar automáticamente un sprint con algunos puntos si no se detectó un error de regresión en la última semana. Si se han detectado errores de regresión, el programador comienza con 0.
Además, en "gamificación" hay "juego". Y el aspecto fundamental de un juego es que juegas / participas voluntariamente. En el contexto del trabajo, la administración puede imponerlo, como es el caso aquí, pero normalmente nadie debería verse obligado a hacerlo.
Para concluir, este MVP no es necesariamente una mala idea, pero el enfoque podría cambiarse un poco para hacer que los negocios (resolver errores importantes) sean lo primero, y enfatizar el trabajo en equipo en lugar de los individuos.
fuente
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.
fuente
Este es un ejemplo clásico de cómo una práctica específica (reconocimiento público como MVP) puede tener un impacto significativo pero indirecto en el comportamiento de su equipo. Esto va más allá de los incentivos, las motivaciones y las recompensas, y en realidad toca ideas en psicología ambiental / conductual y arquitectura de decisiones. Cosas interesantes.
La pregunta es: ¿cómo puede diseñar un proceso para que su equipo simplemente haga las cosas correctas de forma natural, sin tener que establecer políticas rígidas u obligar a las personas a hacer algo?
He escrito sobre el uso de posibilidades (en la tradición del Diseño de las cosas cotidianas de Donald Norman ) para los procesos como un mecanismo para diseñar un proceso que funcione para su equipo. La idea básica es que las prácticas en un proceso influyen directamente en el comportamiento de una persona. Como tal, surgen problemas cuando las posibilidades en su proceso no están totalmente alineadas con los valores de su equipo.
He realizado varios talleres sobre este tema y este tema en particular surge como un ejemplo en grupos de vez en cuando. Aplicar la teoría de las posibilidades al caso que compartió en su pregunta podría verse así ...
Asuma que su equipo valora la consistencia, la previsibilidad y el código de alta calidad.
Tienes una larga lista de comportamientos negativos que has observado y todos parecen provenir del uso de métricas de defectos para elegir un MVP del equipo. Por ejemplo, los compañeros de equipo parecen querer naturalmente elegir y corregir errores al azar, impactando negativamente en sus tres valores. (Supongo que también hubo un problema antes, y esto es lo que llevó a la idea de MVP).
En lugar de tener un solo MVP basado en métricas de defectos, intentaremos cambiar el comportamiento del equipo haciendo algunos cambios pequeños pero significativos.
Y estos son solo algunos ejemplos para demostrar el enfoque y comenzar ...
Lo bueno de este enfoque es que está diseñando activamente los cambios en su proceso y tiene razones justificables para los cambios en el proceso que realiza. Al igual que en el diseño de objetos o UI, incluso puede medir los resultados para comprender si las cosas funcionan o no.
fuente
Uno de los ajustes más fáciles de hacer para garantizar que algo así como un programa MVP funcione es recompensar a los miembros del equipo por ser los más valiosos para el éxito del equipo, no ser el trabajador más duro.
Hemos hecho esto con éxito al reconocer a las personas que ni siquiera trabajaron en errores o características, pero hicieron algo increíble que hizo que todos en el equipo tuvieran un mejor éxito. Por ejemplo, tuvimos un desarrollador que asumió la tarea de asesorar a un grupo de nuevos miembros para que pudieran aprender la arquitectura y cómo trabajamos. Nuestra velocidad aumentó porque teníamos a estos nuevos reclutas capaces de entregar resultados de manera rápida y eficiente, a pesar de que individualmente la velocidad de un desarrollador se redujo porque estaba pasando más tiempo ayudando al resto del equipo.
Recompense el trabajo en equipo, y el equipo notará que lo que importa es el EQUIPO, no su propio éxito personal.
fuente