miércoles, marzo 28, 2018

¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)?

Hola a todos

Hace un tiempo vi el excelente video de Agustín Villena - LKES17: Agustin Villena - Alineamiento, flujo y exploración (clic aquí) - recomiendo verlo con papel y lápiz, - por allá en el minuto 16:00-  clic aquí-, comparte la siguente gráfica de Alistair Cockburn.

Develop for business value once risks are down (1)



Donde el mensaje clave es: "Antes de comenzar a generar valor debes bajarle el riesgo a tu proyecto"

Es obvio sino tu proyecto, producto o iniciativa estará torpedeado por impedimentos, retrasos, problemas, desconocimientos, complicaciones técnicas, etc., cayendo en una zona de mucha fricción y poca velocidad en el desarrollo y en consecuencia es difícil generación de valor. Es por eso que también que dentro de las sugerencias para realizar un piloto en ágil se sugiere que la tecnología sea conocida y dominada por el equipo (2).

Ahora también,  lo presenta el articulo de Alistair (1) en el apartado "Don’t confuse knowledge acquisition with BDUF -Big Desing Up Front(3)", es probable que debas asumir una velocidad baja de tu equipo mientras logran:

  • entender mejor la arquitectura
  • resolver dependencias
  • realizar pruebas de concepto
  • comprender mejor los frameworks
Y luego de esta zona, si ganar velocidad en la zona de generación de valor.


Hasta acá este cortísimo compartir

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

  1. Design as Knowledge Acquisition by Alistair Cockbur - clic aquí- .
  2. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. - clic aquí -.
  3. Big Desing Up Front: the old habit of sitting at the desk and drawing up a big, fancy, full-scale design (BDUF = “big design up front”) (1)
  4. Cada vez más me alejo del concepto de Proyecto Ágil, podria cambiar este título por ¿Cuándo se Comienza a Generar Valor en la Construcción de un Producto de Forma Ágil?


lunes, marzo 26, 2018

Un tweet de un grande - R.I.P. Mike Beedle

viernes, marzo 02, 2018

Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones


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 propuestoObservaciones

  • 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).

  • Opción 2: Referencias

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