Exprimiendo Scrum: Scrum y el control del proyecto (II): la visibilidad
Hablaba en mi anterior post sobre el control de proyectos con Scrum sobre el avance, uno de los aspectos claves del control de un proyecto de software. Hoy toca hablar de otro aspecto relevante en el control de proyectos: la visibilidad . ¿Qué entendemos por visibilidad? Yo lo definiría como la capacidad del equipo de desarrollo de hacer evidentes los avances realizados durante el tiempo transcurrido de desarrollo.
Todo Paris, podía ver como progresaban las obras de la Torre Eiffel. Solo tenían que mirar al horizonte para cuantificar el avance. Eso es visibilidad en un proyecto. ¿Cómo podemos lograr esto en los proyectos de software? ¿Por qué es tan importante?.
La visibilidad es un aspecto fundamental en el desarrollo de software. Nuestros clientes, sean externos o internos a nuestra organización, tiene derecho a tener evidencia de que el dinero que aportan al proceso de desarrollo se está convirtiendo en valor. Esto se llama más ponposamente 'asegurar el retorno de la inversión'. Otro aspecto relevante es que otros departamentos, ajenos al desarrolla de software, pero dependientes o relacionados con este, tienen la necesidad de conocer lo que pueden esperar del software estamos desarrollando y tienen que tener la posibilidad de ir acomodando sus acciones al progreso que perciben en el desarrollo de software.
Surge un proyecto, y el equipo de desarrollo se abre al mundo y sale a capturar requisitos, habla con los clientes, con diferentes departamentos, captura sus necesidades y luego… luego ese mismo equipo se retira a su 'ratonera' y no se vuelve a saber de él… durante meses. Frecuentemente se ve a los equipos de desarrollo como un conjunto de hechiceros que tras saber el conjuro que el cliente necesita, y tras un largo tiempo de 'vete tu a saber que andan haciendo'… presentan un software… que no sirve a nadie. A menudo esta presentación se pospone hasta que todo el mundo se pone nervioso, y otras partes de la empresa o los clientes empiezan a demandar visibilidad. Pero ya es tarde. Cuando la visibilidad surge de una demanda externa en lugar de surgir de las prácticas habituales del equipo aparece un problema claro: la confianza está dañada. Además, sin visibilidad no hay feedback y sin feedback no acertaremos a liberar valor. Andaremos camino pero quizás en la dirección equivocada . Pero esta es otra historia que en otra ocasión abordaré. Los equipos de desarrollo tenemos que salir de la ratonera y mostrar que estamos construyendo. Mi experiencia es que hacer ese esfuerzo cambia de manera radical la relación de los equipos de desarrollo con el resto de los componentes de la empresa y el cliente, y lógicamente, para bien.
Los equipos de desarrollo hemos actuado a menudo con opacidad. Muchos equipos de desarrollo fallan a la hora de comunicar su progresos. Muchos equipos olvidan que la única medida de su progreso es el valor que liberan y entregan a sus clientes en forma de funcionalidad. Y muchos más equipos de desarrollo obligan que el software al contrario que otros productos tiene valor aunque no esté completamente desarrollado.
Pero los proyecto no solo fallan por como se comportan los equipos de desarrollo, en una cuestión cultural de la gestión clásica de proyectos. Se tiende a ver el avance los proyectos como una cuestión objetiva, pero no es así. El avance de un proyecto es una cuestión de percepción. Es evidente que a menudo hay divergencias entre el avance que el cliente percibe y el avance que el equipo de desarrollo proclama. Solo el avance percibido por el cliente es relevante. De nada sirve que nosotros, los desarrolladores, digamos que hemos hecho 'arcos de iglesia' si el cliente no lo percibe así. Un cliente que no percibe avance será, más tarde o más temprano, un cliente cabreado. No hay proyecto exitoso posible sin la colaboración del cliente, y no hay cliente cabreado que sea colaborado.
Otro error habitual es mostrar el avance del proyecto mediante artefactos que no son software ejecutable. Uno de estos típicos artefactos son 'los Project', pero la experiencia nos ha enseñado a los desarrolladores y los clientes que un diagrama de Gantt lo aguanta todo. ¿Quién no ha vivido la paradoja de un diagrama de Gantt que muestra un progresos del 90% en un proyecto que todo el mundo conoce que está a años luz de sus objetivos?... Las métricas se pueden sesgar con facilidad, la de progreso no es una excepción.
Además tendemos a pensar que el progreso es una función de los hitos alcanzados o del tiempo transcurrido, pero la realidad es que el avance del proyecto es una función del valor liberado para el cliente. Da igual el empeño que pongamos en un proyecto, o el tiempo de desarrollo que dedique el equipo, si no logramos liberar valor para el cliente, el progreso del proyecto es nulo.
Los clientes, cada vez más, necesitan ver para creer y lo equipos de desarrollo necesitamos que los clientes vean el resultado de nuestro trabajo para saber que estamos en el buen camino, que vamos en la dirección correcta, que nuestros esfuerzos están proporcionando algo útil al cliente. Evidentemente es necesario cambiar la relación con el cliente para que esto funcione.
Scrum habilita mecanismos explícitos para lograr hacer visible el avance del proyecto. Este mecanismo es el Sprint Review, una reunión en la que el equipo muestra los avances logrados por el equipo de desarrollo mostrando software que funciona. Además todos los involucrados en el proyecto y especialmente los representantes del cliente o el propio cliente debe proporcionar feedback sobre lo que ve. Esta sencilla liturgia de Scrum, vital en esta metodología, es un poderosísimo mecanismo para introducir la necesaria visibilidad en el equipo de desarrollo.