El problema con las estimaciones no son las estimaciones

Captura de pantalla 2016-06-15 a las 6.35.01 p.m.

“La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto, determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman incertidumbres.” – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)

Hola! Por favor permítame expresar mi opinión con respecto al tema de las estimaciones, y #NoEstimaciones. El problema con las estimaciones no son las estimaciones. Las estimaciones son sólo eso, aproximaciones sobre la magnitud de algo. No son valores determinísticos que buscan exactitud sobre el sujeto de la estimación. Bajo este contexto, no existen “estimaciones equivocadas”.

El problema con las estimaciones (Estimates) -sobre todo en el ámbito del desarrollo de software- es que se usan como fechas de finalización de los proyectos (deadlines), sobre las cuales se asocian costos y se asignan equipos para lograr cumplir un alcance que por naturaleza es variable, en un entorno complejo completamente alterable en función de los cientos de factores que provienen de la misma naturaleza del desarrollo de software y de la naturaleza de lo que queremos construir. Complejidad.

Sin embargo, el proceso de estimación (Estimating) desde mi punto de vista es útil. Y aquí hago una pequeña pausa para resaltar la diferencia entre Estimating (la dinámica de estimación) y Estimates (los valores resultantes de la dinámica de estimación). Quizás tengamos un problema en castellano, ya que ambas tienden a traducirse como lo mismo: “estimación” o “estimaciones”.

Desde mi punto de vista, el proceso de estimación es un ejercicio de entendimiento compartido durante el cual los participantes descubren y discuten aspectos que les permite comprender en mayor medida los desafíos de la construcción de lo que estén estimando. Por ejemplo -muy popular dentro del contexto Scrum-, cuando Usted observa a los equipos en una dinámica de Planning Poker, lo valioso es la discusión que se genera frente a la percepción de la complejidad de la cosa a construir y no por el número en sí mismo. Las estimaciones (estimates) pueden ser útiles o no, más el proceso de estimación es valioso.

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones (Estimates) pueden ser expresadas en la unidad que el equipo acuerde: pueden ser horas, pueden ser puntos de historia o pueden ser bananas. Más adelante veremos cuántas bananas nos comimos en una unidad de tiempo. Son simplemente etiquetas de equipo que nos facilitan el proceso mental de comprender qué significa una banana.

El verdadero problema es enfrentar la necesidad de “predictibilidad”

Imagine que Usted llega a la cola en una oficina de su banco (a veces es necesario ir allí hasta que tengamos una banca totalmente digital). Entonces Usted llega a la cola y puede apreciar que hay varias personas antes que Usted. En ese momento le llama su esposa y le pregunta: “¿En qué tiempo te desocupas? Mira que tenemos que ir a donde mi mamá.”; Usted responde: “Okay amor, en esto momento no puedo hablar porque estoy en el Banco, pero ya te escribo por Whatsapp o algo.”

Cuelga y se dice a así mismo: “Vamos; soy ingeniero, trabajo en proyectos, también sé algo de ágil…esto no debería ser un reto para mí…” y comienza. Recordará sus años de Teoría de Colas y dirá: “Ley de Little!!…claro”. El tiempo promedio de espera en la cola es igual al número promedio de personas en la cola dividido para el tiempo promedio de atención. Ya está! Cuenta: hay 20 personas antes que Usted, toma el tiempo desde que una persona llega a la caja hasta que sale (digamos 3 minutos) y listo, matemática simple: 20 personas + Usted (21 personas) / (1 persona cada 3 minutos) = 63 minutos, aproximadamente.

Pero espere, antes de que escriba a su esposa por la respuesta recuerde algo; el señor Little decía antes: “En un sistema estable el tiempo promedio de espera es….blah, blah.”. Un sistema estable, ¿qué significa? Serían 63 minutos si todas las personas realizarían el mismo tipo de transacción exactamente, y que la persona en la caja se demore exactamente ese tiempo de atención por cada transacción sin cansarse. Además, pasan cosas: “se fue el sistema!” (muy típico al menos en mi país), es el descanso de la persona en la caja, lo reemplaza otra persona que está aprendiendo a usar el sistema, una persona se cuela por la parte de adelante, se va la energía eléctrica, habilitan una nueva caja, etcétera.

En otras palabras: Variabilidad. Variabilidad interna y externa al sistema. Estos y otros posibles cientos de factores que influyen en el comportamiento general del sistema. Con los equipos ágiles es muy similar, la diferencia es que estos factores pueden ser muchos pero en verdad muchos más.

