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.
