Agile Mindset, kanban, Organizaciones Diferentes, scrum

¿Scrum o Kanban? es EVIDENTE señor Watson.

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.

appetite-1239056_1280.jpg

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.

hourglass-3197626_1920.jpg

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?

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s