DISCLAIMER: En el anterior artículo adelantaba que hablaría sobre Historias de Usuario. Lamentablemente, mientras escribía éste, comprobé que se me hacía demasiado largo y he preferido posponer el refinamiento para la siguiente entrega.
En el primer artículo de esta serie me centré en las primeras conversaciones que tiene el equipo respecto de una idea, con el objetivo de descartarla o no. En este artículo voy a explicar qué tipo de conversaciones se tienen para decidir cuál elegir de entre todas las opciones disponibles y qué técnicas podemos emplear para facilitar esas conversaciones.
Priorización
Los criterios típicos para priorizar pueden ser: @Unlockd/do-you-prioritize-like-a-hippo-829479735376">HiPPO, el que más insiste, la matriz de Eisenhower o diferentes versiones que emplean la urgencia y la importancia como dimensiones, MoSCoW, etc. En mi experiencia, la mayoría de estos métodos no sirven realmente para priorizar sino apenas para no decir que no, por lo que realmente deberían quedar encuadrados en la fase anterior, que trata de distinguir si hacemos algo o no. En según qué contexto esto puede ser ya un gran avance.
Si hemos usado User Story Mapping, como ya comenté en el artículo anterior, es muy posible que hayamos ya aplicado alguno de estos criterios para crear nuestro plan iterativo e incremental. Si sólo tenemos un proyecto a desarrollar y no es necesario combinarlo con otras prioridades, entonces el problema es fácil: sigue el plan. Sin embargo, a veces nuestra pila de opciones (o backlog) se alimenta de diferentes fuentes.
Una vez que hemos decidido que sí podemos y debemos abordar el desarrollo de una de las opciones del backlog tenemos que responder a la pregunta: “¿Cuándo deberíamos empezar a trabajar en ella?”. Esa pregunta nos puede empujar a hacer un análisis detallado de costes, uso de recursos, disponibilidad de los mismos, ventanas de oportunidad y todo éso que tiene que ver con tratar de adivinar el futuro. Sin embargo, no puedes controlar cuándo terminará la tarea, pero sí cuándo la comenzarás. Así que en realidad el equipo se enfrenta a esta otra pregunta: “Cuando tengamos capacidad para trabajar en una nueva idea, ¿por cuál nos decidiremos, de todas las que tenemos en el backlog?”, o dicho de otra manera, “¿De entre todas las opciones, cuál es la siguiente tarea que debemos empezar?”
Para responder a esto necesitamos entender la naturaleza de la demanda y, como veremos también más adelante, nuestra predictibilidad como equipo dependiendo de la misma.
Análisis de la demanda
Si hemos hecho un análisis de riesgos y oportunidades con una técnica como Risk Profile, que ya comentaba en la primera entrega de este artículo, lo normal es que tengamos una idea bastante aproximada sobre costes y riesgos, incluído el coste de oportunidad, pero en mi opinión, lo que más nos ayudará a priorizar será el análisis del Coste de Retraso, que también puedes incluir en tu Risk Profile.
Coste de Retraso
La mayoría de las técnicas de priorización buscan optimizar el tiempo de entrega (“entreguemos a tiempo o lo antes posible”) o el valor (“entreguemos antes lo que más valor aporta o lo que más dinero nos hace perder”). Es difícil combinar ambos criterios. En mi opinión, el análisis de Coste de Retraso (CoD, de Cost of Delay en inglés) permite entender mucho mejor la naturaleza de la demanda y, en consecuencia, ordenar nuestra lista de opciones combinando urgencia y valor.
Creo que este artículo de Joshua J. Arnold es una buena explicación sobre cómo la mera conversación, tratando de entender el coste de retraso de una manera cualitativa, es suficiente para mejorar la manera de priorizar el trabajo.
Tipo de Coste de Retraso
En la Guía “Essential Kanban Condensed” (que puedes descargarte gratis), Carmichael y Anderson llegan a la conclusión de que hay cuatro perfiles básicos para categorizar el coste de retrasar la entrega de una tarea:
- Acelerado (Expedite en inglés). Cada momento que pasa perdemos más dinero, pudiendo llegar a colapsar el negocio si no empezamos a trabajar inmediatamente. Seguro que alguna vez te has enfrentado a un defecto en producción de esos que hay que resolver con la máxima urgencia. Cuidado, a veces no es tan evidente qué es tan urgente y qué no lo es.
- Fecha Fija (Fixed Date en inglés). La típica campaña de Navidad. Si no llegamos a tiempo, perderemos (o dejaremos de ganar) una cantidad fija, cuantificable como la oportunidad perdida. Pasada esa fecha ya no tendrá sentido.
- Estándar (Standard en inglés). Se trata de aquellas tareas cuyo coste de retraso es más o menos lineal con el tiempo. Cuanto más tardamos en entregar, más dinero perdemos (o dejamos de ganar). Ojo, dependiendo del negocio, pudiera suceder que este perfil no sea el más común, sin embargo, sí lo es en la mayoría.
- Intangible (Intangible en inglés). Son los típicos importantes pero no urgentes. Si no los abordamos nunca podríamos llegar a perder (o dejar de ganar) mucho dinero. Un ejemplo típico es la automatización de pruebas manuales o cualquier tipo de deuda técnica.
Me he permitido adaptar la imagen que usa Andy Carmichael en este artículo, que también te recomiendo si quieres profundizar en este tema. También Joshua Arnold clasifica los perfiles de las urgencias, pero a mí al menos me resulta más difícil de aplicar que los del coste de retraso, aunque es evidente que tienen mucho que ver los unos con los otros, como bien explica Carmichael en ese artículo al que te refiero.
Creo que es un buen ejercicio tomarte algo de tiempo en tratar de clasificar algunos de los casos que te sueles encontrar en tu trabajo. Luego veremos cómo estos perfiles también aplicarán para estudiar las Clases de Servicio, pero no nos adelantemos.
Coste de Retraso Dividido por la Duración
El Coste de Retraso Dividido por la Duración (CD3, del inglés Cost of Delay Divided by Duration) es una fórmula para ordenar (priorizar) opciones de manera meramente cuantitativa. Sin embargo, creo que ser capaces de cuantificar, aunque sea en un rango de valores, el coste de retraso atribuible a una opción cualquiera nos permite priorizar el trabajo de una manera más objetiva, lo que siempre es bueno cuando se trata de tomar decisiones en grupo.
Si te interesa, creo que el ejemplo y la explicación de este artículo es suficientemente bueno como para extenderme yo aquí. Si te interesa el framework de escalado SAFe, también verás que se utiliza una fórmula muy parecida: WSJF (Weighted Shortest Job First), propuesta originalmente por Donald Reinertsen en “The Principles of Product Development Flow” para maximizar el ROI de un equipo.
Eso sí, este criterio adolece de un gran problema: espera que conozcamos de antemano la duración de la tarea. Creo que Joshua Arnold explica muy bien en este artículo cómo los números concretos del Coste de Retraso o de la Duración no son lo más importante, sino la conversación sobre el valor aportado por cada opción que evaluamos y sobre el impacto que postergar la entrega podría tener sobre ese valor.
En mi opinión, el análisis de la demanda, independientemente de la técnica empleada se debe centrar no tanto en aplicar fórmulas cuantitativas sino en generar un aprendizaje colectivo a través de una conversación facilitada. Entender el perfil del coste de retraso es una conversación normalmente muy corta y ayuda muchísimo a que el equipo pueda tomar mejores decisiones, también técnicas. Si nos perdemos en encontrar los números exactos, nos olvidaremos de tener esas conversaciones significativas.
Análisis de la capacidad
De poco nos servirá conocer el impacto que tendrá retrasarnos en desarrollar una idea cualquiera si no entendemos nuestra capacidad para darle salida. Seguro que resuena en tu cabeza la pregunta “¿Cuánto tardaremos en desarrollar esta funcionalidad?”. Como explico aquí, es una pregunta bien legítima que un equipo estable, en un entorno estable y acostumbrado a abordar trabajos similares, responderá con cierta precisión bastante a menudo. Lo que sucede es que no es habitual encontrarse con este escenario. No podemos garantizar la mayoría de esas condiciones ideales. Así que lo mejor es hacer un pronóstico basado en nuestro comportamiento pasado.
Predictibilidad
Para conseguir una mayor predictibilidad, los equipos que hacen Scrum miden la velocidad del equipo, iteración a iteración. Hacen una estimación del esfuerzo que requerirá cada desarrollo, para decidir finalmente, en la reunión de planificación, qué tareas podrán abordar y cuáles quedarán para el sprint siguiente. Por mucho que es un avance respecto de otros métodos mucho más costosos, esa manera de medir y predecir tiene algunos problemas:
- la puntuación que asignamos a una tarea (aunque sea una vez acabada) es siempre subjetiva, dependiente de la experiencia pasada de los miembros del equipo,
- el comportamiento del equipo se sesga en función del tamaño asignado (previsto) de la tarea, lo que hace que el tiempo empleado sea una especie de profecía autocumplida o ley de Parkinson.
Una simplificación posible es contar el número de tareas que abordamos, es decir, darles a todas el mismo peso. Esta técnica evita perder tiempo en estimar el tamaño de la tarea, pero también evita la conversación que nos puede llevar a identificar algo que es inesperadamente “grande”. Ya veremos que en la fase de Refinamiento esto puede ser útil, pero en este punto del proceso en realidad lo que necesitamos es entender nuestra verdadera capacidad de trabajo.
En cualquier caso, en la mayoría de los casos, cualquiera de estos métodos basados en una estimación ligera son suficientes. Insisto en que la parte importante aquí es la conversación que se produce en el seno del equipo para entender mejor el valor y la urgencia de la tarea en comparación con el resto de opciones. Sin embargo, si tenemos muchas opciones o si debemos priorizar muy a menudo, quizás deberíamos pensar en hacer Kanban y en aplicar Clases de Servicio.
Clasificar la demanda
En realidad, todo el rato estamos hablando de priorizar cuando hay una tarea aún más importante: clasificar la demanda. Hace tiempo explicaba en este artículo cómo manejar la demanda no planificable y balancearla respecto de la demanda planificada (comprometida). Si te fijas, llas reglas para manejar el trabajo no planificable estaban muy cerca de lo que llamamos Kanban, salvo que no se habla explícitamente de limitar el WIP.
Para el trabajo no planificable definíamos una serie de políticas para clasificar la demanda y, a partir de ellas, asignarles parte de nuestra capacidad de trabajo. Esos criterios (o políticas) encajaban bastante con los arquetipos de coste de retraso que he explicado más arriba. Así, el trabajo estándar es el que se podía planificar y dar salida con una gestión más rígida de la capacidad (siguiendo las reglas de Scrum), el trabajo urgente se trataba como un “expedite”, pagando por el coste de interrupciones, pero porque este coste se entendía menor que el coste de no abordarlo inmediatamente. El resto de políticas tenían mucho que ver con nuestro conocimiento de nuestra capacidad de trabajo y, por tanto, nuestra capacidad para responder en un tiempo razonable (aceptable en términos de coste de retraso).
Cada política venía a ser una Clase de Servicio. Pero antes de explicar qué son las Clases de Servicio debemos pagar un peaje. Necesitamos comprender nuestra capacidad. Para esto hay dos métricas importantísimas: el lead time (o tiempo de producción) y la flow efficiency (o eficiencia del flujo).
Lead time (o tiempo de producción)
Es el tiempo que tarda el equipo en realizar todo el trabajo de desarrollar una idea. En nuestro proceso de desarrollo, arrancamos el reloj desde el momento en el que comienza a trabajar en ella, es decir, desde que tiramos de ella (recordemos que estamos haciendo Kanban) en la lista de opciones que ya hemos filtrado, y lo paramos en el momento en el que la funcionalidad se ha puesto a disponibilidad de los usuarios.
En el artículo que menciono más arriba, sobre cómo pronosticar la duración de un desarrollo, muestro diferentes gráficas que te pueden ayudar a entender mejor cómo usar el lead time para que el equipo busque ser más predecible.
Flow efficiency (o eficiencia del flujo)
Es la proporción de tiempo que el equipo dedica a trabajar efectivamente en una tarea, respecto del tiempo total que tarda la tarea en ser completada (el lead time). Una eficiencia del 100% se consiguiría si nunca estuviera bloqueada o esperando en una cola.
Entender la eficiencia de un equipo para tratar un tipo de tareas es muy importante porque ayuda a entender cómo trabaja el equipo, no sólo internamente, sino también, por ejemplo, cómo trata las dependencias con otros equipos.
Los equipos que hacen Kanban frecuentemente revisan estas metricas. Las conversaciones que se producen en estas retrospectivas son muy interesantes pues les permiten entender mejor su capacidad y cómo la gestionan, de lo que se derivan acciones de mejora como cambios en las políticas de gestión de las tareas.
Clases de servicio
Una Clase de Servicio es una política o conjunto de políticas que establece el orden en que seleccionamos el siguiente elemento de nuestra lista de opciones, una vez que nos hemos comprometido a trabajar en ellas.
Creo que un buen artículo donde se explican las clases de servicio es éste. Si quieres más, también puedes ver la última presentación de David Anderson sobre Clases de Servicio (también en video). Desde mi punto de vista, Anderson se centra mucho en la matemática detrás del mecanismo, asumiendo que la mayoría de nosotros trabajamos en entornos donde el número de opciones es tan alto como para que sus modelos estadísticos sean significativos. En cualquier caso, merece la pena atender a sus argumentos.
Aplicar Clases de Servicio afectarán a tus lead time, por tanto, cambiar las políticas de las mismas, también afectará a los mismos. De ahí que entender los lead time de tu equipo sea tan importante. Por ejemplo, qué hace que un defecto en producción (bug) tenga un lead time más corto que el resto de historias. Quizás es que necesitan un tipo diferente de refinamiento. Si cambias la manera en que se gestionan este tipo de tareas, porque el equipo ha entendido bien la naturaleza de las mismas, será más fácil reducir el tiempo en que se les da salida (lead time) y aumentar la eficiencia del proceso (flow efficiency).
Es relativamente fácil ver que los Expedite tienen una eficiencia de flujo cercana al 100% pues las políticas que les aplicamos se centran en dedicarles mucha más atención que al resto. Es frecuente ver que las Fixed Date también tienen una eficiencia bastante alta, pues no queremos ser penalizados por llegar tarde. A partir de conocer nuestros lead times y emplear técnicas de pronóstico como el método de Montecarlo, es bastante fácil sentirnos cómodos posponiendo el inicio de estas tareas, comenzando por otras opciones con perfiles de coste de retraso menos agresivos. Como siempre, lo más difícil es darles importancia a los intangibles. De ahí la relevancia de las Clases de Servicio. Una política que he visto que funciona muy bien es asignar una capacidad de trabajo fija, por ejemplo, un timebox o ciertas personas dedicadas. Personalmente prefiero la primera porque produce menos silos, pero la solución es siempre muy dependiente del contexto.
Conclusiones
Aunque en el gráfico del proceso de desarrollo que ilustra el artículo anterior esta actividad de priorizar (o seleccionar la siguiente tarea) no es muy relevante, como habrás podido comprobar, requiere de mucha conversación para establecer un marco de decisión. Una vez hemos entendido cómo es nuestra demanda y nuestra capacidad, podemos acordar las políticas para gestionarlas.
Si te fijas, la mayor dificultad de establecer Clases de Servicio, es acordar sus políticas. Conseguir poner de acuerdo al equipo y a los stakeholders sobre cómo gestionarán la capacidad de trabajo del equipo y que sea compatible con las necesidades de los clientes es una conversación que puede ser complicada, pero cuyos beneficios son incuestionables, pues contribuye a reducir muchísimo el estrés y los costes por priorizar equivocadamente. Mi consejo es que, a estas reuniones de revisión de las políticas, no te lleves únicamente argumentos racionales sino que también te lleves argumentos emocionales, como los que te he ido salpicando a lo largo de este artículo. Aunque nosotros veamos muy claros los beneficios, no todo el mundo está en disposición de empezar a trabajar con Clases de Servicio desde el primer momento. A veces, simplemente tener una manera de no decir que no es un gran salto para un equipo. El trabajo del Agile coach es ayudar a que este camino sea transitado lo antes posible, pero con la menor resistencia.
Establecer un CONWIP o establecer un límite del WIP muy bajo para todo el sistema haría que la mayoría de este trabajo fuera innecesario. Imagina un proceso en el que nunca empieces a trabajar en una idea nueva hasta no haber terminado otra y que sólo hubiera una idea en curso cada vez. Ya sé, esto sólo ocurre en muy pocos casos, quizás en en startups muy incipientes, donde cada idea a explorar es un pivot sobre su modelo de negocio. Si sólo hay una idea en la que trabajar no hay nada que discutir, se hace y punto. No se trata de hablar por hablar. 😀
En el artículo que viene profundizaré en la siguiente parte del proceso, que solemos conocer como Refinamiento. Además, veremos varias técnicas para facilitar las conversaciones que tienen lugar en esta fase.