Durante los últimos meses he podido trabajar en diferentes consultoras tecnológicas (ahora digitales todas) donde he podido ver su manera de implantar Scrum y utilizarlo.
¿Dónde está el aporte de valor? Imagina el siguiente caso. Perteneces a una empresa de alquiler de coches ubicada en Barcelona, y quieres un nuevo software para tus agentes que están en el mostrador en Mallorca. Aunque el usuario de ese software son tus empleados, la persona afectada por el mismo, el “customer” real es la persona al otro lado del mostrador. Según cómo sea ese software, se prestará un servicio mejor o peor.
Ahora, imagina que para este nuevo software contratas a una empresa, una consultora tecnológica que lleva más de 20 años haciendo proyectos y con un portafolio increíble de casos de éxito. Además, te hace un buen precio. Esta consultora deriva gran parte del trabajo a su factoría de Sevilla, así reduce costes porque el transporte del software es muy barato. Sin embargo, esta factoría trabaja con otra que está ubicada en Chile, así bajan todavía más los precios y rentabilizan las operaciones.
Y ahora bien, ¿Cómo crees que es la relación entre el desarrollador que está en Chile y el customer final? La relación es tan lejana, que el viajar para averiguar qué es valor nos va a disparar los costes de una manera increíble. O por el contrario, entregaremos en fecha un software que después no quiera nadie (desperdicio absoluto).
Recordemos que cuando se creó Scrum el concepto era el de personas juntas colaborando por un objetivo, en el caso del rugby era la pelota. Scrum no es una persona en Chile, dos en Sevilla, tres en Barcelona y la pelota en Mallorca. Por tanto, aplicar Scrum en situaciones de este estilo se hace inviable a pesar de que hagamos todos los eventos y tengamos un precioso Jira.
Modelos actuales de relación impiden hacer Scrum
El gran problema de la consultoría lo podemos encontrar en el manifesto Agile donde dice que la colaboración con el cliente es más importante que la negociación contractual.
Al final el cliente te pide un modelo cerrado, así reduce riesgos y controla el coste (incluso aprieta). Es como si llevas el coche al taller y le regatas al mecánico como se arregla la caja de cambios. La diferencia es que el mecánico te deja sin coche hasta que pagues lo que el arreglo cuesta. El contrato lastra, y mucho, tener un contrato Agile nos permite entregar valor.
Labores poco productivas
Al introducir una consultora en el proceso de creación de Software introducimos tareas que antes no existían y que posiblemente se consideren desperdicio. Sabemos que en Product Owner controla los costes del producto, pero ¿Quién controla los costes asociados a la consultora? Muchas le piden al Scrum Master que lo haga, una vez más, esto los convertiría en Jefes de Proyecto. Otra opción es crear nuevas figuras que hagan esta labor, puede funcionar pero aumentamos el coste.
Otro problema es que, si dejamos que nuestro cliente (el que nos ha contratado) sea el Product Owner sin saber lo que significa, acabaremos por hacer nosotros sus labores.
Expertos
Sumemos otra dificultad. En la mayoría de las casos las empresas no saben de tecnología tanto como las consultoras por lo que se dejan asesorar por ellas. Hace años tenía mucho sentido, les adquirían los ordenadores, se los instalaban y configuraban, a veces les desarrollaban un software específico.
Ahora es diferente, deben asesorarles sobre lo que es ser Agile pero requiere tantos cambios, que preferimos enseñarles un Agile más edulcorado que no implique cambiar y que nos asegure un buen dinero.
Nos hemos acostumbrado todos a trabajar con fechas finales de entrega y cambiar eso es enfrentarnos a la dirección. Esto nos puede generar un ruido que no nos interesa, la venta está en juego.
¿Podemos convencer?
Hace poco hablando con una consultora me hicieron esa pregunta ¿Cómo convencemos? Realmente creo que no existe una argumentación implacable. Depende de muchos factores. ¿Qué problemas queremos realmente resolver? Pero no habiendo una argumentación, podemos utilizar alguna de las siguientes estrategias:
- Plantarnos. Es así de simple, si no vamos a trabajar en un contexto Agile y bajo Scrum lo mejor es que no empecemos, porque mancharemos nuestro nombre. Vale, esta es la posición más radical pero dependerá de quién queramos ser. A las organizaciones más Agile les está funcionando con algunos clientes. “yo no quiero trabajar contigo así porque nos vamos a estrellar, si la competencia lo hace adelante, hablaremos en el futuro”.
- Contrato Abierto. Este caso es el de mayor éxito, consiste en firmar un equipo (coste) y un tiempo y con ello empezar a hacer Scrum hasta que consideremos. Este modelo puede funcionar con un Product Owner que sepa gestionar bien su producto y utilice este contrato abierto como parte de los costes de su producto. Hay que tener mucho cuidado con este tipo de contrato porque, a veces, hay fechas comprometidas con entregables y lo que parece abierto, es tan cerrado que haría las delicias de Henry Gantt.
- Tres Sprint y… ¿Seguimos?. Otra alternativa es hacer tres Sprints en modalidad más cerrada. En este periodo podemos evaluarnos mutuamente y generar confianza. Por un lado el cliente puede evaluar si la consultora le entrega valor y por otro lado el cliente aprende. A partir de ahí podemos empezar a hablar de fechas al tener mayor conocimiento. Recordemos que la velocidad de desarrollo de un equipo dependerá también del cliente y de todos los impedimentos y dependencias por lo que no puede asumir una consultora todo el peso de la entrega.
- Reparto de beneficios. Otra modalidad que algunos han experimentado es repartirse los beneficios construidos con el producto. Esto no funciona para todo tipo de productos pero puede tener sentido para los que tengan cara al público y en los que se pueda medir el valor del mismo en base a ingresos. Desde luego es una de las mejores opciones si queremos fomentar que consultora y cliente estén comprometidas con un objetivo común.
- Firmar cerrado y tratar de cambiar. Una de las alternativas que más he visto es la de cerrar con el cliente un alcance para tratar de llevarlo a un modelo de confianza. La idea es, firmamos unos Sprints con un alcance conocido (hacemos algún ejercicio de descubrimiento) y a medida que el cliente solicita cambios, tratamos de proponerle el abrir el contrato y dejar el alcance abierto. Esto puede funcionar, pero es peligroso porque el cliente puede acabar sacando el contrato, hay que hacerlo con mucho arte.
Estas son algunas estrategias, estoy convencido de que a medida que me enfrente a nuevas compañías y retos descubriré otras muchas. Si nos fijamos, ninguna de ellas nos asegura un equipo Scrum, pero nos dan ideas de cómo podemos actuar ante un cliente.
De momento el mundo de la consultoría para mí es un problema. Actualmente he decidido incorporarme a otra para ayudarles a cambiar, no sé qué me deparará el futuro pero si esperamos encontrar la organización perfecta que ya crea en Agile ¿Para que nos van a necesitar?
