agile coaches

Muchas veces se tienen dudas como “Y en Scrum se puede…”, “¿y puedo hacer…?”, “¿y se puede…?”. Parece que Scrum es como un conjuro mágico en el que si solo cambias algunas cositas podría seguir funcionando. Y si en vez de ancas de rana pongo ojos de sapo, ¿funcionará? Scrum está lejos de ser una fórmula mágica que soluciona todos nuestros males. Veamos cómo la Business Agility o Agilidad Empresarial puede ayudarnos con estas cuestiones

¿Qué es la Agilidad Empresarial o Business Agility?

El problema real que encierra esta pregunta es que estamos asumiendo que Scrum es un fin. “¿Se puede hacer esto o lo otro y sigue siendo Scrum?”. Cuando a nadie le debería importar si es Scrum o no.

El día que un CEO toma la decisión de reservar una buena parte del presupuesto de los siguientes años para comenzar una transformación, no está buscando que los equipos estén haciendo Scrum, Kanban, Product Owners empoderados o equipos auto-organizados.

Nuestro CEO está buscando la supervivencia de su empresa ganando competitividad e intentando poder luchar de tú a tú algún día con las nativas digitales. Busca alcanzar la Agilidad Empresarial o “Business Agility”:

Capacidad de poner en valor rápidamente nuestro desarrollo (fast revenue)
Alta gestión de riesgos
Poder aprovechar las oportunidades de mercado

Scrum es una herramienta para activar Business Agility en las organizaciones. Lo hace creando al menos un incremento terminado, potencialmente usable, un incremento Done en cada Sprint. De esto va Scrum. No es un fin, es un medio.

Scrum no va de daily, retrospectivas bailando o similares. Va de entregar valor. Scrum nos proporciona elementos: artefactos, eventos y roles, que nos brindan una alta capacidad de inspección, adaptación y transparencia. Los pilares del empirismo. Son las armas que necesitamos para crear incrementos de alto valor y maximizar nuestra capacidad de generar ingresos.

¿Como nos habilita el Incremento “Done” la Agilidad empresarial?

Fast revenue

Los desarrollos de productos se siguen enfocando a proyecto. Primero obtenemos todos los requisitos, creamos un plan para los siguientes meses (o años) y, al final del todo, me voy al mercado a intentar monetizar.

Con el enfoque iterativo incremental que nos propone Scrum y teniendo incrementos terminados, integrados y listos para usarse en cada Sprint, podré ir buscando una version de mi producto que me permita llegar al mercado e ir generando beneficios.

Un ejemplo es el lanzamiento de Amazon Prime Videos. Con poco catalogo, sin soporte para Chromecast o sin aplicaciones nativas para tablets y teléfonos comenzó a poner en valor su nuevo producto lo antes posible.

Alta gestión de riesgos

Podemos hablar de tres grandes riesgos y la manera que tiene Scrum de gestionarlos es resolverlos.

Riesgo de mercado: ¿Estoy creando lo que mis usuarios realmente necesitan? Scrum va de crear un incremento y conseguir feedback real para adaptar mis siguientes pasos si es necesario.
Riesgo financiero: ¿Esto cuánto me va a costar? Por mucha documentación y planes que hagamos ya sabemos que siempre habrá variables que no conozcamos. E incluso las variables que conocemos tienen baja predictibilidad. La única manera de conocer el coste es realmente empezar a hacerlo y luego intentar obtener predictibilidad basada en datos históricos.
Riesgo técnico: ¿Mi idea se puede realizar con las tecnologías que actualmente estoy usando? Una vez más, la única manera de saberlo es empezar a hacerlo e ir obteniendo una nueva versión de mi producto Sprint a Sprint.

Capacidad de aprovechar oportunidades del mercado

