La guerra de Corea de 1950 a 1954 es una guerra que tiene un componente interesante desde el punto de vista militar. Este conflicto armado fue la primera vez que enfrentó a aviones de reacción. Estos aviones nacieron en la etapa final de la Segunda Guerra mundial pero no fue hasta la guerra de Corea que se utilizaron en combate. En concreto, se enfrentaron el Mig-15 Soviético y el el F-86, dos aviones de combate que revolucionarán el mundo de la aviación.
Lo curioso de este enfrentamiento es que el Mig 15 era una bestia tecnológica. Su relación peso potencia, su velocidad y su maniobrabilidad lo hacían muy superior al avión americano. Sin embargo, las bajas se contaban diez a uno en favor del estadounidense. A pesar de que el MIG15 era tecnológicamente más potente, era incapaz de vencer a los F-86.
El motivo era la visibilidad. Al parecer el Mig15 tenía una cabina llena de remaches que dificulta la visión del piloto mientras que el F86 dispone de una cúpula semi abierta que permitía mayor visibilidad. Si habéis visto cualquier película de aviones de combate el avión que se posiciona delante y está siendo perseguido por otro, continuamente está maniobrando para esquivar los disparos y evitar ser derribado. Para poder hacer eso y poder situarte detrás de tu atacante debes de tener mucha visibilidad para entender muy bien el contexto en el que te mueves.
¿Cómo consiguen visibilidad los equipos Scrum?
Planes por Reviews
Jeff Sutherland, cocreador de Scrum, había tenido varias experiencias negativas con equipos de software que hiper planificaban durante los 80 y principios de los 90. Harto de desarrollar planes que nunca se cumplían y generaban mucha frustración le dijo a su jefe que se negaba a planificar. Haremos un trato, no te voy a entregar un plan que sabemos ambos que no se va a cumplir, a cambio te daré con software terminado en menos de un mes y cada vez que nos juntemos analizamos lo que entregamos.
Nace así las Sprint Review primigenia, la alternativa al famoso diagrama de Gantt o cronograma. A pesar de que muchas personas piensan que el Product Backlogs es la alternativa al plan porque contiene los “requisitos”, realmente es la Sprint Review la auténtica alternativa.
Una Sprint Review bien hecha dispone de métricas de negocio y de feedback continuo del mercado. Podemos evaluar cada vez que nos reunimos el estado de nuestro producto con respecto a los objetivos que se ha marcado. Y gracias a este evento podemos evaluar próximas acciones y por tanto ser más adaptativos. ¡la adaptación es más importante que cumplir un plan!
Los equipos Scrum que no disponen de Sprint Review o la hacen de manera fatídica son los menos adaptables y por eso acaban convirtiéndose en scrum fall en forma de sprints. Sin visibilidad, podremos ser muy buenos, pero estaremos a merced del mercado. El que se adapta vive, el que se mantiene rígido pertenece al mundo de los dinosaurios.
La importancia de la visibilidad
Hemos visto muchos equipos que trabajaban incontables horas y se esforzaban por dar un resultado. Orgullosos del mismo se lo mostraban a sus responsables y estos a su vez cuando acababa la reunión comentaban que el equipo iba mal. Muchas veces tras un gran trabajo había una baja rentabilidad o un producto que no se utilizaba.
Esta situación se repite muchas veces y provoca una enorme rabia cuando te das cuenta de que los responsables están evaluando de una determinada manera al equipo y este es inconsciente de esa métrica. El equipo se enfada con la empresa ¿por qué están descontentos si nos estamos esforzando?
Un equipo Scrum tiene que entender muy bien el propósito de su existencia y cómo se le va a medir a lo largo del tiempo. Si un equipo no tiene esa visibilidad acabará tomando decisiones erróneas y luego se pagarán en la organización.
Propósitos y métricas
Uno de los grandes problemas de la Sprint Review aparece cuando lo aplicamos en proyectos cerrados. La existencia de proyectos cerrados abunda en el mundo de la consultoría tecnológica, aunque hay clientes finales que también disponen de ellos. Los proyectos cerrados se suelen evaluar por la entrega en fecha. Y el gran problema es que la fecha suele ser binaria: o llegas o no llegas; sin importar el impacto real en negocio
Cuando acabamos un proyecto en fecha y tienen bajo impacto de negocio, desde tecnología solemos acusar a las personas que definieron el proyecto porque fue su culpa. “Solo me encargo de la implementación, tú tienes la culpa de haberlo definido mal los requisitos”. La cruda realidad es que ambos pierden.
A pesar de que moralmente pueda tener razón, la realidad es que hemos hecho un esfuerzo para algo que nadie utiliza, no es útil. No hay nada que frustre más a un equipo que desarrollar algo que nadie quiere.
Por eso, en proyectos cerrados aplicar Scrum es difícil, deberíamos evitarlo. Ahora bien si afrontamos un cambio cultural en el que pongamos sobre la mesa métrica de negocio entenderemos mejor cómo será la entrega de ese equipo. Y en ese momento, en el que situamos el éxito de un equipo Scrum en su capacidad de generar impacto, necesitamos la máxima visibilidad posible del mercado.
Negocio o muerte
Cuando hay métricas de negocios sobre la mesa los equipos se suelen motivar tratando de alcanzar algo que es difícil. A los mejores equipos les encanta superar retos, mejorar métricas, alcanzar hitos difíciles.
Hay personas de tecnología que no les importa lo que ocurra en su negocio. Para mí es una falta de profesionalidad; los desarrolladores tenemos que entender que nuestro trabajo tiene que dar unos resultados y esos resultados suelen estar cerca del negocio. Incluso aunque hagamos un determinado software que sea puro tecnológico (nacido de la estrategia tecnológica de la empresa) también tenemos que darle un valor a nivel organizativo. Tiene que tener un impacto positivo de alguna manera.
Un equipo que evita medir su impacto es un equipo poco maduro que rara vez funcionará. De hecho, el hecho de que existan muchos equipos Scrum sin estas métricas hace que se genera recelo sobre el propio marco. Scrum está para maximizar valor pero cuando evitamos medir dicho valor, ¡Scrum es ineficiente! Y encima, usamos Scrum para alcanzar fechas imposibles, en el mundo complejo, alcanzar fechas es una pérdida de tiempo.
Y tú ¿entregas valor o sigues planificando?