Hola a todos
En el medio, cuando hablamos con otros agilistas sobre la forma que las organizaciones están abordando la contratación de proyectos ágiles nos encontramos con RFP (Request For Proposal - Solicitudes de Propuesta) donde existen cláusulas, penalidades y ANS (acuerdos de niveles de servicio) como:
- El equipo deberá mejorar un 1% cada sprint su velocidad
- Ganará el RFP el proveedor que proponga el menor tamaño de sprint
- Ganará el RFP el proveedor que proponga menos sprints
- Ganará el RFP el que haga historias de usuario en menos tiempo
Lo cierto es que venimos acostumbrados a penalizaciones y a la desconfianza de cascada, (-obvio nadie salía ganando, el producto no era el esperado, al igual que la fecha y el costo no se cumplían, es un caos por donde se mire -), en donde se generaban clausulas como:
- deberá reducir el porcentaje de defectos proporcionalmente en sus requerimientos
- por día de demora en la fecha de entrega deberá pagar $/día (y he visto proyectos donde la suma de la penalidad es tal que el proyecto termina valiendo cero pesos)
- Por cada error en producción se descontará $xx.xxx.xxx
- entre muchas otras cosas igual o peor de dolorosas donde el proveedor se acomodaba (cobrando más costoso - en el mejor de los casos-, o más barato) pues le interesaba conservar el cliente.(ver este post ¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu - clic aquí)
Por lo tanto, es probable que quien este al frente de contrataciones de proyectos ágiles
- Esté mal asesorado
- No tiene conocimiento o entendimiento de ágil -no tiene que tenerlo, en algún momento yo no lo tuve- y en su buena voluntad cree que poniendo restricciones similares a la de cascada podrá "controlar" el proyecto (cosa que tampoco ocurría en cascada - pero que será artículo de otro post- ).
Lo que se observa en este caso es que se esta tratando de resolver un problema nuevo bajo un paradigma mental anterior y que no aplica para este nuevo contexto, y es allí donde se requiere de buen acompañamiento.
Dado lo anterior, cuales serían mis observaciones al clausulado del principio del artículo.
| Clausula o ANS propuesto | Observaciones |
|---|
- el equipo deberá mejorar un 1% cada sprint su velocidad
|
- Implica que la mejora un año deberá mejorar 48% (y eso que no apliqué la formula del interés compuesto) más de alcance al final del año si consideramos sprints de dos semanas(y en dos años del 96%). esto es insostenible,
- Lo que va a lograr es que las historias de usuario cada vez le pongan más tamaño. (obtienes lo que mides)
- O si se le hace auditoría las estimaciones de las historias de usuario (que es lo que menos valor genera, auditar estimaciones) terminará agotando al proveedor y dejará de ser negocio para el proveedor continuar con ese cliente pues no es rentable, ni demostrable ese ritmo sostenido de mejora.
|
- Ganará el RFP el proveedor que proponga el menor tamaño de Sprint
|
- El tamaño del sprint no implica absolutamente nada, se recomienda 2 semanas, equipos con mucha experiencia tienen sprints de 1 semana, y otros trabajan con kanban, pero es el contexto el que da el tamaño del sprint.
- Es mu probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas partes que ágil no sirve.
|
- Ganará el RFP el proveedor que proponga menos sprints
|
- Es una orientación puramente hacia cascada y creer que se puede definir el alcance a priori en agile (aun en cascada) es falso.
- Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve
|
- Ganará el RFP el que haga historias de usuario en menos tiempo
|
- Las historias de usuario son irregulares, aunque se puede hacer partición de ellas no es posible garantizar un tamaño, y aunque se desarrolle más rápido algunas no es garantía de que todas van a ser así.
- Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve
|
|
¿Cómo resolver esto?
- Opción 1: Prueba de Concepto
Una posible forma de saber con que proveedor quedarse es darle la oportunidad de ejecutarun proyecto en ágil , que ejecute varios sprints (2, 3, o 4 sprints)y si:
- tiene buen manejo de la metodología
- si equipo esta preparado y experimentado
- tiene gestión de la deuda técnica
- tiene prácticas técnicas
- su scrum master es preparado y con experiencia
- entregan software funcionando cada dos semanas
Continuar con el, sino detenerse y entregarle el proyecto otro proveedor.
¿Pero perdiste como cliente? No, ganaste conocimiento y al menos quedaste con software funcionando (cosa que no quedaba en cascada).
Otra opción es visitar referencias de clientes de ese proveedor y validar con un experto en ágil las experiencias y aplique las mismas condiciones de la opción 1, sino funciona terminar el contrato.
Lecturas Recomendadas
Recomiendo para la mejor comprensión y ayuda estos dos post
Bienvenido el feedback
Saludos ágiles
Jorge Abad
