Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Cynefin. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Cynefin. Mostrar todas las entradas

miércoles, julio 17, 2019

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:

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:

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.


miércoles, abril 10, 2019

La caducidad del Scrum Master… y por extrapolación del coach ágil



El 10 de abril de 2019 un grupo de contactos de la comunidad Ágiles Colombia revivió este debate en el que yo no participaba quizás en los últimos cinco años. Hablamos de la “fecha de vencimiento del Scrum Master”, de la madurez del equipo, de si el Scrum Master agrega valor o no. Varios y distintos puntos de vista, una discusión con respeto y apertura, tengo que decirlo, lo que muestra que, de alguna manera, hemos madurado y que estamos aprendiendo a soportarnos, que hay apertura, y que ya no somos tan políticamente correctos. ¡Eso es bueno, creo!

Esta es mi opinión, ni más faltaba, soportada en mi experiencia:

Quiero empezar por dejarlos con la siguiente reflexión: llegar a considerar esto (que en algún momento no se requiere el Scrum Master) quiere decir que el desarrollo del equipo tiene un “techo”, es decir, un nivel máximo (de madurez). Algunos dirán que el equipo (de producto) y el Dueño de Producto pueden seguir evolucionando por sí solos; quizás sea posible, ¿pero hasta qué nivel? El equipo tiene una tarea principal y es precisamente el producto, la entrega de valor.

Al considerar este escenario, estamos diciendo que el así llamado mejoramiento continuo tiene un límite. Que en algún momento del tiempo no necesitaremos mejorar más, que llegamos a un nivel de madurez “non plus ultra”, que somos los más más, los que todo lo pueden y no hay nada ni nadie más allá.

Yo estoy hablando del rol, pero no veo al equipo “distribuyéndose” este rol de Scrum Master, en principio “as per Scrum guide”, entre sus miembros. El equipo tiene sus propios retos, inherentes a su papel, hablo de todo eso en lo que confluye la excelencia técnica y, sobre todo, en la entrega continua de producto con valor.

Quizás son dos cosas muy distintas, pero no veo un equipo de fútbol, aun uno de Rugby, o a una orquesta sinfónica, todos conformados por grandes estrellas en sus respectivos campos, jugando o interpretando sin el entrenador adecuado.

Lo escuché por primera vez de Ángel Medinilla: el Scrum Master vive en el futuro del equipo. Le compré la idea. Bueno, ¡en realidad, la tomé prestada! La promuevo en mis equipos y en las organizaciones con la que colaboro habitualmente. Me ha dado buenos resultados. Vivir en el futuro quiere decir que está pensando en cómo llevar a su equipo al siguiente nivel y en cómo preparar a la organización para ese “nuevo” y mejorado equipo. Mejoramiento continuo.

También sabemos que cuando una persona entra o sale del equipo, el resultado no es el mismo equipo, se trata de un nuevo equipo. Aun para equipos de alto desempeño, equipos maduros, equipos en el nivel desempeño del modelo Tuckman, aun para esta clase de equipos, el esfuerzo de “volver” a integrarse los hará regresar de nuevo a la etapa de formación. Y este impulso seguramente seguirá requiriendo de un gran Scrum Master cuyo foco sea llevar nuevamente al equipo a su estado de madurez más alto conseguido.

Voy a ir más allá. Hemos establecido ampliamente que el Scrum Master, al menos uno extraordinario, juega en distintas posiciones:

1.    Coach
2.    Maestro
3.    Líder servicial
4.    Gestor
5.    Agente de cambio
6.    Mentor
7.    Facilitador

Entre otras no menos importantes. Distribuir cada una de estas funciones en el equipo no es algo de poca monta y puede llegar a ser algo perturbador para los miembros de ese equipo. ¿Una por cada miembro del equipo? ¿Y qué pasa si es un equipo de menos de siete personas?

¿Y las tareas mundanas?

Veamos otro contexto:

En algún momento, abstraerse de las complejidades propias de un producto y dedicarse a preparar una retrospectiva puede ser un aliciente, una “pausa activa” para uno o dos miembros del equipo de producto. Pero no veo a largo plazo los beneficios de implementar tal práctica. Necesitamos a los miembros del equipo concentrando todo su esfuerzo en la generación de valor de manera frecuente para la organización.

Sí, ya sé, algunos van a decir que estoy tratando a la retrospectiva como algo frívolo, “terrenal”. ¿Y no es de eso de lo que estamos hablando cuando hablamos de jubilar al Scrum Master? Mirémoslo desde otro ángulo: a la luz de un equipo maduro, que seguramente estará enfrentando problemas de alta complejidad y de mucha incertidumbre, preparar y realizar un evento de Planificación o una Retrospectiva parecerá algo profano y hasta superfluo.

Pero no se equivoquen: no, los eventos Scrum no son para nada momentos vanos, ni siquiera para un equipo realmente “avanzado”. Mucho menos lo son la gran cantidad de otros eventos, sesiones, ceremonias, reuniones, actividades y prácticas que emergen alrededor del desarrollo de productos con Scrum y, por extensión, con pensamiento ágil o lean.

Sobre VUCA y Cynefin

Ah, y ya que toco este no menos peliagudo asunto de la complejidad y la incertidumbre, ¿qué hay acerca del mundo VUCA que habitamos hoy? ¿Qué hay acerca del caos que nos consume? Es en estos ambientes de altísima volatilidad y ambigüedad en los que se necesitan soluciones expeditas, prácticas y categóricas. Un equipo, aun uno con un alto grado de madurez, quizás no sea capaz de reaccionar por sí solo a esos escenarios que emergen de repente y mucho menos en iteraciones cortas de una o dos semanas. Es allí donde un Scrum Master, de esos que he dado en llamar “Extraordinarios” es útil. Incluso si el Scrum Master está parcialmente en el equipo, como plantean algunos, sus respuestas pueden llegar tardías o simplemente no llegar.

Y el Coach Ágil

Un Scrum Master extraordinario sabe que necesita un mentor, alguien que lo acompañe en el camino mientras se forma, mientras madura. Tanto uno como el otro no deben entorpecer las labores del equipo, tampoco deben generar dependencia. En ese sentido deben ser “invisibles”, pero esto no quiere decir que no sean indispensables para ayudar en la mejora de las personas del equipo.

Mi Conclusión

En mi opinión, sí es necesario el Scrum Master. La persona. ¡Y el rol que juega! Quizás sea posible un modelo donde no esté. Ni el coach ágil. Pero en mi experiencia, la evolución de este equipo se va a detener o se va a hacer excesivamente lenta.

¿Qué piensas de todo esto? Déjamelo saber en el foro.

Sobre el Scrum Master Extraordinario

Los invito a leer algunas de mis contribuciones al respecto: