Quería compartir un par de anécdotas que seguramente muchos de vosotros habéis vivido. Una vez estaba trabajando como Scrum Master en un cliente y tras varios Sprints descubrimos que no tendríamos todo el trabajo que esperaba la organización en una fecha dada. Tiempo después, descubrí que Scrum no busca cumplir alcance en fecha, esa es la mentalidad de proyecto, y Scrum busca más la mentalidad de producto de generar valor constante. Sin embargo, a aquella reunión asistió un miembro del comité de dirección y dijo la siguiente frase “Pero… ¿por qué no llegamos?, si somos Scrum somos más rápidos”. Ahí mi responsable le respondió “¡claro que sí!”. Con el tiempo nunca entendí eso, para mí Scrum está más relacionado con la flexibilidad y adaptación que con la velocidad… ¡No buscamos ir más rápido para cumplir un Diagrama de Gantt impuesto!
Scrum cómo un leopardo
Otra situación “divertida” que viví fue en una compañía en la que me presentaron una diapositiva con un leopardo corriendo y ponía “Scrum, desarrollo rápido de software”. Si yo soy un cliente y veo esa diapositiva, pienso “¡Dame dos Scrum de esos! Porque por fin se va a cumplir la fecha con todo lo que yo quiera ¡Y con cambios gratis!”
Desde entonces, siempre he luchado con un lema “Scrum no es ir rápido, Scrum es ser adaptable”. Cuando he acompañado o entrenado equipos, siempre trato de enseñar que el gran beneficio de Scrum es ser flexible con respecto a las decisiones y no tanto, un desarrollo veloz.
Scrum no busca cumplir un plan más allá de un Sprint, no va de eso y, nos guste o no, quien intenta aplicar Scrum en proyectos acaba descubriendo los mismos problemas que siempre nos han acompañado. Es más, un mal Scrum es peor que un waterfall. En un waterfall, al menos, tienes un plan al que agarrarte en caso de que algo vaya mal, en un mal Scrum no solemos tener nada de eso.
Todo iba bien hasta que profundicé en mis conocimientos de Product Management y a través de Scrum.org me llega el siguiente mensaje:
“Un buen Product Owner es capaz de ayudar a un Scrum Team a entregar de manera rápida necesidades de los customers”.
¿Qué significa eso?
¡Pero si esto es lo que nos ha llevado a las organizaciones al desastre! Un cliente nos pide una subida urgente en una fecha imposible porque se lo han prometido a los clientes y acabamos entregando un software con una calidad baja. ¿No dijimos que Scrum no iba de velocidad? ¡Siempre que nos centramos en velocidad acabamos por meter la pata! ¿Un Scrum Team debe ser rápido?
La respuesta a esto la he encontrado con el tiempo y la madurez. Un Scrum Team poco maduro es aquel que tiene muchas limitaciones para hacer Scrum debido al contexto y, sobretodo, a la organización a la que pertenece. Ocurren cosas como que el Product Owner no está disponible y se salta eventos; los integrantes del Development Team tienden a tener etiquetas y apenas colaboran entre sí; no disponemos de medidores de negocio, ni de una visión clara de lo que queremos hacer. Al final, nos dedicamos a tratar de llegar a una fecha y esto nos provoca acumulación de deuda técnica.
Un Scrum Team maduro que haya resuelto muchos impedimentos en la organización puede llegar a ser muy rápido. Rápido significa que si medimos su Lead-Time será muy bajo. El Lead-Time es el tiempo que pasa desde que recibimos una necesidad y se la entregamos a un usuario final. ¿Cómo podemos ser rápidos haciendo esto sin afectar a la calidad?
Transformación de Procesos
Para que un Scrum Team sea rápido las personas deben trabajar de otra manera, esto requiere en las organizaciones actuales una transformación de procesos. Además, el propio Scrum Team debe estar entrenado en Scrum y en técnicas que le permitan trabajar de manera eficiente.
En muchas organizaciones basadas en el control, para tomar una decisión hay que hacer malabares porque todo el mundo quiere estar enterado de lo que está pasando y tener el poder de decir “esto no se hace”. Con este tipo de manera de gestionar, lo que acabamos provocando es que se limite y retrase a los equipos, lo que impacta totalmente en nuestra capacidad de entregar rápido.
He visto organizaciones en las que hasta el presidente tenía que validar las pantallas que se iban a subir a producción. Si tenemos que esperar a que toda la jerarquía valide las pantallas iremos muy lento, ¡el mercado no espera!
Por tanto, un nuevo sistema de gestión basado en delegación como propone Management 3.0 o una estructura más liberadora como propone Frederic Laloux y su modelo de organizaciones (Teal) nos ayudarán a mejorar el tiempo en la toma de decisiones.
Un medidor que puede ayudar a un Product Owner que quiera ver reducido este tiempo es el “On-Product-Index” que consiste en medir el tiempo que pasamos en reuniones. Para aplicarlo, se puede crear una tarjeta cada vez que finalice una reunión y apuntar las personas que asistieron, el topic tratado y la duración. Después, toda esa información ayuda a tener conversaciones con la organización sobre la manera en la que se toman decisiones dentro de ella.
Transformación de la Tecnología y cómo la construimos
Para que un Scrum Team pueda entregar rápido, debemos tener en cuenta que la tecnología juega un papel clave. Hay tecnologías que nos permiten automatizar una gran cantidad de nuestro código, dándonos la capacidad de hacer un despliegue muy rápido y garantizando calidad de manera veloz. Para ello, hay que invertir en calidad desde el principio, invertir en piezas de funcionalidad que nos permitan que la integración de código se haga lo más eficiente posible.
Por ejemplo, en una organización en la que trabajé decidieron disponer solo de dos entornos preproductivos que se compartían entre todos los equipos. Esto nos genera mucho retrasos, porque había que esperar una ventana que nos permitiera usarlo. Además, había que tener reuniones para “pelear” la disponibilidad de dichos entornos porque no eran capaces de organizarse mejor. Todo esto reducía costes, pero retrasaba la entrega de valor. ¿El ahorro mereció la pena? Depende del servicio que queremos ofrecer.
Además, no es sólo tecnología, es programar bien y para ello, podemos utilizar técnicas de programación madura como patrones de diseño, pair programming, TDD u otras. El objetivo es que la tecnología no sea un impedimento que retrase la puesta a disposición del usuario de nuestra feature desarrollada. Estas técnicas hay que enseñarlas, invertir en formación e invertir en tener tiempo para implantarlas y si no hacemos esta inversión, no podemos esperar que los desarrollos vuelen. Y lo más difícil no es aplicarlas, es tener espacio para poder hacerlo. Enseñar requiere tiempo, y usarlas garantiza una calidad, pero requiere de un cambio cultural de entender que si no invertimos en ellas, y no reducimos la calidad aunque lleguemos a un hito con menos funcionalidad, es la clave de todo.
Mentalidad de Producto
En mi opinión, esta es la transformación más difícil de entender. Los Scrum Team rápidos necesitan que haya una mentalidad de producto dentro de la organización. Esto tiene muchas implicaciones.
Por un lado, necesitamos que el equipo sea multidisciplinar, lo que provoca que no haya silos en la organización y que el equipo tenga todo lo que necesita para entregar. En algunas organizaciones, incluyen a abogados en los equipos para las validaciones legales y, en otras, a marketing para la coordinación con campañas publicitarias.
Necesitamos que el Development Team tenga libertad para tomar decisiones, lo que provocará que sus miembros se puedan autoorganizar. Cuanta más autonomía les permitamos, más capacidad de correr, porque no tendrán que pedir permiso para todo, directamente se centrarán en la entrega de valor.
El Product Owner debe tener poder de decisión y tiempo. Gracias al poder de decisión, un Product Owner puede decidir en qué cliente centrarse en cada momento, qué feature hacer o qué expectativa acometer. El tiempo en el que atendemos las necesidades de los customers es clave: si elegimos como Product Owner a una persona muy ocupada, el tiempo de respuesta aumentará, y por tanto, el servicio de la organización. Tener un Product Owner con esa capacidad nos acelera mucho la llegada de peticiones al Development Team para que desarrolle el incremento y, además, permite disponibilidad para la toma de decisiones durante el Sprint.
A todo esto sumemos que el Scrum Team tenga un apoyo completo de los managers de la organización. Los managers deben apoyar Scrum, entender el desarrollo empírico y trabajar más con una gorra de coach, facilitadores y de solucionadores de impedimentos organizacionales, que con una gorra de ordeno y mando bajo el continuo control de los equipos.
Cuando los managers presionan para cumplir fechas imposibles, al final los equipos acaban por reducir la calidad con tal de “llegar”. Esto genera deuda técnica que se empieza a acumular provocando que al final no podamos ser rápidos porque un pequeño desarrollo requiere lidiar con mucho código en mal estado.
¿Equipos de alto rendimiento?
El concepto “alto rendimiento” para mí es peligroso porque muchas organizaciones con mentalidad tradicional están buscando equipos que sean capaces de cumplir esas fechas imposibles a las que se han comprometido. Cuando decimos que el Scrum Team es rápido, no es eso lo que buscamos.
Un Scrum Team rápido es aquel que pone el foco en el mercado, lo estudia, trabaja con los customer y les propone soluciones. Desarrolla rápido gracias a que tiene el apoyo de la organización, a las personas entrenadas tanto en Scrum como en tecnología y una mentalidad de producto y de actitud hacia el usuario.
Si nos fijamos, todo esto requiere un cambio bestial en la organización ¿Estamos dispuestos a ello?
