Exprimiendo Scrum: Scrum y el control del proyecto (II): la visibilidad

Avance visible de la construcción de la Torre Eiffel

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.

16 comentarios sobre “Exprimiendo Scrum: Scrum y el control del proyecto (II): la visibilidad”

  1. Uno de los miedos del equipo de desarrolladores es mostrar los avances del software para que «te cambien todo otra vez», pero claro, no es lo mismo que en un proyecto de 10 sprints «te cambien todo otra vez» en uno o dos que en seis o en siete, significa que el resto de proyectos pendientes ha de esperar (¡¡¡uy, uy, uy!!!) y que ves que no te cunde.
    YO creo que scrum funcionará bien en bastantes casos, pero en otros… en fin que para esto de scrum muchos han de cam,biar el chip como se decía en los 90.

  2. Y yo creo que también hay jefes de proyecto que no les interesa dar visibilidad a su proyecto para que no se vea las pirulas que hacen…

  3. Considero que desde la planeación se deben etapas entragables que permiten tener una buena visibilidad, de esta manera e proceso de desarrollo girara en torno de crear avances visibles cada tanto y como bien lo dices esto terminara favoreciendo a todos.

  4. Increible que hablando de visibilidad y metodologías ágiles, no hayan salido todavía las palabras ITERATIVO e INCREMENTAL, que son dos ideas de base del desarrollo ágil.
    Me temo que a veces Scrum no nos deje ver el bosque. 😉

  5. @Julio: Los usuarios, los producto owners, los clientes, los stakeholders o llámalo como quieras no piden cambios por placer. Piden cambios porque ven oportunidades o carencias o descubren lo que el equipo de desarrollo y la tecnología puede hacer… Si tu presentas lo que el cliente necesita, el pragmatísmo siempre se impone y los cambios se autocontienen.

    @Vicenç: Las pirulas siempre cantan, todos hacemos pirulas. La única diferencia la marca el tiempo que tardas en detectarlas y corregirlas.

    @Juan Carlos: Totalmente de acuerdo.

    @Joserra: No usar las palabras ITERATIVO e INCREMENTAL es algo consciente. Están tan manidas que decir que un proceso de desarrollo es interativo e incremental es no decir nada en absoluto. Todos los procesos de desarrollo moderno dicen ser iterativos e incrementales, ¿pero cuantos ponen mecanismos y reglas explicitas que lo hagan explicito?.

    De los procesos de desarrollo me interesan más las ideas subyacentes que las etiquetas ;).

    ¡Gracias por los comentarios!

  6. Estoy deacuerdo, el Sprint Review es un mecanismo excelente para demostrar el progreso de la aplicación, si bien no exenta de problemas, por un lado obliga al equipo a realizar un gran esfuerzo ya que se quieren evitar los errores en la presentación de la aplicación y tenemos la obligación implicita de terminar las tareas a las que nos hemos comprometido a realizar al comienzo del sprint, de manera que si no las terminamos no podremos mostrar el trabajo realizado…

    Por otro lado nuestro trabajo sera evaluado por otras personas, algunas que ni siquiera tienen conocimientos básicos sobre
    informática y que no podran apreciar el coste del trabajo realizado.

    Por otra parte estaremos expuestos a las críticas, aunque lejos de aplacarnos nos deben ayudar a mejorar nuestro trabajo.

  7. No creo que iterativo e incremental sean etiquetas. Para que la visibilidad del proyecto encaje en un entorno ágil de desarrollo es importante que se base en entregas de producto terminado. Y esto no es posible hacerlo si el desarrollo no es incremental/iterativo.

    Sí que es verdad que se utilizan demasiado a menudo para no indicar nada real.

  8. Yo creo que la visibilidad ( tanto demos como retrospectivas ) es una parte esencial de todo desarrollo. El echo de tener que demostrar la funcionalidad cada cierto tiempo es muy positivo para el equipo porque se fuerza a tener un producto de calidad y no a ir desarrolando a lo loco y también es muy positivo para el cliente, product owner, etc, para ver los avances del proyecto, poder corregir, saber las desviaciones, etc.

    En mi corta experiencia utilizando metodologias ágiles de lo que estoy más contento es de las herramientas para proporcionar visibilidad al proyecto, tanto los sprint daily meetings, como las demostraciones y las retrospectivas. Creo que ayudan muchísimo al equipo.

    Perdón por el tostón.

  9. Hay un factor que echo en falta en la visibilidad. A lo largo de tu explicación se presupone el interes del cliente por conocer el progreso, ver el avance y ajustar los requisitos. Si tuviera que desear el peor mal para un JP es contar con un cliente que compra un proyecto «llave en mano», «avisame cuando este». Es muy tentador tomar esa libertad, pero en realidad es un gran castigo. La visibilidad no solo es una obligación para el JP y el equipo sino un compromiso que adquiere el cliente con el encargo del proyecto, tanto como el pago, y es el JP quien debe gestionar para que se satisfaga.

  10. Siempre he pensado que el cliente (o el usuario final) debe y tiene que estar alli, colaborando con la aplicacion… No hay desarrollo existoso sin una colaboracion COMPLETA de la persona que desea utilizarlo.

    En mi vida como desarrollador he cometido todo tipo de fallos, desde el tipico «oscurantismo» y «no lo ves hasta que funcione todo» hasta dar tanta manga ancha al usuario que cada dia era un cambio. Pero de eso se aprende, y recuerdo con mucho cariño una pequeña aplicacion que se desarrollo para una gran empresa (donde estube varios años entre unas cosas y otras) para el departamento de metodos y tiempos (los perros verdes los llamaban, por sus rarezas). Tal fue la colaboracion y entusiasmo de este departamento que no solo se acabo con exito la aplicacion dentro de plazo, no solo aprendi todo lo que se debia saber sobre el intrincado mundo de medir la productividad, si no que esa aplicacion que se desarrollo esta hoy en dia vigente (fue escrita en cobol hara 4 o 5 años) y NADIE ha conseguido plantear un cambio para Java o .NET que satisfaga a ese departamento.

    Es por esa razon que opino que una relacion directa con el cliente no solo es buena, si no que nos «baja» a muchos desarrolladores de ese pedestal de «sobreconocimiento» en el que muchos creemos estar y nos muestra que nuestra mision es unicamente satisfacer las necfesidades de una serie de personas CREANDO herramientas que realizen lo que ellos realmente necesitan.

    Y si me lo permitis, un saludo a los chicos de Met y Tiempo de esa empresa (que no nombrare aqui) Jose Angel, Jose Antonio y Daniel….con cariño.

  11. Excelente post Rodrigo; algún día aprenderé cantonés o mandarín, traduciré tus posts y me llenaré de dinero vendiendo un libro en China sobre gestión de proyectos :D. Seguramente lo que haré es cerrar el libro con un capítulo entero dedicado a la relación [equipo de desarrollo] // [cliente], porque veo que por lo general independientemente del tema a tratar, siempre sale a colación lo complicado que esta relación.

    Con respecto a la visibilidad, es un factor fundamental en cualquier proyecto que considere «serio»; pero en demasiadas ocasiones veo que es más fácil esconder la tierra debajo de la alfombra que aprender de los errores.

    Yo he estado en proyectos que han terminado mucho después de lo planeado inicialmente, pero con los clientes contentos, ya que todas las personas implicadas siempre estuvieron conscientes del trabajo que se estaba realizando, de las complicaciones con las que nos encontrábamos y finalmente (y tal vez lo más importante para los bosses) de como se reflejaba toda esta información en €€€. Y prefiero estos proyectos a «los otros».

    Saludos

  12. Completamente de acuerdo con lo que planteas. La visibilidad siempre es positiva y los cambios deberían también tomarse como algo natural y positivo (ayudan a buscar El camino). ¿Pero cuanta responsabilidad cae en los equipos de desarrollo y cuanta sobre las direcciones de las organizaciones en la adopción de estas buenas prácticas?

    Completamente de acuerdo con lo de que el software ejecutable es «la mejor metrica».

  13. hola..a todos, yo estoy haciendo mi proyecto de trabajo de grado con SCRUM y me gustaría que alguno de ustedes se comunicara conmigo para hablar un poco mas sobre scrum, yo les comento lo que se y ustedes conmigo igual. Me pidieron en la universidad que hiciera incapie en los foros…Gracias…

  14. Evidentemente, el cliente quiere ver en qué se está gastando el dinero, y cuanto mas largo sea el proyecto pero me lo pones porque no puede pasarme varios meses soltando dinero y no ver nada a cambio.
    Cuanto mas profundizo en SCRUM veo mucho sentido común basado en la experiencia y las buenas prácticas.

Responder a elbruno Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *