El Planning Poker me arruinó por completo

Si llegaste hasta aquí pensando que voy a estigmatizar esta práctica de estimación ágil, aún estás a tiempo de hacer clic en algún otro lugar de tu navegador. Quizás aquí, mi artículo sobre “Estimaciones en los tiempos de la agilidad”, en cuya sección final decía que si sigues estimando como hace algún tiempo seguramente no estás en el camino ágil o te alejaste de este, es más, quizás ni estés haciendo estimaciones propiamente dichas. A lo que seguí con una serie de recomendaciones que terminaban con una enfática pero respetuosa propuesta de simplemente no estimes del todo, enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.

Se trata precisamente de evolucionar, de seguir experimentando y aprendiendo de los resultados de nuestros experimentos. Ya dimos el primer paso y fue dejar de usar técnicas tradicionales que requerían de tener mucha información y de hacer mucho trabajo que, a la postre, se convertía en desperdicio para la organización o que, en general, no era de valor para nadie. El nivel de predictibilidad era muy bajo, tuve la oportunidad de comprobarlo una y otra vez hasta la desesperación durante dos décadas. Luego empezamos a usar técnicas de estimación relativa y juegos como Planning Poker nos enseñaron a hacer mejores predicciones acerca del trabajo sin generar tanto desperdicio de tiempo.

A veces es posible hacer algo sin hacerlo. Una de las formas de estimar es no estimar. Sé que para llegar a eso el camino es cuesta arriba, pero eso muchas veces es bueno, porque cuando lo logras, ves que valió la pena porque la vista es fantástica.*

Así que avancemos un poco por ese camino…

Enfócate en generar Valor, no estimes

Imagen de Nattanan Kanchanaprat en Pixabay

Motiva al Dueño de Producto o a quien sea tu “cliente” a Ordenar por Valor todo lo que quiere. Acompáñalo en el proceso. Haz que se enamore profundamente de esta forma de pensar y de hacer basada en el valor, pero sin que llegue a odiar las formas anteriores. Hay muchas técnicas para ordenar el backlog:

• En función de lo que quieran tus clientes o consumidores
• Lo que los interesados internos quieren
• Lo que creas que impactará más
• La antiquísima MoSCoW
• Por Costo-Beneficio
• RoI (Retorno de la Inversión)
• VIP (el método del servicio preferencial)
• El costo de la demora
• Puedes elaborar una matriz Valor – Complejidad  

Puedes usar una combinación de estos, por ejemplo, entre dos elementos Requeridos (MoSCoW), implementa primero el que menor costo de implementación tenga y mayor beneficio te genere (Costo-Beneficio) o el que mayor retorno de la inversión te genere (RoI); entre dos elementos que te generen el mismo RoI, construye primero el de mayor costo de la demora (CoD) o el que te haya solicitado la persona más importante para tu organización de entre tus interesados. Aunque, ojo, esta persona no siempre es la de mayor rango jerárquico.

Hazlo gradualmente, de manera orgánica. Experimenta.

Imagen tomada de https://pixabay.com/images/id-512503/

Pasa de puntos de historias a tallas de camiseta. Pero no hagas un equivalente entre una talla y un número de puntos. Sería como tratar de saltar en paracaídas con una soga atada al avión, ¡no lo vas a lograr! Si lo que quieres es “medir” la velocidad del equipo, entonces cambia la escala también: ya no serán 30 o 47 puntos, sino seis elementos Talla M u ocho talla S, por ejemplo. Más adelante, busca una forma cada vez menos cuantitativa y más cualitativa de realizar la estimación, que tienda o evolucione siempre hacia el valor del incremento de producto a entregar y se aleje de una vez por todas y para siempre del esfuerzo necesario para hacer el trabajo o de la complejidad inherente a cada elemento del producto.

Evidentemente necesitarás kilometraje ágil. Tú, tu equipo y muy probablemente tu organización ya habrán llegado, al menos, a la cima de la curva de la innovación, en este caso, de cambio de forma de pensar y de hacer las cosas “a lo ágil”. Es decir, una gran mayoría temprana y un sector de la mayoría tardía, ya han entendido de qué se trata, ya han interiorizado, practican y promueven el pensamiento ágil, los valores y principios del Manifiesto Ágil, los pilares de Colabora, Entrega, Reflexiona y Mejora del Corazón de la Agilidad; y ya hay un sistema de valores de poca o ninguna variabilidad y consistente con las prácticas empresariales como base que guía el accionar de todos o de casi todos en la empresa y en su entorno.

Algunos patrones Scrum para estimar

Imagen de Achim Scholty en Pixabay

Usa patrones Scrum como el Gradiente de granularidad. ^(II)

Hemos experimentado y sabemos que los elementos pequeños son más fáciles de estimar, pero desglosar los elementos de trabajo es mucho trabajo en sí mismo. Las estimaciones de trabajo para pequeños incrementos de producto y tareas tienen menos errores que para los más grandes por tres razones:

·    La magnitud del trabajo (y, por lo tanto, del posible error) es menor que para un incremento o tarea más grande.

·    El equipo puede comprender mejor las entregas y tareas más pequeñas que las más grandes.

·    El porcentaje de error en las entregas y tareas más pequeñas es menor que en las grandes porque hay menos elementos de adivinanzas (y el tamaño máximo de cualquier error se mitiga implícitamente).

Por lo tanto:

Divide los primeros PBI en elementos pequeños de medio Sprint o menos de trabajo para una persona (aproximadamente el 10 % del trabajo total del Sprint) cada uno. El equipo debe desglosar los PBI posteriores para que su tamaño sea proporcional a su profundidad en el backlog Producto.

Otro patrón es el del Trabajo fijo. ^(III)

Scrum divide el tiempo en dos. Hay un cronograma continuo para el análisis y el negocio, y un cronograma cíclico de Sprint para la producción. El tiempo para el análisis y la innovación es imposible de estimar y puede desarrollarse durante largos intervalos, porque surge de manera impredecible en un proceso que Steve Johnson llama "la corazonada lenta" en su libro “Where Good Ideas Come From: The Natural History of Innovation”, Capítulo III, “The Slow Hunch”.

Todo el trabajo debe tenerse en cuenta si el Dueño del producto va a utilizar la velocidad del equipo para la planificación del lanzamiento del producto, pero no todo el trabajo de desarrollo puede tener un límite de tiempo.

Así que:

Divide todo el trabajo del Equipo de Desarrollo en aquel cuya duración estiman (es decir, trabajan en el producto) y lo que no pueden estimar (como el trabajo para entender los requisitos a medida que el equipo mueve los PBI a Preparado). En cada Sprint, reserva tiempos periódicos para el trabajo no estimable, fuera del presupuesto del Sprint, y completa la mayor parte de cada tipo de trabajo que permita el bloque de tiempo.

O este otro patrón del Alto valor primero.^(IV)

Que hace alarde del antiguo y conocido refrán “más vale pájaro en mano que un ciento volando”, y hoy por hoy los desarrollos a corto plazo deberían ofrecer valor lo antes posible.

Las cosas así:

Haz que tu equipo desarrolle primero los elementos del Producto de alto valor más esenciales.

Imagen basada en “A Scrum book”. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

También usa patrones como El Clima de Ayer, Equipos que terminan más temprano aceleran más rápido e Illegitimus Non Interruptus no solo para hacer mejores predicciones de lo que planeas entregar sino también para llevar a tu equipo a niveles de desempeño grandiosos y entregar más valor en menos tiempo, quizás el doble del valor en la mitad del tiempo. Para saber más de estos y otros patrones puedes ir a:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

Donde encontrarás sendas presentaciones para descargar y videos para ver sobre el tema.

Para finalizar