Imagine que el siguiente gráfico representa la Velocidad de un equipo ágil en el tiempo:

Captura de pantalla 2016-06-15 a las 6.14.54 p.m.

Fíjese que en los primeros sprints la distancia entre su mejor velocidad histórica (la línea superior del rango) y su peor velocidad histórica (la línea inferior del rango) es más ancha; y a medida que el equipo corre sprints, esta distancia tiende a estrecharse. Esto es gracias a varios motivos, pero obviemos eso por ahora. Estamos tranquilos allí en la oficina y nos hacen la pregunta típica: ¿y en cuánto tiempo estará la feature X si trabajamos con el Equipo 1? Vale, hagamos el ejercicio de proyección:

Captura de pantalla 2016-06-15 a las 6.23.03 p.m.

En función de su desempeño histórico, podemos deducir un rango de fechas en el que equipo puede entregar la feature: entre la fecha X y Z; y podemos contemplar escenarios: en un mejor escenario la fecha X, en un escenario esperado la fecha Y, y en un escenario pesimista la fecha Z. El rango de fechas será más grande mientras más temprano en el tiempo tome su desempeño para proyectar (más alta es la varianza). Entre más estrecho el rango, la probabilidad de entrega es mejor.

Pero no se olvide, complejidad y variabilidad: ¿este equipo conoce el dominio y las tecnologías de implementación?, ¿ha trabajado antes sobre esto?, te comento que la mitad del equipo se va de vacaciones por esa época, etcétera. Variabilidad externa e interna. No hay ciencia exacta.

Entonces, ¿qué le decimos a la esposa?: “Amor, ve avanzando…allá te veo.” 🙂

¿Quiere ser predecible? Reduzca la variabilidad

Hay que reconocerlo: no se puede ser predecible en contextos complejos y sujetos a variabilidad como el desarrollo de software; entre más complejo el sistema y más elementos que añadan variabilidad menos preciso seremos. Es la realidad.

Si queremos lograr un mejor nivel de predictibilidad debemos trabajar sobre la variabilidad. La variabilidad interna (al alcance del equipo):

  • Reducir el batch size (reduzca el tamaño de los ítems de trabajo o Historias)
  • Revise el tamaño de la cola (ítems en el backlog)
  • Clasifique el trabajo (tipos de ítems de trabajo)
  • Establezca restricciones WIP (en cuántos ítems podemos trabajar en función de nuestra capacidad)
  • Enfocarse en generar flujo
  • Identificar cuellos de botella y supeditar el flujo a las restricciones
  • Equipo cohesionado trabajando junto durante un tiempo, no lo desarme
  • Otros.

La variabilidad externa (más difícil y a veces fuera del alcance del equipo):

  • Evitar distracciones organizacionales
  • Evitar multi-tasking o trabajar en varios proyectos al mismo tiempo
  • Contar con ceremonias de sincronización y alineamiento
  • Mucho feedback con Clientes y Stakeholders, entre otros.

Y nada, las cosas pasan…no se puede contener todo y no sabemos lo que sucederá hasta que pasa.

Con respecto a #NoEstimates

#NoEstimates es una perspectiva -y movimiento- que se enfoca en medir la entrega real de valor, por sobre obtener “medidas” a piori para saber cuánto trabajo se puede realizar y en qué tiempo. Es decir, en lugar de ponernos a obtener estas medidas (estimates), mejor hagamos el trabajo, entreguemos y luego sabremos realmente cuánto hicimos. En este contexto, las estimaciones (estimates) son desperdicio (“waste” desde el punto de vista Lean). De acuerdo, como mencioné: el número en sí mismo no es lo importante; más no así el proceso de estimación. Para #NoEstimates tanto el proceso y el resultados son desperdicio; yo simplemente discrepo con respecto al proceso. El proceso de estimación -independientemente del número obtenido- puede ser valioso para los equipos.

Pensamientos finales

A modo de resumen:

  • Las estimaciones (Estimates) pueden ser útiles, pero es mucho más útil contar con la información histórica de entrega real.
  • El proceso de estimación es un proceso de entendimiento compartido, ayuda a comprender la magnitud del problema, identificar riesgos y llegar a consensos.
  • El problema no son las estimaciones, es problema es enfrentar la necesidad de predictibilidad.
  • Los sistemas complejos poseen variabilidad, a mayor variabilidad peor predictibilidad. Nunca será 100% predecible, abrace la variabilidad.
  • Si desea ser predecible -en la medida de lo que eso signifique- entienda y trabaje con la variabilidad interna y externa.
  • #NoEstimates en un enfoque hacia medir el valor real logrado en lugar de obtener cosas medidas a priori, no podría estar más de acuerdo.
  • Nunca deje esperando a su esposa…o a su suegra 🙂

 

