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.

Planear sprints en horas y no por puntos

Hace algunos días nuestro amigo Carlos Jaramillo nos preguntaba a algunos colegas si estábamos de acuerdo con el legendario Mike Cohn cuando dice que los sprints deberían planearse con horas y no con puntos. Carlos se refirió específicamente al artículo Why Sprints Should Be Planned with Hours, Not Points (Por qué los sprints deberían planearse con horas, no con puntos).

Como lo dice Cohn al inicio de su artículo, para mí y creo que para muchos de los que hemos leído su libro Agile Estimating and planning (Estimación y Planificación Ágil) fue una sorpresa cuando vimos el título ya que sabemos que él es un gran referente y promotor de los puntos de historia y de su uso. Pero pasemos a la que fue mi respuesta entonces:

¡Estoy de acuerdo!

En particular, estoy de acuerdo con Mike cuando dice que “los puntos (de historia) son demasiado imprecisos para ser útiles en el corto plazo”, es decir, en un sprint de menos de un mes. También me gustaría destacar aquello de que la velocidad, aunque ligeramente, puede variar de sprint a sprint.

Además de lo que dice Cohn en su artículo algunas otras razones me llevan a pensar así:

No hay una correlación directa entre puntos de historia y el esfuerzo de implementación de la historia de usuario. Es decir, no existe tal regla o ley que señale que si un punto de historia toma H horas implementarse, N puntos de historia tomarán N x H horas implementarse (por ejemplo: si la implementación de una historia de un (1) punto toma 25 horas, entonces la implementación de una historia de 2 puntos tomará 50 horas, no).

Es probable, eso sí, que al final, después de muchos sprints, el promedio muestre tendencia hacia esos números, pero nada evita, en el escenario propuesto, que una historia de 2 puntos le tome al equipo 15 horas y otra también de 2 puntos le tome 35 horas para implementarla o cualquier otro número, incluso podríamos tener una historia de 2 puntos cuya implementación tome 10 horas o menos. En cualquier caso, eso apenas sería la tendencia natural.

Además, aun con ritmo sostenido y con entrega de valor constante en cada sprint, no es lo mismo un equipo en el primer sprint del proyecto que en el séptimo o en el décimo noveno. No es lo mismo un equipo en abril que en septiembre o en diciembre. No es lo mismo un equipo si el proyecto va bien desde varios puntos de vista, como el valor entregado, la calidad, el consumo de presupuesto, etcétera, o si va regular o mal; y no es lo mismo si el equipo y aun la organización a la que pertenece han estado mejorando continuamente o si su crecimiento personal y profesional se ha estancado por acción del proyecto.

Todos esos factores que acabo de mencionar impactan positiva o negativamente la motivación del equipo y por consiguiente, el rendimiento de los miembros del equipo. Lo que finalmente se traduce en número de horas de esfuerzo necesarias para implementar una historia, o sea, para llevarla de ‘Propuesta’ o ‘En proceso’ a ‘Terminada’.

La misma calidad y el tamaño de las historias de usuario también afectan de una forma u otra el esfuerzo requerido para su implementación. Me refiero a la calidad con que son comunicadas al equipo por el Dueño de Producto o por quien corresponda, así también perturba de manera distinta una historia de 2 puntos que una de 5 o una de 8.

Y todo esto para concluir que en cada Planificación de Sprint se debe hacer el ejercicio de, precisamente, planear por horas de esfuerzo, de eso se trata esta ceremonia inicial de Scrum después de todo. La gran diferencia con la planificación de los métodos tradicionalistas es que no vamos a planear seis meses de trabajo o un año o dos, no, se trata solo de adelantarnos a lo que va a pasar en las próximas 2 semanas de trabajo, quizás tres.

Nuestros equipos deben o deberían tener el conocimiento y la experiencia para decirle al Dueño de Producto y al mismo Scrum Master, al final de la Planificación, cómo intentarán hacer su trabajo en el sprint que comienza y eso incluye contarnos el número de horas de esfuerzo que tomará implementar una historia de usuario en particular. Se trata es de dilucidar cuando nos tomará el diseño, la programación, las pruebas, la integración, la documentación y cualquier otra actividad concerniente a la construcción de la historia. Después de todo, para eso fue que precisamente se conformó el equipo.

¡Pero hay más!

Usamos Puntos de Historia para estimar el backlog y el esfuerzo a mediano y largo plazo porque son o representan un valor abstracto. También sabemos que es posible usar otros métodos abstractos de estimación como 'tallas de camisetas', días ideales, colores, tamaño de los planetas o, incluso como dice mi amigo Jorge Abad en sus Lecciones Aprendidas, podemos usar la técnica del ‘ojo de buen cubero’, estimar con Garrapatandamandapispuntos o con cualquier otra medida cuyas convenciones sean bien conocidas por todo el equipo.

El precepto fundamental aquí es que todos estos métodos producen estimados y los estimados, sobre todo en software, están condenados al error. Casi 50 años de experiencias después de aquella remota conferencia de la OTAN en Garmisch en la que de alguna manera se dio vida a la Ingeniería de Software nos han demostrado eso.

En cualquier caso para estos escenarios de mediano/largo plazo, si un usuario o cliente está exigiendo estimar en horas un proyecto Ágil, todavía no ha entendido el enfoque y necesita guía en ese sentido. Las horas son algo concreto sí, pero solo para lo que he explicado arriba, estimar un sprint corto o muy corto, de muy pocos días a dos semanas.

Pero igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones. Así que en vez de salir corriendo detrás de las horas, deberíamos enfocarnos en habilitar y empoderar nuestros equipos para que hagan un mejor trabajo.

----------

¿Ustedes qué creen? ¿Cómo estiman los sprints? Déjenmelo saber en el foro - la sección de comentarios más abajo.

----------

Más sobre Planificación en:

Planificación del Sprint: el primer paso para producir el máximo efecto

Respuesta al cambio sobre seguir un plan: ¡no planearás!

El artículo de referencia de Mike Cohn lo pueden encontrar en:

https://www.scrumalliance.org/community/spotlight/mike-cohn/september-2014/why-sprints-should-be-planned-with-hours-not-point