Las 5 leyes más comunes en el mundo de la agilidad.
He participado como oyente en muchos eventos de SCRUM, me gusta mucho leer todo lo relacionado a metodologías ágiles, por ello me animé a obtener una certificación: la PMI-ACP (Agile Certified Practitioner). Esta me hizo entender que aún me faltaba mucho por aprender. Como parte del curso y después de haber leído en formato PDF (no me alcanzó para la fotocopia) el libro verde PMI-ACP® EXAM PREP escrito por Mike Griffiths, me topé con algunas leyes que emergen con estos cambios.
A continuación hago una recapitulación sobre las 5 leyes mas comunes(… según mi criterio).
1.- La ley de Goodhart
Esta teoría fue introducida por Charles Goodhart, un economista en Inglaterra, y establece que “cuando una medida se convierte en el objetivo, ya no se puede usar como medida”. La ley de Goodhart se aplicó originalmente a la estabilidad del gasto económico y ahora se usa para señalar el problema de asignar valor a una variable específica que se utilizará como indicador (KPI).
No lo entendiste? Te lo explico con pescados, sí con pescados:
- Si mides a un pescador por la cantidad de pescados, pescará muchos peces pequeños para alcanzar el objetivo.
- Si, en cambio, mides al pescador por el peso del pescado, entonces pescará pocos peces grandes y pesados para alcanzar el objetivo.
Suena lógico, no? Todos aspiramos a llegar a objetivos, que nos feliciten por haber cumplido los objetivos. Sin embargo, el desconocer esta ley puede jugar en nuestra contra.
Te preguntas cómo se da esta ley en Scrum? Pues se dá con la medición de puntos de historia / sprint.
2.- Ley del Instrumento o del Martillo
Recuerdan en sus clases de gestión de personal o psicología sobre la famosa pirámide de Maslow? Ese mismo fué.
Ésta ley se enuncia así:
“Si la única herramienta que tienes es un martillo, tratarás a cualquier cosa como si fuera un clavo”.
Esto si está más claro que la ley anterior, pero de todas maneras te explico:
- Nosotros juzgamos lo que tenemos enfrente con la herramienta que tenemos.
- La ley propone que tratemos el mismo objeto de manera diferente dependiendo de que si tenemos una balanza o una regla en nuestras manos.
Ahora te puedo dar un ejemplo de cómo se da esto en Scrum: Medir a diferentes equipos por la cantidad de puntos que hacen, no podemos decir que un equipo scrum es más productivo que otro porque simplemente hace más puntos de historia en un sprint.
He escuchado de empresas donde manejan equipos ágiles y tradicionales y ambos son medidos por horas de productividad. Otro claro ejemplo de esta ley que atenta contra nuestra labor cotidiana dentro de un proyecto.
3.- Ley de Parkinson
Esta observación fue hecha por Cyril Northcote Parkinson en 1955, famoso historiador británico, la cual enuncia lo siguiente: “el trabajo se expande hasta que se termina el tiempo disponible para su culminación”. Es una de las leyes más conocidas y aplicadas en la administración del tiempo.
¿Qué significa esta afirmación?
- Pues que cuanto más tiempo tienes para realizar una tarea, más tiempo tardas en llevarla a cabo.
- Al asignar la cantidad de tiempo adecuada a una tarea, ganamos más tiempo y la tarea se reducirá en complejidad a su estado natural.
¿Ahora, como se da esto dentro de Scrum?
- En los meetings, aunque muchas tienen una duración predeterminada de 60 minutos, la mayoría de las reuniones se pueden realizar en 15 o 30.
- Cuanto más tiempo transcurra un proyecto, más nuevas ideas / características se incorporarán a él.
- La gente continuará puliendo y mejorando el producto indefinidamente.
- Cuando establecemos los story points usando planning pocker.
Por último, quiero hablar de algo que he oído al 99.9% de directores de proyecto, jefes de proyecto, gerentes de proyecto, e incluso a Scrum Masters. Como los gases tienden a ocupar el 100% del volumen disponible, una tarea asignada a una persona tenderá a ocupar el 100% del tiempo asignado para ella, o incluso más. Por eso, “lo que hay que hacer” es asignar un poco menos de tiempo y así en el mejor de los casos lo tendremos antes, y en el peor lo tendremos a tiempo.
¿Seguramente se te vino a la mente el “Síndrome del Estudiante”? No son iguales. Mientras este es comenzar la tarea hasta el último momento, Parkinson, demora la finalización de la tarea.
4.-Ley de Humphrey
El psicólogo George Humphrey (1889–1966) en 1923, escribió «El Dilema del Ciempiés», un poema corto que le da nombre a un fenómeno psicológico llamado el efecto ciempiés o el síndrome del ciempiés. Sí, sé que me estoy volviendo bastante esotérico en esto, pero creo que es bueno entender de dónde viene esto.
Citaré el poema con el propósito de entenderlo
Un ciempiés paseaba contento
Hasta que un sapo burlón
Le dijo: «Cuéntame, ¿en qué orden mueves las patas?»
Le llenó de dudas hasta tal punto
Que cayó exhausto en el camino
Sin saber cómo correr.
El epónimo de la “Ley de Humphrey” establece que: “ una vez que la ejecución de una tarea es automatizada, el pensamiento consciente sobre la tarea durante su ejecución perjudica su rendimiento”.
Entonces la pregunta sigue siendo, ¿cómo encaja esto sobre la Ley de Humphrey como fue descrita por Jeff Sutherland, co-creador de Scrum y donde se presentó la idea de las 3 Leyes del Desarrollo de Software?
La Ley de Humphrey establece que los usuarios no saben lo que quieren hasta que no vean un software en funcionamiento, es decir que para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después de que los usuarios lo hayan usado.
A menudo escuchamos a los usuarios finales decir “Lo sabré cuando lo vea” (IKIWISI). A medida que los usuarios interactúan con un nuevo sistema de software, adquieren más conocimientos sobre el potencial y la funcionalidad del sistema. La revisión iterativa y el proceso de sugerencias conducen a nuevos descubrimientos impredecibles. Estos nuevos descubrimientos son, para mí, la razón por la cual, en el desarrollo de software, el uso de enfoques tradicionales de gestión de proyectos no es una buena opción, ni tan efectiva como otros enfoques. Los enfoques tradicionales de administración de proyectos asumen incorrectamente que los usuarios saben lo que quieren antes de que se desarrolle el software.
5.- La ley de Little
En 1961, el Dr. John Little propuso esto en relación a la previsibilidad. Más que una ecuación matemática, se puede entender como : “la relación entre la tasa de rendimiento (Throughput), el tiempo de permanencia en el sistema (Lead Time) y el número de elementos en el sistema (WIP-del inglés Work In Progress)”.
Algebraicamente:
L=λW;
WIP (unidades)=Throughput (unidades/tiempo)*Lead time(tiempo)
Para el mundo de la agilidad y sobre todo como métrica (kpi) en un Kanban Board, podemos refactorizar la fórmula así:
Lead Time = WIP/Throughput
¿Estás más confundido? pues te lo explico con user stories y porqué nos debería de importar:
Supongamos que tenemos un promedio de 8 user stories en progreso, una tasa de entrega promedio de 4 user stories por semana y un tiempo de entrega promedio de 2 semanas (sprint). Reemplazando los valores en la fórmula anterior quedaría:
2 semanas = 8 user stories/ (4 user stories por semana)
Ahora, llega nuestro líder técnico y nos dice que deberíamos ser más proactivos y estar trabajando no solamente en nuestras asignaciones sino en otras, así que se doblan las asignaciones, manteniendo la misma tasa de rendimiento:
3 semanas = 12 user stories/ (4 user stories por semana)
OMG! ¿Les parece lógico este resultado? El Lead Time incrementó de 2 a 3 semanas, aunque esto es bueno desde un punto de vista matemático, no es lo que suele suceder.
Si sobrecargas tu trabajo, es poco probable que seas el doble de productivo y lo completes al mismo tiempo; solo tomará el doble de tiempo completar el doble de trabajo, entregando aproximadamente a la misma velocidad que antes.
Tenemos dos maneras para reducir el Lead time, reducimos el WIP (lo más fácil) o elevamos la tasa de rendimiento (más difícil). Se que todos optan por limitar el WIP, pero no olvidemos un pensamiento ágil: “Stop Starting, Start Finishing”.
Para que me puedan creer más, les dejo una herramienta de simulación de tablero Kanban (si les sale advertencia de seguridad, le dan proceder):
La configuración inicial que hice fué:
- WIP => Backlog:5; Analysis:3;Dev:3; QA: 2; Deploy: 2;
- Horas => Analysis:2; Development:3; QA: 5; Deployment:1;
- Team => Analyst:3; Developer:3; Tester: 4; DevOps:2;
Bajo esta configuración, tenemos un Lead Time de 3.1 dias. Ahora si uds comienzan a incrementar cualquier WIP, verán como el Lead Time incrementa… cosa de locos!!!
Bueno hasta aquí es lo que he podido colaborar para el entendimiento de algunas leyes que se dan en este maravilloso mundo ágil. Les dejo mi perfil de LinkedIn para cualquier consulta.
¡Gracias a todos y que la agilidad los acompañe!!!
#leydegoodhart
