Una de las prácticas que hemos heredado es el concepto de “colchoneo”. El colchoneo consiste en añadir tiempo o dinero a una estimación con el fin de protegernos de riesgos que puedan aparecer. El concepto de colchoneo no es malo, se utiliza en forma de Plan de Riesgos en el PMP y su función es esa. El colchoneo es una manera elegante de protegernos de la incertidumbre y evitar pérdidas.
El problema del colchoneo es que no es transparente. Una consultora lo añade y no informa a su cliente. Además, hay clientes que después demandan una “rebaja” y así garantizamos las ganancias que queríamos. Esta situación, a parte de ser poco honesta, provoca que nos enfrentemos a un desarrollo sin garantías ninguna de que ganemos dinero o de que funcione bien. En el PMP lo que se hace, es que esos colchones se transparentan. Al cliente se le transmite que hay una parte que se cobra para evitar problemas que puedan surgir, de esta manera se crea una relación de mayor confianza.
El gran riesgo que percibo, es que, el concepto de Producto Mínimo Viable (MVP) está generando muchos problemas en los equipos. Llamamos MVP al conjunto mínimo de funcionalidades que, como mínimo, necesitamos para un objetivo concreto o salir a producción. Esto ya genera una tensión en una relación cliente-proveedor: “yo he reducido el alcance, he puesto de mi parte, os toca cumplir”. Puede generarse una expectativa donde nuestro cliente entiende que ya ha puesto de su parte y que, por tanto, es el proveedor el que se tiene que apretar para conseguir ese alcance en fecha.
Toda esta situación, puede derivar en que acabemos teniendo problemas para “llegar a la fecha” y acabemos haciendo lo de siempre: echar horas, renegociar el alcance, meter gente en el equipo o disminuir la calidad. Todas estas acciones acaban minando la moral del equipo y destruyendo la imagen del proveedor. La única medida protectora fue añadir margen económico, así, si nos vamos de fecha podemos pagar un tiempo de desarrollo del equipo manteniendo un margen aceptable para nuestra compañía. Esto sigue sin evitar que hay una expectativa de entrega en fecha no cumplida.
Para evitar esta situación, os propongo una alternativa que hemos probado con algunos equipos. Imaginemos que estamos ante la típica situación de “tenemos que tener esto y necesitamos fecha”. Suponemos que tenemos los requisitos “claros” y que tenemos un equipo y experiencia en la tecnología que vamos a utilizar. El equipo estima y, aproximadamente calcula que necesitará 10 Sprints de dos semanas (hacer estimaciones tempranas para mí es un riesgo pero aún así supongamos que ocurre). En este caso, una manera responsable de trabajar con nuestro cliente es decirle: “el equipo piensa que en 10 Sprints podría tenerlo este MVP, aún así, vamos a firmar 20 Sprints. De esta manera, no cerramos una entrega de un MVP, trabajamos Sprint a Sprint con vistas a lo que queréis, pero dejamos tiempo para cambios, problemas, incidencias o cualquier cosa que ocurra”.
De esta manera, tratamos de proteger lo más importante entre un cliente y un proveedor: la relación de confianza. Si os fijáis, en este ejemplo estamos utilizando herramientas del mundo tradicional (estimación temprana, foco en la alcance-fecha, no medimos valor), pero porque aún no tenemos un cliente con una confianza que nos permita proponer una visión de valor.
Si aceptamos, ahora es el momento de empezar a promover el cambio. Cuando entreguemos podemos tener conversaciones sobre los cambios que han surgido, su origen y motivación y cómo hemos reaccionado ante ellos. Quizás, esta experiencia permite desbloquear futuros cambios que nos permitan usar Scrum para gestionar la incertidumbre mejor.
Tabla de contenido
Entradas relacionadas
¿Quiéres que tu organización haga más Scrum? ¡Cambia la definición de Scrum!0 (0)
Comentarios recientes