Sabemos que el desarrollo ágil de software (Agile) nació precisamente en el entorno del software. En estos 20 años ha sufrido una gran evolución, muchas de las prácticas que propone Agile se han aplicado en otras áreas de la empresa debido a su impacto y calado.
Además, como muchos equipos han encontrado impedimentos en su propia empresa para poder entregar valor, se ha derivado en tener que “agilizar” el resto de la empresa si se quería mejorar la entrega de valor.
No sabría decir en otros países, pero en España, el software se ha visto como un “mal necesario”. Las empresas tenían web o email porque había que tenerlo, pero no haciendo una apuesta clara por ello. De hecho, pocos productos digitales existen en España, hemos creado una industria del software orientado a servicios. Debido a esto, las consultoras tienen un gran peso en la industria del software.
¿Qué es Agilizarse?
Agile se define mediante cuatro valores y doce principios. Con una visión rápida, el objetivo es entender a nuestro customer, integrarlo en nuestro proceso de desarrollo, ser adaptativo, buscar la mejora contínua y ser capaz de integrar la calidad como parte de la agilidad.
Cuando hablamos de Agile, hablamos de entregar software con valor, es decir, resolvemos problemas mediante el software a base de inspeccionar nuestras hipótesis y adaptar continuamente nuestro proceso y nuestro producto.
En muchas organizaciones y empresas, hemos visto que se miraba a Agile como una manera de reducir tiempos de entrega, incorporar cambios sin “quejarnos” y acabar cumpliendo planes imposibles que nunca se cumplían. Agile, poco a poco, va demostrando que no se trata de hacer software rápido, sino de resolver problemas a través del software. Bajo esta premisa, podemos pensar en expandir esta filosofía a otros mundos.
Agile fuera de la tecnología
Solemos aplicar Agile fuera del software porque nos enfrentamos a un problema complejo donde las necesidades de nuestros customer no paran de cambiar. Si tenemos esa situación, una mentalidad Agile nos puede dar mejores resultados.
Han pasado 20 años desde que nació Agile, sabemos que es un adjetivo, pero hoy en día muchas personas han ampliado su definición, incorporando nuevas acepciones.
Hay quien lo ve como la capacidad de adaptación de un negocio para generar valor. Gracias a la inspección y la adaptación podemos pivotar rápidamente en base a datos de negocio.
Otras personas entienden Agile como un gestor de riesgos. Una vez más, el hecho de analizar los riegos cada poco tiempo nos permite anticiparnos a que se disparen. Esto nos permite evitar sorpresas o disminuirlas.
Agile también es la capacidad de satisfacer a nuestros customer a base de entregas constantes y sostenibles en el tiempo. Aquí juega un papel esencial la calidad, ya que a largo plazo nos permite una adaptación más rápida y una mejor experiencia.
También hablamos de que Agile es mejora continua, dado un sistema de trabajo, perfeccionarlo en periodos cortos.
Bajo todas estas definiciones, podemos aplicar Agile fuera del software para resolver multitud de problemas. Por tanto, primero deberemos entender muy bien qué problema queremos resolver y cómo usar la transparencia, inspección y adaptación como herramientas para resolverlo poco a poco.
Cómo implantar Agile fuera de la tecnología
A la hora de implantar Agile, me gusta más la aproximación Kanban, ya que permite implantar partiendo del punto actual del equipo, sin ir muy rápido. Con Scrum tenemos que crear roles que pueden no existir en el cliente y eso es un problema. Scrum parte de la idea de que, o lo implantan todos, o no es Scrum. Cierto es, que cuando implantamos, introducimos elementos poco a poco, pero Kanban aquí es más flexible.
Me gusta simplificar un equipo de trabajo en varios elementos. Por un lado, tenemos un trabajo que hacer, y por otro, personas que saben hacerlo. Partiendo de esa premisa, tenemos que modelar el proceso que utilicen para trabajar de manera que podamos visualizarlo. Es decir, hay que responder a la pregunta: ¿Cómo trabajáis hoy?
Partiendo del sistema actual, lo primero es visualizar los pasos que damos para completar el trabajo. Es decir, tenemos que visualizar nuestro proceso de trabajo. Esto puede ser complejo, podemos realizar diferentes tipos de trabajo y pensar que cada uno es distinto. Por ejemplo, si tenemos una pizzería el proceso cambia según el pedido, pero podemos simplificarlo de esta manera:
Una vez que lo hemos modelado, llenamos nuestro tablero con el estado actual de trabajo. De esta manera, todos visualicemos el estado del trabajo, y entonces podemos empezar a tomar decisiones. Hacer una primera retrospectiva o análisis del proceso actual es algo que suele ayudar mucho, en muchas empresas no se fomenta el preguntar a los empleados.
Es importante que entendamos un cambio de mentalidad. En todo sistema de trabajo, tratamos de ordenar el propio trabajo, no a las personas. El objetivo no es que las personas trabajen mucho, sino que el trabajo fluya y salga. Por ejemplo, un repartidor puede ayudar a preparar pedidos si estamos atascados haciendo pizzas. Si el trabajo además está ordenado por lo que más valor nos pueda aportar, maximizamos el valor de lo que queremos conseguir.
El siguiente paso consiste en poner encima de la mesa las políticas de trabajo que tengamos. En muchos equipos tienen reglas no escritas, lo que hace cada persona lo interprete diferente y esto genere problemas. ¿Puede un cocinero repartir una pizza si los pedidos están parados? Hacer el ejercicio de anotar nuestras reglas suele generar debates muy interesantes para los equipos.
¿Qué medir cuando hacemos Agile fuera de la tecnología?
Aunque muchas métricas son dependientes del negocio, hay algunas que sí podemos generalizar. Por ejemplo, el cycle time, el tiempo en el que tardamos en hacer las cosas. Inicialmente podemos asumir que cada tarea que realizamos son comparables y por tanto, hacemos una medición general. Después, podemos definir diferentes tipos de trabajo y medirlos por separado.
En Kanban nos gusta predecir en base a estadística en vez de estimar, para ello debemos medir. En los equipos solemos dar diferentes tipos de servicio, por tanto, es interesante definir los items y los servicios que prestamos. Por ejemplo, en un hospital tenemos diferentes tipos de trabajo: operar una pierna o un parto. Por otro lado, están las clases de servicio, no es lo mismo atender una pierna rota en urgencias que por el médico de familia aunque el “trabajo” es similar. En ese momento, los medidores mejoran en calidad y precisión, no es cuestión de qué hacemos (items), es cuestión de cómo lo resolvemos (clases de servicio).
¿Qué eventos podemos utilizar en Agile fuera de la tecnología?
Kanban propone siete eventos. Implantarlos rápido suele dar problemas, por lo que recomiendo empezar gradualmente. Por ejemplo, una vez a la semana hacer un replenishment dónde hablemos del trabajo de la semana, y eventos diarios para analizar el trabajo planificado de la semana (Esto se conoce como la Kanban meeting). Al principio, es habitual que la reunión diaria se convierta en reporte, nos toca enseñar lo que significa que el trabajo fluya y poner foco en bloqueos.
El último lugar, toca implantar la retrospectiva de manera periódica. Como comentaba, es básico, tener puntos donde analicemos cómo mejorar. Por eso, cada varias semanas nos sentamos a analizar cómo estamos trabajando. en Kanban se utiliza la Service Delivery Review, dónde analizamos al equipo y el resultado de su trabajo. Tener métricas implantadas es esencial, así podemos entender si tenemos una tendencia positiva o negativa.
Limitar el trabajo
Cuando aplicamos Agile fuera de la tecnología, tenemos que explicar la importancia de limitar la cantidad de trabajo que podemos hacer. Si tenemos cinco motos en la pizzería, tenemos que limitar la capacidad de aceptar pedidos. Por ejemplo, si quedan 15 minutos para cerrar y todas las motos están repartiendo, puede ser mala idea aceptar otro pedido. Es mejor decir que no, que prometer algo que no podemos cumplir.
Es típico en las empresas querer hacer mucho trabajo sin foco alguno. Esto acaba por saturar a los equipos, y en entornos dónde nos pagan por pensar, el estar demasiado ocupados no es buena idea. Agile también es maximizar la cantidad de trabajo no realizado, es decir, conseguir mejores resultados haciendo menos. Para que funcione, tenemos que tener foco, y para ello limitar la cantidad de cosas que hacemos.
Esta práctica es de las más avanzadas. En mi caso, suelo utilizar el Okaloa como simulador de Kanban y hacerles ver la importancia de decidir qué trabajo hacer. Sin embargo, muchas cultura no permiten decir que no a un trabajo, y esto genera mucha pérdida de valor.
Conclusiones
Agile original es software, y desde ese punto de vista no podemos salir de ahí. Sin embargo, Agile ha dejado una cultura y una manera de pensar que se puede extrapolar a otros mundos.
Utilizando el método Kanban, podemos ayudar a los equipos a mejorar su capacidad de entrega y a fluir en su proceso de trabajo.
Y tú, ¿haces Agile fuera de la tecnología?