Si tienes previsto un desarrollo de más de un año y una oportunidad de mercado llega cuando estás en el sexto mes de trabajo con todo abierto, nada integrado, en definitiva, nada terminado. O Incluso si simplemente has estado documentado lo que vas a hacer los siguientes meses, sumarte a esta nueva ola conlleva muchísimo esfuerzo. Tanto que generalmente se decide dejar pasar o esperar a terminar todo el desarrollo disminuyendo drásticamente tu capacidad de competir.

Conclusion

Una vez que tenemos claro qué Scrum es un medio para hacer crecer Business Agility en nuestra organización, será fácil respondernos a preguntas “¿en Scrum se puede…?”. Simplemente debemos pensar si al introducir un cambio estoy aumentando o disminuyendo mi Agilidad Empresarial.

¿En Scrum se puede tener dos sprints de desarrollo y luego otro de hardening?

Cuando terminen los sprints de desarrollo:

Si viene una oportunidad de mercado…
- ¿Podré sumarme a ella? No.
- ¿Alguien me puede asegurar cuándo podré hacerlo? No. Nadie puede asegurar que el hardening vaya a tomar solo un sprint o dos.
¿Puedo poner en el mercado lo que tengo al final del Sprint de desarrollo? No. Adiós al fast revenue.
¿Estamos tomando decisiones del futuro de nuestro producto basándonos en feedback real? No. No lo hemos podido poner en producción por lo que no tenemos ninguna métrica de negocio real. Al no estar nada terminado no tenemos transparencia de la situación del producto, esto nos llevará a discusiones sin fundamento con los Stakeholders en la Sprint Review eliminando nuestra capacidad de adaptación al mercado.

¿En Scrum se puede hacer la Daily Scrum 2 veces por semana?

La Daily Scrum nos permite inspeccionar el avance de nuestro Sprint para alcanzar la Sprint Goal con nuestro Incremento. El Sprint Goal puede representar una hipótesis sobre nuestro producto que negocio quiere comprobar si realmente es lo que quieren los usuarios y si nos va a otorgar el beneficio esperado. Por ejemplo, que mis usuarios van a querer pagar con Paypal.

La Daily Scrum es una manera de maximizar las posibilidades de que el equipo de desarrollo tenga terminado todo el trabajo relacionado con la Sprint Goal a final del Sprint. Eliminando algunas daily,

¿estoy ayudando a mi Agilidad Empresarial o poniéndola en riesgo?

Hace más o menos un año, publiqué un artículo de los más leidos de este blog, sobre el pseudoagile, las pseudostartups y el cargo cult. A pesar de lo simple del concepto, me sigue sorprendiendo que cada vez más gente cae presa del mismo. Como los Agile Coaches.

¿Que es el cargo cult?

De forma resumida, se trata de hacer algo porque lo hacen otros, esperando obtener los mismos beneficios que hemos observado en otros. Otra versión es hacer algo porque siempre se ha hecho así.

En el caso que relataba Feynman, los miembros de las tribus de los mares del sur imitaban los comportamientos que habían visto a la armada estadounidense. Así conseguirían que los aviones bajaran del cielo para hacerles regalos. O al menos lo intentaban.

Hace unas semanas visité a un posible cliente y me invitaron a participar en el standup de los miembros del comité de dirección. Daba pena. Lo que vi no era una reunión de inspección y adaptación sino una reunión de reporte entre pares. Lo cual no esta mal, pero se aleja del objetivo que tienen los métodos ágiles. Abordar la mejora continua a través de inspección y adaptación.

El Standup del equipo de coaches no funciona

La semana pasada, en el Agile Coach Camp Barcelona, propusieron una reunión acerca de como organizar y facilitar el trabajo entre equipos de coaches. En los últimos meses lo he escuchado mucho. Mucho. Hablé con otros coaches que decían que sus reuniones de standup no funcionaban. Los asistentes no estaban comprometidos y no parecía que ofreciera mucho valor a los asistentes. No sabían que hacer.

