Dentro de mi curso de Gerencia de proyectos informáticos el cual dicto en la Universidad Eafit - www.eafit.edu.co para el pregrado de ingeniería de sistemas, tengo la costumbre de poner a escribir a los estudiantes un artículo sobre un listado de posibles temas que les proporciono que tienen que ver con gerencia de proyectos y /o agilismo.
A continuación les comparto el artículo escrito por Miguel Baquero, el cual es una buena aproximación a una métrica que debe llevar el equipo y que debe ser revisada cada retrospectiva, LA METRICA DE LA FELICIDAD.
---
link al documento original - Clic aquí
La métrica de la felicidad.
Gestión de proyectos informáticos.
Miguel Baquero
mbaquer6@eafit.edu.co
Departamento de Ingeniería de Sistemas
Universidad Eafit
Medellín, Colombia
Gerentes y consultores piensan que la gente está harta de trabajar infeliz. La gente más joven en particular se resiste a trabajar bajo el esquema de mando y control, ambientes basados en culpa y castigo. Un cambio importante está sucediendo. Harvard Business Review dedicó todo un número a la Felicidad porque empleados felices conllevan a clientes felices y mejores negocios. Sin embargo, nunca se debe subestimar la capacidad humana de cometer errores. Puede pasar que el equipo sea muy complaciente, tenga exceso de confianza o no vea oportunidades para mejorar. El patrón “un peldaño a la vez”, recomienda enfocarse en un punto a mejorar, de manera que sea claro su impacto. Sin embargo, existen muchas oportunidades para mejorar y es necesario tener una forma de trabajar en las cosas que den los mayores beneficios.
A menudo se genera una larga lista de cosas que se supone ayudan a mejorar la velocidad. Al ser muchos ítems, es posible que se trabaje en algo que no logre mejorar la velocidad, y sí lo hace, no presenta una mejora importante. La gente comúnmente no se siente identificada con largas listas, por lo que no están suficientemente motivados para que funcionen. Es necesario trabajar en la mejora adecuada de manera que el equipo sienta pasión. La gente siente gran satisfacción al hacer bien su trabajo, además tienen un gran sentido de responsabilidad por su trabajo, particularmente si se encuentran en un equipo autónomo. Por esto, hay que encontrar qué mejora va a incrementar en la mayor medida posible la felicidad del equipo, e implementarlo para el siguiente Sprint.
Existen varias maneras de medir la felicidad del equipo, pero se ha encontrado que una forma simple y subjetiva de un puntaje de uno a cinco es suficiente. La mejora deseada debe ser parte de la meta del Sprint, por lo que este patrón además, puede ayudar a formular esta meta.
Hay cierta vulnerabilidad en la expresión de estos deseos. Algunas personas podrían sentirse incómodas haciéndolo públicamente. En este caso, podrían expresarlo anónimamente. Sin embargo, esto no es lo ideal; es mucho mejor reforzar una “comunidad de confianza”, donde las personas se sientan bien expresando sus deseos.
Enfocarse en la felicidad del equipo tiene una extraña habilidad de descubrir qué problemas evitan que el equipo sea más efectivo, no solo más feliz. Probablemente se deba a que las personas obtienen gran satisfacción al hacer un buen trabajo. Además, a menudo están en una posición que permite entender qué pueden hacerlos más efectivos y que cosas se interponen en su camino. Otra razón para que la Métrica de la Felicidad permita un mejor desempeño del equipo, es que la gente siente una mayor conexión personal y compromiso a mejorar.
La Métrica de la Felicidad puede ayudar a prevenir el agotamiento. El agotamiento ocurre cuando la gente trabaja por largas horas o gastan mucha energía mental durante mucho tiempo sin descanso. El agotamiento puede destruir la productividad (“Every hour of overtime is offset by an hour of undertime” – Tom DeMarco) o también provocar la deserción de la gente a un ambiente más sano. Sí el agotamiento es una amenaza, alguien probablemente va a proponer como Métrica de la Felicidad, “detener las horas de trabajo no sanas”.
La gente puede tener distintas percepciones de la felicidad, por lo que es importante no dejar a una sola persona encargarse de la Métrica de la Felicidad; es una decisión del equipo qué es lo mejor para ellos. Al mismo tiempo, cada persona debe ser escuchada, haciéndolos parte de la decisión final. Algunas personas (como gerentes con mucho tiempo en el oficio), temen que el equipo “engañe” este sistema, decidiendo que la felicidad puede ser mejorada tomando los viernes libres, por ejemplo. Esto podría ser posible, sin embargo, como todos los aspectos de la anatomía del equipo, se debe confiar que el equipo siga el espíritu del juego. (Si no se confía en el
equipo, esto viola el espíritu del juego, por lo que se tiene problemas más serios). Así como todas las mejoras, la Métrica de la Felicidad debe ser medible, de manera que indique que realmente se han producido mejoras.
Un ejemplo: Un equipo usa la Métrica de la Felicidad de forma que puedan identificar y priorizar las mejoras. En una escala de 1 a 5 se les pregunta cómo se sienten con su rol en la compañía y como se sienten acerca de la compañía. Luego comparten qué los haría sentir mejor y el equipo utiliza planning poker para estimar el peso de las cosas que los miembros del equipo consideran importantes para esto. El equipo estima el valor (opuesto al esfuerzo) de los ítems del backlog. El equipo estimó 50 puntos. “Mejores historias de usuario” fue la mejora más importante que consideró el equipo. Remover este impedimento tuvo más de 60 puntos. El product owner se preguntó si remover este impedimento podría doblar la velocidad al obtener un mayor puntaje que todo el product backlog para el Sprint. “Mejores historias de usuario” se agregó al Product Backlog para el siguiente Sprint y una nueva Definición de Done. Esta Definición de Done fue implementada como criterios de aceptación que tenía métricas que fueron calculadas en el siguiente Spring review. Estas incluyeron:
- Cuantas historias de usuario estuvieron en el Sprint que no alcanzaron el criterio INVEST (immediately actionable, negotiable, valuable, estimable, sized to fit, and testable) este debe ser 0.
- ¿Cuántas veces los desarrolladores tuvieron que acudir al product owner para clarificar una historia durante el sprint?
- ¿Cuántas veces las dependencias forzaron una historia a estar en estado de espera durante un Sprint?
- ¿Cuántas historias tuvieron una eficiencia de más del 50% en el proceso?
- ¿Cuántas historias no fueron claras para los desarrolladores? Medir por el número de miembros que se quejaron de la historia
- ¿Cuántas historias implicaron mayor implementación técnica que la aclaración de la experiencia de usuario deseada?
- ¿De cuántas historias de usuario los desarrolladores entendieron la relación entre una historia, el tópico que produjo la historia y las necesidades del negocio que la generaron? Medida por el número de miembros del equipo que tienen quejas que no entienden qué estaban haciendo durante la historia.
Los resultados: Mientras que la mejora a la calidad de las historias de usuario nunca termina, el sprint review mostró la mejora significativa en este ítem del Backlog medido por los criterios de aceptación. Mejoras significativas resultaron en un incremento de la velocidad después de varios sprints. Después de doblar la velocidad, el impedimento cayó del encabezado de la lista y fue reemplazado por otro impedimento. Un equipo feliz es un equipo mucho más productivo.
------------
link al documento original - Clic aquí
Referencias:
Sutherland, Jeff. SCRUM LOG JEFF SUTHERLAND. 2012 . En: http://scrum.jeffsutherland.com/2010/1 1/happiness-metric-wave-of- future.html (consultado en noviembre de 2013).
Harrison Neil B, Sutherland Jeff. PROCESS IMPROVEMENT. 2013. En: https://sites.google.com/a/scrumplop.o rg/published-patterns/retrospective- pattern-language/happiness-metric (consultado en noviembre de 2013).
Schwartz, Tony. Happiness is overrated. 2010. En: http://blogs.hbr.org/2010/10/happiness -is-overrated/ (consultado en noviembre de 2013).------------
link al documento original - Clic aquí