Gracias por leer y por sus comentarios.

Johnny

Referencias

El Levantamiento de los Movimientos “#No”

NoMovements

No sé si soy yo, pero siento que en Latinoamérica existe un creciente interés acerca de algo que yo denomino, los “movimientos #No”: #NoEstimates, #NoBacklogs, #NoManagers; que ya tienen un rato dentro de la jerga agilista (yo me encontré con ellos hace unos años). En realidad pienso que es esto es bueno porque demuestra mayor exploración y, en términos generales, mejor entendimiento del pensamiento Lean; y quizás de una transición de enfoques de desarrollo iterativos incrementales (como Scrum) hacia otros donde se habla flujo de entrega de valor (como el método Kanban). Buenísimo!

Pero -desde mi punto de vista- hay que tener cuidado en no caer en enfoques puristas que pueden alejarnos de los beneficios que estos movimientos pueden brindarnos. Mi opinión a continuación:

#NoEstimates

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones son inútiles, pero el proceso de estimación es valorable. El proceso de estimación es un proceso de conocimiento compartido, muy valioso para los equipos; no por el valor de estimación obtenido, sino por la discusión alrededor. Si las estimaciones y la dinámica aporta valor para su organización y a sus Clientes, úselos; recuerde también que tiene áreas Comerciales, maneja contratos y departamentos legales; estas cosas siguen existiendo en el mundo real. Si las estimaciones no le aportan valor, deséchelas; pero independientemente, revise su contexto y manténgase enfocado en la entrega de valor: hacia el Cliente y hacia la organización.

#NoBacklogs

“No hay nada derrochador sobre el concepto del backlog. Un backlog en sí mismo no es un desperdicio. Lo que importa es cómo las personas lo usan. Los trabajadores creativos necesitan herramientas para almacenar sus ideas y recordar sus opciones. Sólo de trabajadores de manufactura se debería esperar mantener su inventario bajo y sus máquinas limpias.” – Jurgen Appelo, Backlogs Are Not Waste

No a los backlogs estáticos, esos sí son desperdicio. No a backlogs de cientos de requerimientos que se levantan “up-front” y que cuyo valor se pudre en el tiempo. Si su backlog es un inventario entonces es un despercicio. Pero si su backlog está continuamente cambiando gracias al feedback de sus Clientes o del mercado, adaptándose a las necesidades, mutando continuamente para maximizar la entrega de valor, generando discusión y experimentos; esto es aprendizaje, respuesta al cambio. Sí a estos backlogs. Crear software no es igual al trabajo de manufactura.

#NoManagers

“Cuando la cultura de una organización es mala, no sólo es culpa de los managers. El Management de una organización es responsabilidad de todos. Un mejor management significa “enganchar” a la gente, mejorar el sistema entero e incrementar el valor hacia nuestros Clientes.” – Jurgen Appelo, Management 3.0 Workout

Managers no es igual a Management. El management en una organización -bueno o malo- no es sólo responsabilidad de los managers, es responsabilidad de todos. Es un sistema complejo donde se conjugan principios, comportamientos, reglas “no escritas”, sistemas de recompensas, cultura, diseño organizacional y más. Ver a los managers como la causa de todo mal es sólo ver los árboles, no el bosque; no es sistémico. Sí a la descentralización de decisiones y a la autonomía en los equipos, pero esto no es igual a no tener managers.

Un nuevo movimiento #No

Por favor no interprete que trato de decir que estos movimientos son malos. Lo contrario, mi invitación es a explorarlos, comprenderlos y analizar su aplicabilidad en su contexto; si le aporta valor y le funciona, adelante! Al mismo tiempo, le invito también a no establecerse en una postura purista al respecto; lo que le funcionó a Usted para su contexto, puede que no aplique en otro.

Yo me atrevo a proponer un nuevo movimiento: #NoDogmas. Podemos sentarnos a discutir por horas sobre cuáles enfoques son conceptualmente mejores y cuáles no. En realidad no importa, todos pueden estar equivocados y algunos pueden servir para un contexto determinado; sólo se sabrá cuando se aplique; pero independientemente de todo, siento que encerrarse en enfoques puristas no es recomendable para las organizaciones y equipos en los que tratamos de llevar agilidad. Agilidad sobre debates metodológicos.

Como siempre, gracias por leer.

Johnny