Con motivo de la última CAS (Conferencia Agile Spain) 2016 celebrada en diciembre en Vitoria, en los corrillos apareció un tema interesante que me hizo reflexionar posteriormente, y que para alguien que se considera agile no presenta un problema por todas las ventajas que tiene Agile.
Pero para un cliente que esté empezando a trabajar con equipos agile y esté "migrando" de equipos waterfall a equipos agile o en plena transición agile, se presenta:
¿Porqué las consultoras cobran más cara la tarifa agile de desarrollo software que la tarifa waterfall?
Hablando con compañeros y compartiendo opiniones, decidí solicitarle a Jerónimo Palacios,un referente para mí, un post tras conversar sobre el tema con él. Está en :
https://jeronimopalacios.com/2017/01/scrumclinic-coste-equipos-agiles-vs-tradicionales-waterfall/
Es muy clarificador y está redactado de una forma amena, clara y con sentido del humor.
El problema endémico del sector del desarrollo del software es que las grandes consultoras (y no tan grandes) han estado facturando desarrolladores noveles (juniors) a precio de consultores o seniors para conservar sus márgenes (entre un 50 y 90% por persona) unas veces, con holgura sobre el contrato con el cliente y otras apretados por los márgenes con los clientes (contratando a la baja el pliego para seguir como proveedor).
Para conservar sus márgenes o maximizarlos (muchas veces fruto de facturar perfiles como consultores o jefes de proyecto internos con alta tarifa en dichos proyectos), dichos recursos han sido cedidos en varios proyectos a la vez, para como antes bien decía, maximizar sus beneficios.
El problema que se presenta es que en Agile el equipo es, o debe ser, de dedicación exclusiva al proyecto, con lo cual esa capacidad de distribuir recursos entre distintos proyectos desaparece, puesto que además el equipo ha de estar interactuando mediante dailys, sprint planning, sprints review y retrospectivas con el cliente constantemente. Dicho equipo de dedicación exclusiva maximiza su productividad y auto-organización.
No es un control por parte del cliente, es una sincronización permanente. A parte, para un equipo agile donde hay que entregar producto en cada iteración (entre 2 y 4 semanas) el perfil necesario, lógicamente ya no es un junior, ya son seniors capaces de entregar software funcionando y coherente cada iteración, y claro, dicho perfil es más caro (pero más realista, me vas a facturar un perfil senior como senior, ya no me facturarás un pefil junior sobre explotado como senior).
Las tarifas de dichos equipos Agile son practicamente igual en términos absolutos (puesto que desaparecen roles como el jefe de proyecto en el equipo y se compensa dicha tarifa agile de seniors en términos absolutos y de productividad), es decir en un periodo t de tiempo (un mes, dos meses, etc) no hay gran diferencia. Manejándose entre un 1.2 - 1.3 la diferencia máxima entre perfil waterfall (junior a precio de senior) y perfil agile (perfil senior) y rara vez más allá de un 1.5 (50% más caro que el perfil waterfall si el equipo es competente, dicho equipo lleva tiempo trabajando de modo ágil ya, 1-2 años porque es la esencia de ese proveedor, trabajar de manera Agile con Scrum muy posiblemente), pero claro, el motivo es que dicho equipo está formado por seniors Agile a precio de seniors, no juniors a precio de seniors.
El dilema, que no es tal o no debería serlo nunca, es : ¿
Queremos software bueno y a tiempo en producción? Con un equipo Agile que al realizar MVPs siempre terminarán antes que un equipo waterfall, dicha productividad que da el equipo agile se refleja en software funcionando puesto en producción rápidamente, validado por el cliente, testeado, con menor número de incidencias y coherente con lo que negocio ha solicitado,
ó ¿Queremos software barato que nunca respeta las fechas propuestas de antemano?, y que incurre en sobre coste, frustración y enfados.Si, se ha terminado el proyecto, pero ¿se ha respetado la fecha del 15 de Marzo? No, nos hemos ido al 30 de Abril, no es para tanto. Solo te has retrasado mes y medio (Siendo optimistas).
Por poner un ejemplo más concreto, un MVP agile realiza un 60-70% funcionalidad máxima que sí se va a utilizar, ahorrando en tiempo, al reducir el time to market de puesta en producción respecto a un proyecto waterfall (ya estamos ahorrando simplemente por terminar antes, y además estamos obteniendo el ROI primero, con lo cual maximizamos el ROI esperado). En un proyecto pequeño de 3 meses en Agile que se desvía a mes, mes y medio ya se ve claramente, que decir en proyectos a 6-9 meses o un año vista.
Es decir el MVP habría salido con fecha 15 de Marzo maximizando el ROI un mes y medio más que de manera waterfall y lógicamente compensando la tarifa agile en caso de que hubiera sido un 50% más cara, por tener un gran equipo agile desarrollando dicho producto.
En este punto entramos en otra variable, uno puede para de desarrollar y dedicarse a otra cosa (nuevas oportunidades) o seguir con el desarrollo (con lo cual seguimos generando valor de negocio), siempre que esté bien priorizado y valorado por negocio.