Como siempre, permite que las personas comprometidas con el trabajo decidan qué hacer respecto a la estimación. Guíalos. Muéstrales beneficios de uno u otro enfoque, de una u otra práctica. Y también perjuicios. Contrasta con el camino ágil recorrido. No es lo mismo un equipo u organización que apenas están saliendo de los enfoques tradicionales a uno que ya lleva ciertos kilómetros transitados.

Si este último es tu escenario, la próxima vez que quieras estimar algo, estima el valor de lo que vas a entregar, no el esfuerzo que te lleva realizarlo o la complejidad de lo que vas a hacer.

Y aunque no hablé de #NoEstimates, este es un movimiento, una filosofía, una visión de pensar acerca de cómo hacer algo, no es una técnica o metodología. Bueno, quizás estas ideas y propuestas constituyan un aporte a esa tendencia.

Referencias

* Basado en una frase de la película Hannah Montana (2009) que viera con mi hija Pamela, de 12 años entonces: “la vida es cuesta arriba, pero la vista es genial”.

(II) ¶59 Granularity Gradient. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(III) ¶23 Fixed Work. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

(IV) ¶51 High Value First. A Scrum book. James Coplien, Jeff Sutherland & The Scrum Pattern Group.

Imagen de la portada basada en:

• Imagen de Natalia Ovcharenko en Pixabay
• Imagen de Mike Cohn en www.mountaingoatsoftware.com
• Imagen de Agile Poker Estimation Planning Cards by Clearly Agile, Inc.

El clima de ayer, o el arte de prever lo que sucederá hoy

Imagen de truthseeker08 en Pixabay

La velocidad de los equipos es algo que nos preocupa desde siempre, sobre todo para quienes venimos de paradigmas tradicionales y formas convenciones de medir el rendimiento de las personas y de los equipos. ¿Cómo la calculamos? ¿Cuánto tardamos en conocerla? ¿Cómo sabemos si esa es la velocidad real del equipo? Son algunas preguntas que surgen en conversaciones en las organizaciones que empiezan a usar Scrum y la forma ágil de hacer las cosas.

¡La desconfianza impera en el ambiente! Se trata de ese temor a lo desconocido, a perder el control de las cosas, natural por demás en nuestro ADN humano. Pero ya basta.

Hemos aprendido que ya no es tan importante saber cuántos Sprints vamos a tardar para conocer más o menos la velocidad del equipo. Como siempre, empezamos con un estimado, con lo que creemos que el equipo puede lograr cuando inicia “labores” ágiles y vamos afinando. El juicio de un experto viene bien; o un cálculo matemático basado en la capacidad del equipo, o la propia experiencia previa del equipo si este ya viene trabajando como tal.

Para ello, usamos un patrón que llamamos “El clima de ayer”, Yesterday’s Weather en inglés. El clima de ayer es un concepto que heredamos de eXtreme Programming (XP) y que usamos para sortear esa determinación a veces excesiva que tienen los equipos para comprometerse en exceso durante los Sprints y que hemos acogido muy bien en Scrum. Nos recuerda que un buen predictor del futuro es lo que hemos hecho en el pasado reciente.

El nombre proviene del hecho de que la mejor forma de pronosticar el clima de hoy es precisamente el clima de ayer. En la mayoría de los casos, el número de Puntos completados en el último Sprint es el vaticinador más confiable de cuántos Puntos se completarán en el Sprint que comienza.

En síntesis, el clima de ayer es un patrón Scrum que ayuda a los equipos a calcular o a determinar rápidamente cuántos puntos probablemente se terminarán en el Sprint por iniciar. Si hiciste 35 puntos este Sprint, sea cual fuere la escala que estés usando para medir, ¿cuánto es lo más probable que hagas en el nuevo Sprint? ¿49? ¿37? ¿23? ¡Yo creo que 35!

