10 reglas de oro para medir un proyecto en Agile

¿Cómo va el proyecto?

Seguro que escuchaste esta pregunta más de una vez en tu vida, y es que en definitiva, es normal que las personas quieran conocer como va el avance del proyecto y que tiempo te llevará terminar el trabajo. De lo contrario se estaría en un estado de caos, cosa no deseable en una empresa pero que he podido apreciar en varias ocasiones.

“Lo que no se define, no se puede medir, lo que no se mide no se puede mejorar, y lo que no se mejora se degrada siempre.” William Thomson
Han sido muchos los proyectos donde me he visto involucrado y topado con personas que miden y realizan estadísticas por encargo, sin nisiquiera conocer o entender de que se trata. A su vez, muchas veces estas métricas se efectúan sin nisiquiera informar a las personas involucradas de su existencia, lo cual erode la confianza de los individuos y equipos.

office-space

En Agile es parte de las metodologías el emplear el gráfico Burndown, el cual indica  el progreso de las tareas que se están llevando adelante. No obstante, existen otras áreas que deben ser medidas para así obtener un panorama mas claro de las distintas situaciones.

Las 10 reglas de oro para medir un proyecto en Agile
Existen diez reglas que te recomiendo seguir a rajatabla y te ayudarán a que tu proyecto en Agile sea un éxito:

Regla 1: Las personas que hacen el trabajo es la que más sabe de donde se está.
En las metodologías tradicionales es el jefe de proyecto el que de alguna forma trata de inducir el estado del proyecto basado en su experiencia, el que a su vez tiene la visión completa del producto. En Ágile se incorpora un concepto que viene de las técnicas Lean e indica que en todo proyecto es finalmente la gente que hace el trabajo la que realmente conoce donde se está.
Obviamente esto asume que a las personas involucradas se les da poder y visión para comprender y adecuar lo que se está llevando adelante, dejando de lado la miopía de proceso vista en las metodologías tradicionales. Un ejemplo clásico de ésta última es la línea de montaje de Ford, donde cada empleado solamente conocía la tarea a ññevar adelante pero no su repercusión total.

Regla 2: Medir los los resultados siempre con individuos en mente
Cuando se realizan las mediciones, las personas deben comprender los valores y estar de acuerdo con los mismos, de lo contrario, se estará dirigiendo el informe hacia un resultado subjetivo. Los valores deberán ser visibles por todos los integrantes del proyecto de forma abierta.

Regla 3. Libertad de medidas a tomar
Una vez interpretados los valores, se le deberá dar libertad al equipo/s (por ejemplo de desarrollo) a tomar las medidas adecuadas para así poder acercarse a la meta prevista,  pero no forzar estos a seguir decisiones externas.

“Las decisiones externas tratan de cambiar comportamientos mientras que las internas refuerzan el crecimiento del equipo.”

Regla 4. Nunca emplear métricas como método de presión
Las métricas no deben ser utilizadas para forzar a las personas a producir más, sino que deberán ser emplaedas para que sus miembros comprendan mejor la situación y buscar alternativas.

Regla 5. Utilizar métricas convenientes
Las métricas convenientes son aquellas que están balanceadas (veremos ésto más adelante) y pueden ser comprendidas por los diferentes miembros. Esto es lo opuesto a aquellos complejos o que se centran solamente en las partes críticas o problemáticas.

Regla 6. El foco debe ser siempre la meta final
En un partido de football, el objetivo puede ser ganar, pero si observamos solamente a la métrica de goles por jugador, entonces desearemos automáticamente aumentar la misma. Ello dará situaciones tales como jugadores robándole la pelota a sus compañeros para así marcar un gol. Obviamente  incrementaría la métrica pero no el rendimiento real del equipo.

Regla 7. Mantenerlo simple
No necesitas más de 3 o 4 gráficos para analizar el rendimiento real de un equpo, más de esto te llevará a confusiones. No debe ser una herramienta para demostrar lo inteligente que eres, sino que volcar valores simples de una forma fácil de ententer y mantener.

Regla 8. Discusión de las métricas
La empresa debe siempre favorecer de forma proactiva y posisitiva a que sus empleados puedan discutir/criticar las métricas de una forma franca y abierta sin penalización alguna.

Regla 9. Asegurarse que las premisas se encuentran bien planteadas
Crear un informe con premisas falsas dará como resultado valores exáctos pero no reales. Por ejemplo, medir productividad basada en líneas de código escritas por desarrollador (en vez de evaluar la calidad) puede dar como resultado información exácta pero no de utilidad. Mi recomendación es que siempre seas crítico de la meta final y el posible camino a seguir. En definitiva un informe, cualquiera éste sea, debería cumplir con lo que yo llamo PDR:

P – Pronosticar
Ayudar a pronosticar con la mayor certeza posible el futuro cercano, por ejemplo, que se podrá terminar y cuando.

D – Diagnosticar
Ayudarte a encontrar dónde se encuentra el problema y sus posibles soluciones

R – Retroalimentar
Brindar retroalimentación para así mejorar los procesos del equipo, pero nunca transformarse en una crítica negativa o una imposición externa para un cambio de actitud.

Obviamente, mejorar la forma de medir ayuda a comprender las internas del proceso de la fabricación y funcionamiento de un equipo de desarrollo de software, lo que facilitará el tomar mejores decisiones y acercarse así a la meta real.

Regla 10. Llegar a un balance
Si sigues las 9 reglas anteriores, te darás cuenta que no alcanza con medir la productividad del equipo: se deben considerar múltiples factores y que ellos se encuentren plenamente balanceados.
Es así que la tabla a continuación te será de mucha utilidad; ella fué confeccionada por Larry Maccherone y hace posible analizar varias áreas medir y a su vez asegurarse que ninguna áreas se encuentra infra o sobrevalorada a costa de otras.

newArticlePNG

Básicamente el cuadro se focaliza en 4 áreas, las que deberán ser observadas y consideradas con el mismo peso. El cuadro superior izquierdo se centra en medir la velocidad de respuesta desde la concepción hasta su implementación. A su derecha si se están haciendo las cosas bien, y mediante la evaluación de la calidad del producto así como tambien la satisfacción del cliente final. Abajo a la izquirda se indica la predictabilidad, esto es, si se tiene una velocidad constante que permita predecir las tareas y su tiempo.nFinalmente se deberá conocer la satisfacción de los empleados para así saber con certeza si se están haciendo las cosas de una forma que las personas que integran los equipos del proyecto estén de acuerdo con los procesos.

Mi recomendación es que observes si los informes de tu proyecto cumplen las 10 reglas de oro y a su vez prestes atención al balance de las distintas áreas. Recuerda finalmente que es siempre sano buscar diferentes vías de interpretar la misma información, lo que dará como resultado una mayor visión de los procesos.

Por último, he propuesto dos conferencias para Agile Spain 2013 que se celebrará en Octubre en Bilbao, si te interesa alguna de ellas, simplemente haz clic en el vínculo y vota por la misma:

Entendiendo los pilares de Agile 2.0: Lo que aprendimos en los últimos 10 años

8 problemas típicos al intentar implementar Agile en la empresa

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

Descubriendo los problemas de equipos Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Cuándo utilizo Ágil? La respuesta que estabas esperando…

¿Qué hacemos con los recursos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s