Cuando trabajamos en organizaciones que se están iniciando en Agile les explicamos que hay muchas maneras de aplicarlo. El método más extendido es Scrum, y siendo Kanban el siguiente más seguido, ¿cuál deberíamos elegir para nuestro equipo?
Normalmente los equipos que desarrollan lo hacen con Scrum y después en mantenimiento pasan a Kanban. A mí esta regla me ha recordado siempre al modelo tradicional. En los equipos en los que he participado como desarrollador siempre ha cambiado la manera de hacerlo antes de la salida a producción y lo que ocurría después. Generalmente en la primera parte nos matábamos por llegar a una fecha y después por resolver incidencias.
Si usamos Scrum en modo proyecto para llegar a fecha y Kanban para correr como pollos sin cabeza para hacer incidencias. ¿Dónde está la mejora?
Hace un tiempo me presenté a una prueba Agile en la que tenía que defender un caso. El ejercicio hablaba de un equipo que recibía peticiones de muchas personas y de priorización. Lo primero que se me vino a la cabeza era hacer Kanban, suena a mantenimiento, sin embargo cuidado. ¿Qué queremos mejorar? Y esa es la pregunta que debe marcar cómo queremos trabajar. Como bien me enseñó mi compañera Crisevelis, mide lo que quieras mejorar, por tanto decidamos en base a mediciones.
¿Cómo se mide en el modelo tradicional?
Si seguimos el proceso que propone el PMP el camino a seguir es el siguiente. Primero, definimos el alcance, averiguar qué es lo que vamos a entregar y después tratamos de calcular el coste y el tiempo que nos llevará. A partir de ahí, centramos la energía en medir las desviaciones en tiempo y coste sobre nuestro plan. El problema de esta estrategia es que, invertimos mucho tiempo en saber si estamos o no desviados porque en todo momento nos basamos en estimaciones. Esto, en un entorno complejo donde hay incertidumbre, nos obliga a gastar demasiada energía para acabar por no tener el control que deseamos tener.
La alternativa a este tipo de mediciones es Evidence Based Management, donde usamos datos de lo que ocurre para tomar decisiones. EBM ha sido actualizado recientemente, dividiéndolo en cuatro áreas de conocimiento llamadas KVA. Vamos a analizar cada KVA y que forma de trabajo puede fomentarla.
Current Value (CV)
Este área clave trata de darnos información sobre el valor que tenemos hoy en día en el producto. No hablamos de futuribles, hablamos del estado actual con la información real.
Medir el valor dependerá mucho del objetivo de lo que estemos construyendo. Si queremos aumentar el número de usuarios, mejorar la conversión o reducir los tiempos de uso de la aplicación. Tenemos que sacar medidores como los costes, los ingresos / número de empleados o el índice de uso de las funcionalidades. Para conseguir que esto mejore lo ideal es un proceso iterativo e incremental y por ello Scrum aplica de manera excelente.
Scrum pone el foco en la maximización de valor por eso si queremos mejorar nuestro CV esta debe ser la opción. Gracias a tener figuras como el Product Owner que deben maximizar dicho valor, apostar por un marco como Scrum nos permite potenciar nuestro valor.
Time to market (T2M)
La velocidad con que somos capaces de entregar es vital. Nos ayuda a saber nuestro tiempo de respuesta al mercado, a nuestros customers. Dentro de este tiempo podemos medir no solo el tiempo de respuesta sino los desperdicios, como el tiempo en reuniones poco útiles. En un mundo digital donde ir rápido es una clara ventaja poner el foco en el T2M ayuda.
Si nuestro equipo está centrado en el T2M entonces deberemos de apostar por Lean-Kanban. El motivo es simple, Lean como filosofía busca la implantación de medidas operacionales que mejores nuestra gestión del flujo y, en el caso del software, mejora de capacidad de entrega. Para ello Kanban tiene su propio método en el que visualizamos el flujo de trabajo y tratamos de mejorarlo con técnicas como limitar el WIP.
Quizás este sea el motivo por el que nos cuadra con equipos de mantenimiento, donde lo que buscamos no es tanto medir valor sino que demos un servicio rápido y de calidad.
Ability to Innovate (A2I)
La habilidad para innovar no debemos confundirlo con una habilidad de crear cosas super disruptivas que constantemente rompan el mercado (aunque podría ser también). Hablamos de la capacidad de un equipo de abordar nuevas ideas y desarrollos frente al mantenimiento del equipo actual. En muchos equipos software se invierte poco en una programación de calidad, lo que provoca que acumulemos deuda y eso impacte a la larga en la capacidad de incluir en nuevas funcionalidades.
Un medidor muy bueno es el % de elementos que hemos finalizado que son realmente nuevos respecto del total finalizado. De esta manera, si el % es bajo significa que tenemos que invertir mucha energía del equipo en el mantenimiento del sistema, ¿hemos invertido en calidad a la hora del desarrollo? Si somos una startup con un producto y en 3 meses tenemos un % de deuda es muy elevado entonces estamos muertos porque nuestra reacción al mercado va a ser muy pobre.
Por tanto, la habilidad para innovar se asocia mucho con la calidad de nuestro trabajo. Scrum o Kanban tienen diferentes elementos para fomentar dicha calidad: Scrum cuenta con el Definition of Done y Kanban con las políticas de calidad entre estados. Aún así, si lo que más te preocupa es la habilidad para innovar, debes de apostar por técnicas de desarrollo que la potencien como pueden ser XP, TDD, BDD o Mob Programming. Todas ellas buscan la calidad de desarrollo sobre otras cosas y por tanto harán que tu habilidad para innovar sea alta.
Unrealized Value (UV)
El valor no realizado habla de la capacidad que tiene nuestro producto si fuéramos capaces de entregar todo aquello que nuestros usuarios nos demandan o esperan de nosotros. Este área es un poco peligrosa, porque entramos en el terreno de las estimaciones y de las previsiones sin conocimiento. Para ser poderosos en esto, debemos tener un contacto claro y directo con el mercado y con nuestros customers.
Todo valor no realizado cuando se lo damos a un usuario es cuando podemos corrobar que era valor o no. Hay productos con un CV bajo pero con un gran UV, por lo que disponen de un gran potencial y por eso se invierte dinero. Un caso contrario lo viví en un gran banco donde había un producto que estaba teniendo éxito (valor actual alto) pero que, debido a una regulación en las comisiones, su valor no realizado se desplomó y se dieron cuenta que el coste por usuario iba a ser superior al beneficio y decidieron desmontar el producto.
Para conocer nuestro valor no realizado hay métricas como saber el % de mercado que tenemos o saber la satisfacción actual y lo que desearían nuestros customers. Si lo que nos preocupa es saber el potencial de nuestro producto aquí podemos utilizar técnicas como Design Thinking, técnicas de prototipado, muestras, y diferentes experimentos. Todas estas técnicas se suelen decir que no son “Agile” en el sentido estricto ya que no aportan valor como tal, y es cierto, no recomiendo invertir demasiada energía en ellas si eso afecta a nuestra capacidad de entrega de valor.
Uniendo todo
Cada área KVA de Evidence Based Management puede ser usado por cualquier equipo. Puedes tener un Scrum Team que se centre en el Current Value, pero que utilice Sprints de una semana para acelerar su capacidad de entrega (Time-2-market) y a su vez tenga un Definition of Done muy estricto que garantice calidad.
Sin embargo, si eres nuevo con EBM, te recomiendo que no trates de medirlo todo, solo aquello que realmente quieras mejorar y del resto lo que no te suponga un esfuerzo excesivo. A medida que madures podrás decidir añadir nuevas métricas que te permitan una mejor toma de decisión.
Y tú, ¿Cómo decides si un equipo es Scrum o Kanban?
Antes que todo muchas gracias por el artículo, me pareció bastante bueno.
En mi experiencia la implementación de uno o de otro marco de trabajo depende mucho de la madurez del equipo, del negocio, de los tiempos y hasta el tipo de tareas.
Muchas veces los «mantenimientos» solicitados por negocio son cambios fuertes que hacen interminable el desarrollo.
Otras veces son solo operación que debe de ir en un proceso y flujo diferentes.
Muchas gracias por tu aportación 🙂
Muy buen artículo.
También añadiría que otro sistema que nos puede ayudar a determinar y justificar qué metodología agile utilizar es fijarnos en cómo debemos atacar el triángulo de hierro.
Como sabéis el triángulo de hierro es aquel que está formado por el Alcance, los Recursos (o Presupuesto) y el Tiempo. En el centro también está la Calidad y es un cuarto componente pero que, como veremos, no entra en la dualidad Scrum-Kanban.
El problema del triángulo de hierro es que nunca se pueden satisfacer todos sus vértices porque en projectos de software la incertidumbre es muy elevada. Es decir, si fijas el Alcance, tendrás que sacrificar o el Tiempo (entregar más tarde) o te costará más dinero (más recursos dedicados). Lo mismo sucede cuando fijas cualquiera de los otros dos vértices.
Ahora bien, en qué se diferencian Scrum y Kanban con respecto al triángulo de hierro?
Scrum juega flexibilizando el Alcance priorizando por valor, es decir, se entrega aquello que aporta más valor para el cliente e incluso se aceptan cambios sobre lo más valioso por delante de otros PBIs (Product Backlog Item). En Scrum el Tiempo y los Recursos (y la Calidad) quedan fijados al inicio. Un ejemplo cotidiano de projecto Scrum es la planificación de una boda: te casas un día concreto y tienes un presupuesto fijo e inamovible. Luego vas priorizando sobre tus preferencias, que si el menú, que si el vestido, el coche, etc. Lo que queda claro es que lo que no llegue a la boda no vale, y lo que no puedas pagar tampoco.
Kanban sí fija el Alcance. Lo otro que fija es el Tiempo (y la Calidad), así que juega con los Recursos. Como ya se ha dicho, un gran ejemplo de Kanban son los departamentos de atención al cliente. Toda llamada ha de ser atendida de principio a fin, en un tiempo máximo y con una mínima calidad. Si quieres atender más llamadas por hora sin sacrificar nada de lo anterior sólo te queda poner más teleoperadores.
Como consecuencia de la diferencia de enfoque el tipo de métricas que se usan en cada metodología es diferente. Por eso en Scrum se mide el valor entregado y la velocidad del equipo, mientras que en Kanban se mide el tiempo de ciclo y se limita el WIP.
En fin, espero haber ayudado con mi comentario.
Un cordial saludo.
Javier