Recomendación: es importante tener cautela y no dejarse llevar por nuestra propia naturaleza humana, esa que nos acusa a las personas y a los equipos con alta autoestima de establecer metas cada vez más altas para sí mismos.

Imagen de StockSnap en Pixabay

Este Sprint hicimos 29, en el nuevo podemos hacer un 10% o un 20% más o más aun, porque hemos aprendido, porque sabemos más, porque somos muy buenos, porque el trabajo en casa rinde más y un sinnúmero de razones por las que siempre intentamos hacer más. Incluso llevamos muchos Sprints sin atinarle a lo prometido y en vez de bajar seguimos subiendo, porque ahora sí, porque la quinta es la vencida, porque ya le “cogimos el tiro al vaina”*, porque ya sabemos cómo es, porque ya nos certificamos en historias de usuario, porque ya leímos el libro de Jorge y Lucho y otro largo etcétera.

¡No hay que caer en eso! Andemos con cuidado por este mar de turbulencias. El clima de ayer es la mejor forma de predecir lo que va a pasar hoy.

Quizás puedes ir hasta tres Sprint más atrás, sí. Hay que experimentar. ¿Pero más de allí? Es que hace 24 Sprints hicimos 54 puntos y desde entonces no subimos de 31, ¡vamos con 55 esta vez! Este año sí. Bueno, no.

Así que mi punto es: ya no se trata de "estabilizar" la velocidad del equipo. La experiencia nos ha demostrado que, aunque posible, estamos en un mundo VICA (VUCA en inglés). Anoche (hoy es 16 de marzo de 2020, en plena crisis mundial por el COVID-19), antes de las 8 de la noche en Perú, ningún equipo Scrum sabía que hoy no iría a trabajar a sus oficinas. ¿Sirve la estabilidad en la velocidad? Creo que no. Toca empezar. Empecemos con el clima de ayer.

Miremos la velocidad que teníamos el viernes y vamos estudiando cómo se dan las cosas para los siguientes Sprints.

Incluso tengamos en cuenta la capacidad del equipo, si sale alguien, si alguien no estará durante algunas horas o días, si alguien se va de vacaciones o se va de luna de miel.

Finalmente, se trata de empirismo, no de prescribir una receta, allí es donde un patrón como este juega un papel importante, ¡aprendamos de la experiencia!

“El conocimiento previo no se puede obtener de fantasmas y espíritus, no se puede obtener por analogía, no se puede descubrir por cálculo. Debe obtenerse de personas, personas que conocen las condiciones del enemigo".

- Sun Tzu, El arte de la guerra

Nota:

* “Coger el tiro a la vaina” en Colombia significa “descubrir o aprender la manera de hacer algo bien”.

Para conocer más sobre el patrón El clima de ayer, pueden ir a:

https://www.scruminc.com/yesterdays-weather/

Estimaciones en los tiempos de la agilidad

Presentación

Hace algunos días, mis amigas Valeria Vásquez y Alejandra García, un par de cómplices caleñas convencidas de esto de generar espacios para compartir conocimiento que nos permita cambiar, me invitaron al cierre de una iniciativa que decidieron liderar desde el día mundial de la Retrospectiva en 2019, la cual consistía en realizar reuniones virtuales abiertas sobre distintos temas seleccionados por la gente. Mi tema era precisamente este de las estimaciones. Aquí les presento algunas conclusiones, no sin antes felicitar en grande a estas dos intrépidas que se han tomado este asunto de ser líderes de una comunidad que sigue expandiéndose y creciendo y que cada día presenta nuevos retos, como lo es Ágiles Colombia.

Ahora sí, vamos a lo que nos ocupa.

Sobre estimaciones bajo el manto ágil

Decíamos en la reunión que una Estimación es un proceso analítico e imparcial para predecir la duración o el costo de un proyecto o desarrollo de producto, de una iniciativa en general. Y hacíamos énfasis en que la estimación es una predicción, no es una planificación, ¡no es un compromiso! Además, “una estimación es buena cuando quienes estimaron consideraron toda la información que tenían a su disposición para el momento y el propósito de la estimación”, o algo así nos contaba mi gran amigo Wilmar Hincapié en una conversación anterior.

Pero ¿qué es eso de “considerar toda la información” disponible? Bien, debemos considerar el entorno VUCA en el que nos movemos hoy día, donde la volatilidad, la incertidumbre, la complejidad y la ambigüedad están a la orden del día, en donde no es posible predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo vamos a entregar y cuánto será su costo. Lo que sí podemos hacer es empezar con planes iniciales, planes cuya elaboración no tome mucho tiempo y sobre los cuales haya certeza de que van a cambiar, quizás tanto como todos los días. Después de todo, la meta es entregar el mejor producto o servicio posible, no la planificación en sí y mucho menos la estimación. Es lo que hemos dado en llamar “filosofía ágil”. Más sobre esto en mi artículo “Cultura ágil: ese oscuro objeto del deseo”.

No estimamos en el universo de lo simple ni de lo complicado, sino en el entorno de lo complejo, de lo caótico y hasta del desorden (Cynefin). Por ello es que no existen las “buenas” técnicas de estimación ágil, aunque tampoco existen las malas, son simplemente técnicas, experimentos que hacemos para tratar de calmar el ansia de todos los interesados en temas como la duración de una iniciativa o en las fechas de entrega de producto.

Debemos deshacernos de una vez por todas y para siempre de las cadenas que nos impuso el triángulo de hierro de los proyectos tradicionales, ese que establecía el éxito de un proyecto si este se encontraba dentro de los límites de tiempo, alcance y costo estimados. En este orden de ideas los invito a que consideren mi enfoque integral de gestión de personas y desarrollo de productos (resultados y restricciones) que expongo en el triángulo ágil extendido.

Técnicas de Estimación

Sobre este asunto de las técnicas o experimentos para estimar también hablamos un poco.

1. Planning Poker

La experiencia nos ha enseñado a usarla cuando tenemos un número relativamente pequeño de elementos a estimar y con un equipo pequeño de personas. Más sobre esta técnica en https://www.mountaingoatsoftware.com/agile/planning-poker.

2. Tallas de camiseta

Esta es una técnica muy buena para estimar un backlog grande de producto. Especialmente cuando tenemos varios equipos concurrentes trabajando en el mismo producto. Es una manera informal y rápida de tener una idea aproximada del esfuerzo requerido para hacer algo. Para saber más sobre la técnica, accede a http://getskillsblogs.com/agile-estimation-with-t-shirt-sizes/.

3. Puntos de votación (dot voting)

Útil cuando nos enfrentamos a un conjunto relativamente pequeño de elementos y necesitamos una técnica súper simple y efectiva para estimar. El método se originó a partir de la toma de decisiones. Funciona bien tanto para equipos pequeños como para grandes, pero tenemos que limitar el número de elementos estimados. Más sobre la técnica en http://www.informit.com/articles/article.aspx?p=2117898&seqNum=3.

4. El sistema del cubo

Mucho más rápido que el planning poker es el sistema de cubos. Este sistema es una buena alternativa al estimar un gran número de elementos con un gran grupo de participantes. Más sobre este curioso método en:

http://www.agileadvice.com/2013/07/30/referenceinformation/agile-estimation-with-the-bucket-system/

5. Grande / Incierto / Pequeño

Un método muy rápido de estimación aproximada es el método Grande / Incierto / Pequeño. Se le pide al equipo que coloque los artículos en una de estas categorías. El primer paso es categorizar los elementos obvios en las dos categorías extremas (Grande y Pequeño). A continuación, el equipo puede discutir los elementos más complejos. Esto es en realidad una simplificación del sistema de cubos. El sistema es especialmente bueno para usar en equipos más pequeños con elementos comparables. Como siempre, podemos asignar tamaños numéricos a estas 3 categorías.