¡Es obvio! Lo he vivido personalmente. Hay un equipo de Agile Coaches en la organización y lo primero que proponen es hacer reuniones diarias de sincronización. Para saber como van. Incluso muchos de ellos tienen un tablero kanban en el que van apuntando lo que están haciendo. Cómo ejercicio de transparencia, es muy interesante. Sin embargo, como ejercicio de agilidad es inútil. No hay inspección y adaptación.

Durante mi estancia en Capital One UK, el equipo de coaches se reunía todos los días con la engagement manager que actuaba de Product Owner para sincronizar lo que estábamos haciendo. El problema era que cada coach se enfocaba en un área distinta de la organización a la que daba servicio.

Convertía esa reunión simplemente en un reporte al jefe. No trabajamos juntos ni con un objetivo común en pequeñas iteraciones. Ni de forma incremental.

Tres situaciones en las que un Standup o Daily Scrum tiene sentido

Todos trabajamos hacia el mismo objetivo

En el caso de Scrum, fijamos un Sprint Goal y trabajamos para completar esa meta durante el Sprint. Los Product Backlog Items (ya sean historias, bugs o Use Cases) son lo de menos. Lo importante es que nos enfoquemos en el Sprint Goal, que es el que da sentido al trabajo que hacemos. En Scrum se llama Daily Scrum porque se enfoca en la inspección y adaptación.

Todos formamos parte del mismo servicio

En el caso del método Kanban, hay que identificar servicios que se ofrecen desde la práctica ágil y enfocarse en la gestión del flujo de trabajo, a través de la gestión de los límites WIP. Por ello, los involucrados en el mismo servicio hacen un Standup para analizar el flujo e identificar posibles bloqueos y áreas de mejora.

Trabajamos en la misma tarea

Si, por ejemplo, trabajamos en preparar un training dos o mas personas, es necesario que mantengamos un nivel alto de comunicación e interacción para asegurar que estamos cumpliendo con lo que estamos preparando. Para este objetivo es mejor el trabajo por pares.

Agilidad en un equipo de coaches

Para conseguir agilidad en un equipo de coaches es necesario entender en primer lugar cual es el objetivo de la práctica: ¿Es el objetivo dar uno o varios servicios permanentes a la organización? o en su lugar ¿Es el obejtivo actuar iterativamente en eliminar impedimentos que impiden que la organización funcione? ¿O son ambos?

En el primer caso, es necesario identificar los distintos servicios que la práctica ágil presta a la organización. Estos pueden ser por ejemplo: Training, Coaching y Estrategia. Cada uno de estos servicios tiene un workflow distinto (i.e. es un sistema Kanban distinto) que se puede seguir a través de un sistema completo Kanban (tablero, límites WIP y políticas). En base a la experiencia, se puede establecer un SLA del servicio de cara a la organización.

En el segundo caso, es necesario identificar los Sprint Goals de cada iteración para que el equipo de coaches al completo actúe para resolver un impedimento o proporcionar una mejora a la organización. El equipo de coaches puede adoptar una versión de Scrum para mantener las oportunidades de transparencia, inspección y adaptación.

El tercer caso se puede abordar a través del uso de Scrumban, a pesar de que este está pensando para hacer una transición de Scrum a Kanban y no como una herramienta que persista a lo largo del tiempo.

Es hora de pensar, eliminemos el Cargo Cult

Cuando empezamos a trabajar en una organización como agentes del cambio, cada mensaje que transmitimos es importante. No ser capaces de demostrar el valor de nuestras propias herramientas significa perder la confianza de la organización. No crearemos tracción.

Por ello hay que pensar sobre lo que hacemos. Detenidamente. Ser humildes y en lugar de gritar nombres a los cuatro vientos, reflexionar sobre los pilares del control empírico de procesos, si es eso lo que queremos usar. O sobre los principios de Lean Flow. Nadie nos presiona. Ofrezcamos el mejor servicio a nuestros clientes.

Scrum y la Business Agility