6. Mapeo de afinidad

Funciona mejor con un grupo pequeño de personas y un número relativamente pequeño de elementos. Más información sobre la técnica en:

http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/

7. Método de ordenamiento

Este es un ejercicio donde se obtiene una imagen precisa del tamaño relativo de los elementos. Funciona mejor con un pequeño grupo de expertos. Todos los elementos se ponen en orden aleatorio en una escala que va de “pequeña” a “grande”. A cada participante se le pide que mueva un elemento en la escala. Cada movimiento es solo un punto más bajo o uno más alto en la escala (muy pequeños, pequeños, medianos, grandes, muy grandes), o simplemente el participante cede el turno. Esto continúa hasta que ningún miembro del equipo quiera mover elementos o ceda su turno.

El método funciona mejor con un grupo relativamente pequeño de personas y una gran cantidad de elementos.

Más sobre una “buena” estimación

• Siempre demos un rango, nunca demos un número. Los números son para hechos, los rangos son para estimaciones
• Siempre preguntemos para qué serán usadas nuestras estimaciones. ¿A qué nos hemos comprometido? ¿Basados en qué información?
• La estimación es diferente de un compromiso. Realizar una estimación “errónea” no hace daño.
• Primero tratemos de medir, contar y calcular. Estimemos solo cuando sea necesario.
• Por sobre todas las cosas, ¡nunca negociemos las estimaciones! Siempre preguntemos las razones y los supuestos detrás de las estimaciones.

Juegos de estimación dañinos que debes evitar

La estimación es un juego pero evita los juegos de estimación dañinos:

• ¡Adivina el número que estoy pensando!
• ¡Un equipo increíble como el de ustedes puede hacer mucho más que esto!
• Esta vez será mucho más rápido porque hemos aprendido mucho del proyecto anterior.
• ¡Este proyecto será muy diferente!
• Si trabajamos un poco más duro, aumentaremos la velocidad.
• ¡Puedo programar esto en la mitad del tiempo! O el infame arte de hacer el doble de trabajo en la mitad del tiempo.
• Si bajamos la estimación, el proyecto se hará más rápido (esto realmente funciona en algunos escenarios).

Recomendaciones finales

• Si sigues estimando como hace dos años o más seguramente no eres  ágil, es más, quizás ni estés haciendo estimaciones propiamente dichas.
• Experimenta con muchos tipos de estimación. 
• Estimas trabajo de conocimiento, trabajo creativo, no trabajo predecible y repetitivo.
• Toma la estimación como un juego, un juego serio pero juego al fin y al cabo.
• Usa técnicas de estimación relativa.
• Con cautela, hazle caso a La ley de los grandes números.
• Fija objetivos y resultados clave (OKR), no números fríos.
• No estimes, a nivel de iteraciones, si no conoces la Definición de Terminado ni los criterios de aceptación.
• Cuando se trate de productos o de características de producto, estima en iteraciones o, a lo sumo, en días. Deja las horas para las actividades diarias.
• Estima para un rango que va desde la Mínima Entrega Viable hasta la Entrega Completa. Es decir, asegúrate de que en ese rango de tiempo harás una entrega de valor.
• Evita a los “influenciadores” expertos y, en general, a quienes pueden crear distractores al momento de realizar la estimación.
• Estima valor de negocio, no puntos de historia.
• Experimenta, crea tu propio método de estimación. Por ejemplo, el método 1 – 5 – 9 es una técnica simple que consiste en establecer si el elemento se puede elaborar o no en una iteración junto a otros 5 a 9 elementos. De ser afirmativo, es porque contamos con la suficiente información para desarrollarlo a continuación. Útil para usar durante la planificación de una iteración de menos de un mes de duración.
• ¡O simplemente no estimes del todo! Enfócate en entregar Valor, en reducir el Time to Market, en eliminar desperdicios y en mejorar continuamente.